[llvm-dev] [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?

Tue Mar 20 10:35:25 PDT 2018

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>