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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev

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:
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

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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 <[hidden email]> 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:
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_SIZEGNU_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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
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 <[hidden email]> 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 <[hidden email]> 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:
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.


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: 
GCC started to support it recently and already uses it for building 
libobjc, libgfortran, libmpx, libstdc++-v3, libatomic, libbacktrace and other libs:

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_SIZEGNU_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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

>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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev
I'd think we shouldn't do anything even for printing out a warning unless doing it is proved to be useful.

On Wed, Mar 21, 2018 at 1:04 AM George Rimar <[hidden email]> wrote:

>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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Adam Nemet via llvm-dev

Just in case, a little update for this thread:


There was a talk about "Protecting the code: Control Flow Enforcement Technology" during the recent

llvm-dev meeting (https://llvm.org/devmtg/2018-04/talks.html#Talk_17).


It was mentioned that some support is already implemented in LLVM. I did not have chance to look close on

it though. Whole feature requires linker side support, current status: bfd support this, gold - still does not.


I would love to see some comments from O. Simhon​ in this thread probably.


Best regards,
George | Developer | Access Softek, Inc

От: Rui Ueyama <[hidden email]>
Отправлено: 23 марта 2018 г. 0:58
Кому: George Rimar
Копия: [hidden email]; llvm-dev
Тема: Re: [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ?
 
I'd think we shouldn't do anything even for printing out a warning unless doing it is proved to be useful.

On Wed, Mar 21, 2018 at 1:04 AM George Rimar <[hidden email]> wrote:

>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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev