George Rimar via llvm-dev
2018-Mar-20 13:59 UTC
[llvm-dev] [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
Linux GABI [1] introduced new .note.gnu.property section which contains a program property note which describes special handling requirements for linker and run-time loader. LLD does not support .note.gnu.property yet. GABI specifies 2 types of entries: GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED: * GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the format of the target processor. Linker should select the maximum value among all input relocatable objects and copy this property to the output. Run-time loader should raise the stack limit to the value specified in this property. * GNU_PROPERTY_NO_COPY_ON_PROTECTED: This indicates that there should be no copy relocations against protected data symbols. If a relocatable object contains this property, linker should treat protected data symbol as defined locally at run-time and copy this property to the output share object. Linker should add this property to the output share object if any protected symbol is expected to be defined locally at run-time. Run-time loader should disallow copy relocations against protected data symbols defined in share objects with GNU_PROPERTY_NO_COPY_ON_PROTECTED property. Its PR_DATASZ should be 0. I am not sure how much the second is useful because I think LLD now restricts doing the copy relocations against protected symbols, so probably we can ignore it ATM. The first is a bit more interesting. We do not proccess this notes and our output is broken now, we just merge all records and seems have the same issue as gold has: https://sourceware.org/bugzilla/show_bug.cgi?id=22914.<https://sourceware.org/bugzilla/show_bug.cgi?id=22914> At the same time as far I know, Linux kernel does not yet has support for GNU_PROPERTY_STACK_SIZE, so it probably means there are no users at all for it in the wild. On another side, we have an Intel CET [2], [3]: "Control-flow Enforcement Technology (CET) provides the following capabilities to defend against ROP/JOP style control-flow subversion attacks: - Shadow Stack - return address protection to defend against Return Oriented Programming, - Indirect branch tracking - free branch protection to defend against Jump/Call Oriented Programming." Intel CET uses following processor-specific program property types in .note.gnu.property [3, p85, p87]: * GNU_PROPERTY_X86_FEATURE_1_IBT This indicates that all executable sections are compatible with IBT (see Section 13.1.1) when endbr64 instruction starts each valid target where an indirect branch instruction can land. 8 * GNU_PROPERTY_X86_FEATURE_1_SHSTK This indicates that all executable sections are compatible with SHSTK (see Section 13.1.2) where return address popped from shadow stack always matches return address popped from normal stack. It is not yet supported by gold: https://sourceware.org/bugzilla/show_bug.cgi?id=22915 But supported by bfd: https://sourceware.org/ml/binutils/2017-06/msg00285.html Support requires both compiler and linker changes. Also [3, p151] says that to support IBT the linker should generate a IBT-enabled PLT together with a second PLT. That is also what is implemented in bfd it seems: https://sourceware.org/ml/binutils/2017-06/msg00285.html. GCC started to support it recently and already uses it for building libobjc, libgfortran, libmpx, libstdc++-v3, libatomic, libbacktrace and other libs: * https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3c0f15b4cebccdbb6388a8df5933e69c9b773149 * https://gcc.gnu.org/git/?p=gcc.git&a=search&h=743b05ae4918eac3437965016649b2cabbdbb819&st=commit&s=intel+cet Technology is backwards compatible. I used GCC version 8.0.1 20180319 (experimental) for experiments. For following code and invocations: 1.cpp: int xxx() { return 1; } /usr/local/bin/gcc 1.cpp -c -o test1.o -fcf-protection=full -mcet -B. /usr/local/bin/gcc 1.cpp -c -o test2.o -B. Compiler will generate special instructions and emit .note.gnu.property section. test1.o: 0000000000000000 <_Z3xxxv>: 0: f3 0f 1e fa endbr64 4: b8 01 00 00 00 mov $0x1,%eax 9: c3 retq readelf output: Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT, SHSTK test2.o (no CET): 0000000000000000 <_Z3xxxv>: 0: b8 01 00 00 00 mov $0x1,%eax 5: c3 retq endbr64 is no-op (for CPUs that do not support CET), more details are in specs above. An important part for the linker is that it should support .note.gnu.property to properly handle and combine x86 specific properties or reject them, since with dumb merging of sections we seems produce broken output here again. Given all above I suggest to: 1) Implement .note.gnu.property and support GNU_PROPERTY_STACK_SIZE + GNU_PROPERTY_NO_COPY_ON_PROTECTED 2) For start - error out on all other flags we do not explicitly support (like GNU_PROPERTY_X86_FEATURE_*, GNU_PROPERTY_X86_ISA_* and others on p86-p88 of [3]). 3) Deside if we want to support Intel CET. [1] - Linux GABI https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf [2] - "CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" (https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf) [3] - "System V Application Binary Interface" ch.13 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf) Best regards, George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/b2687b84/attachment.html>
Rafael Avila de Espindola via llvm-dev
2018-Mar-20 16:33 UTC
[llvm-dev] [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
I think we should wait until there is someone wanting to use these features with lld. Cheers, Rafael ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On March 20, 2018 6:59 AM, George Rimar <grimar at accesssoftek.com> wrote:> Linux GABI [1] introduced new .note.gnu.property section which contains a program > property note which describes special handling requirements for linker and run-time loader. > > LLD does not support .note.gnu.property yet. > > GABI specifies 2 types of entries: > GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED: > > * GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the format > of the target processor. Linker should select the maximum value among all input > relocatable objects and copy this property to the output. Run-time loader should > raise the stack limit to the value specified in this property. > * GNU_PROPERTY_NO_COPY_ON_PROTECTED: This indicates that there should be no > copy relocations against protected data symbols. If a relocatable object contains this > property, linker should treat protected data symbol as defined locally at run-time and > copy this property to the output share object. Linker should add this property to the > output share object if any protected symbol is expected to be defined locally at run-time. > Run-time loader should disallow copy relocations against protected data symbols defined > in share objects with GNU_PROPERTY_NO_COPY_ON_PROTECTED property. > Its PR_DATASZ should be 0. > > I am not sure how much the second is useful because I think LLD now restricts > doing the copy relocations against protected symbols, > so probably we can ignore it ATM. > > The first is a bit more interesting. We do not proccess this notes and our output > is broken now, we just merge all records and seems have the same issue as gold has: > [https://sourceware.org/bugzilla/show_bug.cgi?id=22914.](https://sourceware.org/bugzilla/show_bug.cgi?id=22914) > At the same time as far I know, Linux kernel does not yet has support for > GNU_PROPERTY_STACK_SIZE, so it probably means there are no users at all for it in the wild. > > On another side, we have an Intel CET [2], [3]: > "Control-flow Enforcement Technology (CET) provides the following capabilities to defend > against ROP/JOP style control-flow subversion attacks: > - Shadow Stack - return address protection to defend against Return Oriented Programming, > - Indirect branch tracking - free branch protection to defend against Jump/Call Oriented Programming." > > Intel CET uses following processor-specific program property types in .note.gnu.property [3, p85, p87]: > > * GNU_PROPERTY_X86_FEATURE_1_IBT This indicates that all executable sections are compatible > with IBT (see Section 13.1.1) when endbr64 instruction starts each valid target where an indirect > branch instruction can land. 8 > * GNU_PROPERTY_X86_FEATURE_1_SHSTK This indicates that all executable sections are compatible > with SHSTK (see Section 13.1.2) where return address popped from shadow stack always matches > return address popped from normal stack. > > It is not yet supported by gold: https://sourceware.org/bugzilla/show_bug.cgi?id=22915 > But supported by bfd: https://sourceware.org/ml/binutils/2017-06/msg00285.html > > Support requires both compiler and linker changes. > > Also [3, p151] says that to support IBT the linker should generate a IBT-enabled PLT > together with a second PLT. That is also what is implemented in bfd it seems: > https://sourceware.org/ml/binutils/2017-06/msg00285.html. > GCC started to support it recently and already uses it for building > libobjc, libgfortran, libmpx, libstdc++-v3, libatomic, libbacktrace and other libs: > * https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3c0f15b4cebccdbb6388a8df5933e69c9b773149 > * https://gcc.gnu.org/git/?p=gcc.git&a=search&h=743b05ae4918eac3437965016649b2cabbdbb819&st=commit&s=intel+cet > > Technology is backwards compatible. I used GCC version 8.0.1 20180319 > (experimental) for experiments. > For following code and invocations: > 1.cpp: > int xxx() { return 1; } > > /usr/local/bin/gcc 1.cpp -c -o test1.o -fcf-protection=full -mcet -B. > /usr/local/bin/gcc 1.cpp -c -o test2.o -B. > > Compiler will generate special instructions and emit .note.gnu.property section. > test1.o: > 0000000000000000 <_Z3xxxv>: > 0:f3 0f 1e fa endbr64 > 4:b8 01 00 00 00 mov $0x1,%eax > 9:c3 retq > > readelf output: > Displaying notes found in: .note.gnu.property > Owner Data sizeDescription > GNU 0x00000010NT_GNU_PROPERTY_TYPE_0 > Properties: x86 feature: IBT, SHSTK > > test2.o (no CET): > 0000000000000000 <_Z3xxxv>: > 0:b8 01 00 00 00 mov $0x1,%eax > 5:c3 retq > > endbr64 is no-op (for CPUs that do not support CET), more details are in specs above. > An important part for the linker > is that it should support .note.gnu.property to properly handle and combine > x86 specific properties or reject them, since with dumb merging of sections we seems > produce broken output here again. > > Given all above I suggest to: > 1) Implement .note.gnu.property and support GNU_PROPERTY_STACK_SIZE + GNU_PROPERTY_NO_COPY_ON_PROTECTED > 2) For start - error out on all other flags we do not explicitly support (like GNU_PROPERTY_X86_FEATURE_*, GNU_PROPERTY_X86_ISA_* and others > on p86-p88 of [3]). > 3) Deside if we want to support Intel CET. > > [1] - Linux GABI https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf > > [2] - "CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" (https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf) > > [3] - "System V Application Binary Interface" ch.13 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf) > > Best regards, > George | Developer | Access Softek, Inc-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/335fde8f/attachment.html>
Rui Ueyama via llvm-dev
2018-Mar-20 17:35 UTC
[llvm-dev] [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
I agree. Aiming 100% coverage of the Linux ABI spec is not actually our goal. If we found that that is needed or useful, we should do that, but I don't think we should support that for the sake of increasing the ABI spec coverage. Let's see if the new extension will get traction. On Tue, Mar 20, 2018 at 9:33 AM Rafael Avila de Espindola <rafael at espindo.la> wrote:> I think we should wait until there is someone wanting to use these > features with lld. > > Cheers, > Rafael > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On March 20, 2018 6:59 AM, George Rimar <grimar at accesssoftek.com> wrote: > > > Linux GABI [1] introduced new .note.gnu.property section which contains a > program > property note which describes special handling requirements for linker > and run-time loader. > > LLD does not support .note.gnu.property yet. > > GABI specifies 2 types of entries: > GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED: > > * GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the > format > of the target processor. Linker should select the maximum value among all > input > relocatable objects and copy this property to the output. Run-time loader > should > raise the stack limit to the value specified in this property. > * GNU_PROPERTY_NO_COPY_ON_PROTECTED: This indicates that there should be no > copy relocations against protected data symbols. If a relocatable object > contains this > property, linker should treat protected data symbol as defined locally at > run-time and > copy this property to the output share object. Linker should add this > property to the > output share object if any protected symbol is expected to be defined > locally at run-time. > Run-time loader should disallow copy relocations against protected data > symbols defined > in share objects with GNU_PROPERTY_NO_COPY_ON_PROTECTED property. > Its PR_DATASZ should be 0. > > I am not sure how much the second is useful because I think LLD now > restricts > doing the copy relocations against protected symbols, > so probably we can ignore it ATM. > > The first is a bit more interesting. We do not proccess this notes and our > output > is broken now, we just merge all records and seems have the same issue as > gold has: > https://sourceware.org/bugzilla/show_bug.cgi?id=22914. > <https://sourceware.org/bugzilla/show_bug.cgi?id=22914> > At the same time as far I know, Linux kernel does not yet has support for > GNU_PROPERTY_STACK_SIZE, so it probably means there are no users at > all for it in the wild. > > On another side, we have an Intel CET [2], [3]: > "Control-flow Enforcement Technology (CET) provides the following capabilities > to defend > against ROP/JOP style control-flow subversion attacks: > - Shadow Stack - return address protection to defend against Return Oriented > Programming, > - Indirect branch tracking - free branch protection to defend against Jump/Call > Oriented Programming." > > Intel CET uses following processor-specific program property types in > .note.gnu.property [3, p85, p87]: > > * GNU_PROPERTY_X86_FEATURE_1_IBT This indicates that all executable > sections are compatible > with IBT (see Section 13.1.1) when endbr64 instruction starts each valid > target where an indirect > branch instruction can land. 8 > * GNU_PROPERTY_X86_FEATURE_1_SHSTK This indicates that all executable > sections are compatible > with SHSTK (see Section 13.1.2) where return address popped from shadow > stack always matches > return address popped from normal stack. > > It is not yet supported by gold: > https://sourceware.org/bugzilla/show_bug.cgi?id=22915 > But supported by bfd: > https://sourceware.org/ml/binutils/2017-06/msg00285.html > > Support requires both compiler and linker changes. > > Also [3, p151] says that to support IBT the linker should generate a > IBT-enabled PLT > together with a second PLT. That is also what is implemented in bfd it > seems: > https://sourceware.org/ml/binutils/2017-06/msg00285.html. > GCC started to support it recently and already uses it for building > libobjc, libgfortran, libmpx, libstdc++-v3, libatomic, libbacktrace and > other libs: > * > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3c0f15b4cebccdbb6388a8df5933e69c9b773149 > * > https://gcc.gnu.org/git/?p=gcc.git&a=search&h=743b05ae4918eac3437965016649b2cabbdbb819&st=commit&s=intel+cet > > Technology is backwards compatible. I used GCC version 8.0.1 20180319 > (experimental) for experiments. > For following code and invocations: > 1.cpp: > int xxx() { return 1; } > > /usr/local/bin/gcc 1.cpp -c -o test1.o -fcf-protection=full -mcet -B. > /usr/local/bin/gcc 1.cpp -c -o test2.o -B. > > Compiler will generate special instructions and emit .note.gnu.property > section. > test1.o: > 0000000000000000 <_Z3xxxv>: > 0: f3 0f 1e fa endbr64 > 4: b8 01 00 00 00 mov $0x1,%eax > 9: c3 retq > > readelf output: > Displaying notes found in: .note.gnu.property > Owner Data size Description > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > Properties: x86 feature: IBT, SHSTK > > test2.o (no CET): > 0000000000000000 <_Z3xxxv>: > 0: b8 01 00 00 00 mov $0x1,%eax > 5: c3 retq > > endbr64 is no-op (for CPUs that do not support CET), more details are in > specs above. > An important part for the linker > is that it should support .note.gnu.property to properly handle and combine > x86 specific properties or reject them, since with dumb merging of > sections we seems > produce broken output here again. > > Given all above I suggest to: > 1) Implement .note.gnu.property and support GNU_PROPERTY_STACK_SIZE + > GNU_PROPERTY_NO_COPY_ON_PROTECTED > 2) For start - error out on all other flags we do not explicitly > support (like GNU_PROPERTY_X86_FEATURE_*, GNU_PROPERTY_X86_ISA_* and others > on p86-p88 of [3]). > 3) Deside if we want to support Intel CET. > > [1] - Linux GABI > https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf > > [2] - "CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" ( > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > ) > > [3] - "System V Application Binary Interface" ch.13 ( > https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf) > > > Best regards, > George | Developer | Access Softek, Inc > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/7457adad/attachment.html>
George Rimar via llvm-dev
2018-Mar-21 08:04 UTC
[llvm-dev] [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
>I think we should wait until there is someone wanting to use these features with lld.> >Cheers, >RafaelOk. Should we give an error when .note.gnu.property section is in the object?? ?Best regards, George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180321/76b1852c/attachment.html>
Reasonably Related Threads
- [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
- [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
- [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
- [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
- [RFC] - Deduplication of debug information in linkers (LLD).