Simo Sorce <s...@redhat.com> writes: > I understand this is not a high bar, and I will fold the segment note > in if you think that is what we should do, but I wanted to make you > aware of why I did not do the same as what we do with the stack note.
I think we should aim to make all files "cet-compliant" if we do it att all. After all, the common case is to have a libnettle.so, and then any single object file missing the annotation will make the linker disable the feature, if I've understood it correctly. I agree it should be disabled by default until we're more confident in test coverage. BTW, do you know how that works with late loading using dlopen? One could have a process running in CET-mode, which dynamically loads an so-file with code lacking endbr instructions and corresponding annotation. If we think about it as an arch-specific thing, which I guess we should, then maybe the m4 divert should be in x86_64/machine.m4 and x86/machine.m4, not asm.m4. > That is funny, I actually used CET_ENDBR to make it easier to find for > others grepping as binutils also uses a _CET_ENDBR macro, it sounded > more consistent I agree your name is better for readability, even if less amusing. >> I'd like to understand what's missing. Maybe we can fix it more >> explicitly? > > I do not think we can easily fix it manually, it is mostly other > section notes that the gcc compiler adds when it fortifies C code. But > those notes do not really apply to handcrafted assembly. [...] > So this flag > is basically just saying to the compiler that it should add whatever is > appropriate (which may change depending on compiler flags) because our > code is good as is. Since the command line flag is passed with -Wa, it tells the *assembler* to add notes. Which ones? Is it based only on the command line, say, $(CFLAGS) contains -fharden-foo makes the assembler produces a "foo" note. Or is it based on what's actually in the assembly input file? Is there a risk that it automatically generates a note promising something about the assembly code which we don't actually fulfill? Is there any documentation? I see that it is mentioned in the binutils-2.31 release announcement, but I've not found it mentioned in the Gas manual. > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > (I do no have a better link) Looks like reasonable doc. (Closest on wikpedia seems to be https://en.wikipedia.org/wiki/Control-flow_integrity). > See above explanation and let me know if that changes your opinion, > otherwise I will do this. > >> > +ALIGN(8) >> > +.long 1f - 0f >> > +.long 4f - 1f >> > +.long 5 >> > +0: >> > +.string "GNU" >> > +1: >> > +ALIGN(8) >> > +.long 0xc0000002 >> > +.long 3f - 2f >> > +2: >> > +.long 0x03 >> > +3: >> > +ALIGN(8) >> > +4: >> >> Are there no symbolic names for this note? Since we require assembler to >> suport endbr instructions, can we require that it know about these notes >> as well? What does it look like in gcc output? > > There are symbolic names to compose the 0x03 value and for the > 0xc0000002 values, the rest are just label arithmetic. > > I will change in next submission. I see, I was hoping for something more similar to .section .note.GNU-stack,"",TYPE_PROGBITS I'm still curious as to what it looks like in gcc output. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
