<div dir="ltr">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.</div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 20, 2018 at 9:33 AM Rafael Avila de Espindola <<a href="mailto:rafael@espindo.la">rafael@espindo.la</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I think we should wait until there is someone wanting to use these features with lld.<br></div><div><br></div><div>Cheers,<br></div><div>Rafael<br></div><div class="m_-605358536846470748protonmail_signature_block m_-605358536846470748protonmail_signature_block-empty"><div class="m_-605358536846470748protonmail_signature_block-user m_-605358536846470748protonmail_signature_block-empty"><br></div><div class="m_-605358536846470748protonmail_signature_block-proton m_-605358536846470748protonmail_signature_block-empty"><br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On March 20, 2018 6:59 AM, George Rimar <<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>> wrote:<br></div><div> <br></div><blockquote class="m_-605358536846470748protonmail_quote" type="cite"><p><br></p><div>Linux GABI [1] introduced <span class="m_-605358536846470748size" style="font-size:12pt">new .note.gnu.property section which contains a program</span><br></div><div><span class="m_-605358536846470748size" style="font-size:12pt">property note which describes s</span><span class="m_-605358536846470748size" style="font-size:12pt">pecial handling requirements for linker and run-time loader.</span><br></div><div><br></div><div>LLD does not support .note.gnu.property yet.<br></div><div><br></div><div>GABI specifies 2 types of entries:<br></div><div>GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED:<br></div><div><br></div><div>* GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the format <br></div><div>of the target processor. Linker should select the maximum value among all input<br></div><div>relocatable objects and copy this property to the output. Run-time loader should<br></div><div>raise the stack limit to the value specified in this property.<br></div><div>* GNU_PROPERTY_NO_COPY_ON_PROTECTED: This indicates that there should be no<br></div><div>copy relocations against protected data symbols. If a relocatable object contains this <br></div><div>property, linker should treat protected data symbol as defined locally at run-time and <br></div><div>copy this property to the output share object. Linker should add this property to the <br></div><div>output share object if any protected symbol is expected to be defined locally at run-time. <br></div><div>Run-time loader should disallow copy relocations against protected data symbols defined <br></div><div>in share objects with GNU_PROPERTY_NO_COPY_ON_PROTECTED property. <br></div><div>Its PR_DATASZ should be 0.<br></div><div><br></div><div>I am not sure how much the second is useful because <span class="m_-605358536846470748size" style="font-size:12pt"> I think LLD now restricts</span><br></div><div><span class="m_-605358536846470748size" style="font-size:12pt">doing the copy relocations against protected symbols,</span><br></div><div>so probably we can ignore it ATM.<br></div><div><br></div><div>The first is a bit more interesting. We do not proccess this notes and our output<br></div><div>is broken now, we just merge all records and seems have the same issue as gold has:<br></div><div><span class="m_-605358536846470748size" style="font-size:12pt"><a href="https://sourceware.org/bugzilla/show_bug.cgi?id=22914" target="_blank">https://sourceware.org/bugzilla/show_bug.cgi?id=22914.</a></span><br></div><div>At the same time as far I know, Linux kernel does not yet has support for <br></div><div>GNU_PROPERTY_STACK_SIZE, so it probably means there are no users at all for it in the wild.<br></div><div><br></div><div>On another side, we have an Intel CET [2], [3]:<br></div><div>"Control-flow Enforcement Technology (CET) provides the following <span class="m_-605358536846470748size" style="font-size:12pt">capabilities to defend</span><br></div><div><span class="m_-605358536846470748size" style="font-size:12pt">against ROP/JOP style control-flow subversion </span><span class="m_-605358536846470748size" style="font-size:12pt">attacks:</span><br></div><div>- Shadow Stack - return address protection to defend against Return <span class="m_-605358536846470748size" style="font-size:12pt">Oriented Programming,</span><br></div><div>- Indirect branch tracking - free branch protection to defend <span class="m_-605358536846470748size" style="font-size:12pt">against </span><span class="m_-605358536846470748size" style="font-size:12pt">Jump/Call Oriented Programming.</span><span class="m_-605358536846470748size" style="font-size:12pt">"</span><br></div><div><br></div><div>Intel CET uses following processor-specific program property types in .note.gnu.property [3, p85, p87]:<br></div><div><br></div><div>* GNU_PROPERTY_X86_FEATURE_1_IBT This indicates that all executable sections are compatible<br></div><div>with IBT (see Section 13.1.1) when endbr64 instruction starts each valid target where an indirect<br></div><div>branch instruction can land. 8<br></div><div>* GNU_PROPERTY_X86_FEATURE_1_SHSTK This indicates that all executable sections are compatible<br></div><div>with SHSTK (see Section 13.1.2) where return address popped from shadow stack always matches<br></div><div>return address popped from normal stack.<br></div><div><br></div><div>It is not yet supported by gold: <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=22915" target="_blank">https://sourceware.org/bugzilla/show_bug.cgi?id=22915</a><br></div><div>But supported by bfd: <a href="https://sourceware.org/ml/binutils/2017-06/msg00285.html" target="_blank">https://sourceware.org/ml/binutils/2017-06/msg00285.html</a><br></div><div><br></div><div>Support requires both compiler and linker changes.<br></div><div><br></div><div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px">Also [3, p151] says that to support IBT the linker should generate a IBT-enabled PLT<br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px">together with a second PLT. <span class="m_-605358536846470748size" style="font-size:12pt">That is also what is implemented in bfd it seems: </span><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px"><span class="m_-605358536846470748size" style="font-size:12pt"><a href="https://sourceware.org/ml/binutils/2017-06/msg00285.html" target="_blank">https://sourceware.org/ml/binutils/2017-06/msg00285.html</a>.</span><br></div></div><div>GCC started to support it recently and already uses it for building <br></div><div>libobjc, libgfortran, libmpx, libstdc++-v3, libatomic, libbacktrace and other libs:<br></div><div>* <a href="https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3c0f15b4cebccdbb6388a8df5933e69c9b773149" target="_blank">https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3c0f15b4cebccdbb6388a8df5933e69c9b773149</a><br></div><div>* <a href="https://gcc.gnu.org/git/?p=gcc.git&a=search&h=743b05ae4918eac3437965016649b2cabbdbb819&st=commit&s=intel+cet" target="_blank">https://gcc.gnu.org/git/?p=gcc.git&a=search&h=743b05ae4918eac3437965016649b2cabbdbb819&st=commit&s=intel+cet</a><br></div><div><br></div><div>Technology is backwards compatible. I used GCC version 8.0.1 20180319 <br></div><div>(experimental) for experiments.<br></div><div>For following code and invocations:<br></div><div>1.cpp:<br></div><div>int xxx() { return 1; }<br></div><div><br></div><div>/usr/local/bin/gcc 1.cpp -c -o test1.o -fcf-protection=full -mcet -B.<br></div><div>/usr/local/bin/gcc 1.cpp -c -o test2.o -B.<br></div><div><br></div><div>Compiler will generate special instructions and emit .note.gnu.property section.<br></div><div>test1.o:<br></div><div>0000000000000000 <_Z3xxxv>:<br></div><div>   0:<span style="white-space:pre-wrap"> </span>f3 0f 1e fa          <span style="white-space:pre-wrap"> </span>endbr64 <br></div><div>   4:<span style="white-space:pre-wrap"> </span>b8 01 00 00 00       <span style="white-space:pre-wrap"> </span>mov    $0x1,%eax<br></div><div>   9:<span style="white-space:pre-wrap"> </span>c3                   <span style="white-space:pre-wrap"> </span>retq   <br></div><div>   <br></div><div>readelf output:<br></div><div>Displaying notes found in: .note.gnu.property<br></div><div>  Owner                 Data size<span style="white-space:pre-wrap"> </span>Description<br></div><div>  GNU                  0x00000010<span style="white-space:pre-wrap"> </span>NT_GNU_PROPERTY_TYPE_0<br></div><div>      Properties: x86 feature: IBT, SHSTK<br></div><div><br></div><div>test2.o (no CET):<br></div><div>0000000000000000 <_Z3xxxv>:<br></div><div>   0:<span style="white-space:pre-wrap"> </span>b8 01 00 00 00       <span style="white-space:pre-wrap"> </span>mov    $0x1,%eax<br></div><div>   5:<span style="white-space:pre-wrap"> </span>c3                   <span style="white-space:pre-wrap"> </span>retq   <br></div><div><br></div><div>endbr64 is no-op (for CPUs that do not support CET), more details are in specs above. <br></div><div>An important part for the linker<br></div><div>is that it should support .note.gnu.property to properly handle and combine<br></div><div>x86 specific properties or reject them, since with dumb merging of sections we seems<br></div><div>produce broken output here again.<br></div><div><br></div><div>Given all above I suggest to:<br></div><div>1) Implement <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px">.note.gnu.property</span></span></span> and support <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px">GNU_PROPERTY_STACK_SIZE</span></span></span>
 + <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px"><span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px">GNU_PROPERTY_NO_COPY_ON_PROTECTED</span></span></span></span></span></span><br></div><div>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 <br></div><div>on p86-p88 of [3]).<br></div><div>3) Deside if we want to support Intel CET.<br></div><div><br></div><p>[1] - <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px">Linux GABI </span></span></span><a href="https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf" target="_blank">https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf</a><br></p><p>[2] - <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px">"CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" (<a href="https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf" target="_blank">https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf</a>)</span></span></span><br></p><p>[3] - <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748font" style="font-family:Calibri,Arial,Helvetica,sans-serif"><span class="m_-605358536846470748size" style="font-size:16px">"System V Application Binary Interface" ch.13 (<a href="https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf" target="_blank">https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf</a>)</span></span></span><br></p><p><br></p><div id="m_-605358536846470748Signature"><div name="divtagdefaultwrapper"><div class="m_-605358536846470748BodyFragment"><span class="m_-605358536846470748size" style="font-size:13px"><div class="m_-605358536846470748PlainText"><div>Best regards,<br></div><div> George | Developer | <span class="m_-605358536846470748highlight" style="background-color:rgb(255,255,255)"><span class="m_-605358536846470748colour" style="color:rgb(33,33,33)"><span class="m_-605358536846470748font" style="font-family:Calibri,sans-serif"><span class="m_-605358536846470748size" style="font-size:13.3333px">Access Softek, Inc</span></span></span></span><br></div></div></span></div></div></div></blockquote><div><br></div></blockquote></div>