Mark Kettenis <[email protected]> wrote: > So as far as I can tell, only arm64 has the -mmark-bti-property > option. On x86 there is a <cet.h> include file that, when included, > emits the "right" .note.gnu.property based on preprocessor macros that > get set based on the compiler options. As far as I can tell, this > <cet.h> include is an "Intel standard" that exists in all recent > versions of clang, gcc and the Intel compiler. The downside of this > approach is that it requires modifications to every x86 assembly file.
I think I have a better way of explaining why it is pointless either way. In the arm64 way, someone with 10 .S files will add -mmark-bti-property to the Makefile, not read the actual .S files, and wait for a bug report that says it doesn't work. In the amd64 way, someone with 10 .S files will add cet.h to every .S files but not actually read the actual .S files, and wait for a bug report that says it doesn't work. In our way, we'll change the kernel to assume all program is safe, and wait for a bug report. We've just skipped the first steps! At which point someone will try to figure out the problem, work on a fix. If no quick fix is possible, that program will be marked as shitty with a linker flag, and the kernel will no longer enforce. If the problem is in a library, we can mark all the programs using that library. Later passes can say "wait too many markers saying programs are shitty", and the bugs can be fixed by ourselves or upstream. We have followed this pattern since 2001 (W^X and wxneeded flagging), and we understand how it works to clean the problems in applications. On the other hand Linux has always done this the other way and done effectively NOTHING to improve these types of problems, and always ridden on our coattails. yes I think their dumb mechanisms will show up in upstreams and it will not help anyone.
