llvm dev - Mar 2018 - [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>

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>

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>

>I think we should wait until there is someone wanting to use these features
with lld.
>
>Cheers,
>Rafael
Ok. 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>