On Mon, 2020-03-09 at 15:19 -0400, Simo Sorce wrote: > On Mon, 2020-03-09 at 11:56 -0700, H.J. Lu wrote: > > On Mon, Mar 9, 2020 at 11:19 AM Simo Sorce <[email protected]> wrote: > > > On Mon, 2020-03-09 at 19:03 +0100, Niels Möller wrote: > > > > Simo Sorce <[email protected]> writes: > > > > > > > > > The patchset i solder than I did remember, April 2019 > > > > > But I recall running at least one version of it on our CET emulator @ > > > > > Red Hat. > > > > > > > > Sorry I forgot to followup on that. It seems only the first easy cleanup > > > > patch, "Add missing EPILOGUEs in assembly files", was applied back then. > > > > > > > > Do you remember why you used GNU_CET_SECTION() explicitly in .asm files, > > > > rather than using an m4 divert? > > > > > > Not really I do not recall anymore, but I think there was a reason, as > > > I recall you made that comment back then and it "didn't work out" when > > > I tried is the memory I have of it. > > > Might have to do with differences in how it lays out the code when done > > > via m4 divert, but not 100% sure. > > > > > > > m4 divert requires much less changes. Here is the updated patch with > > ASM_X86_ENDBR, ASM_X86_MARK_CET_ALIGN and ASM_X86_MARK_CET. > > > > > > Two comments on your patch. > > 1. It is an error to align based on architecture. All GNU Notes MUST be > aligned 8 bytes. Since 2018 GNU Libc ignores misaligned notes.
Ah nevermind this point, misunderstanding with my libc expert, the 4 bytes alignment is ok on 32 bit code. > 2. It is better to use .pushsection .popsection pairs around the note > instead of .section because of the side effects of using .section > The m4 divert looks smaller impact, feel free to lift the Gnu Note > section in my patch #3 and place it into your patch if you want. My > code also made it more explicit what all the sections values actually > mean which will help in long term maintenance if someone else need to > change anything (like for example changing to enable only ShadowStack > vs IBT). > > Simo. > -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
