<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p></p>
<div>Linux GABI [1] introduced <span style="font-size: 12pt;">new .note.gnu.property section which contains a program</span></div>
<div><span style="font-size: 12pt;">property note which describes s</span><span style="font-size: 12pt;">pecial handling requirements for linker and run-time loader.</span></div>
<div><br>
</div>
<div>LLD does not support .note.gnu.property yet.</div>
<div><br>
</div>
<div>GABI specifies 2 types of entries:</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 </div>
<div>of the target processor. Linker should select the maximum value among all input</div>
<div>relocatable objects and copy this property to the output. Run-time loader should</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</div>
<div>copy relocations against protected data symbols. If a relocatable object contains this </div>
<div>property, linker should treat protected data symbol as defined locally at run-time and </div>
<div>copy this property to the output share object. Linker should add this property to the </div>
<div>output share object if any protected symbol is expected to be defined locally at run-time. </div>
<div>Run-time loader should disallow copy relocations against protected data symbols defined </div>
<div>in share objects with GNU_PROPERTY_NO_COPY_ON_PROTECTED property. </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 style="font-size: 12pt;">
I think LLD now restricts</span></div>
<div><span style="font-size: 12pt;">doing the copy relocations against protected symbols,</span></div>
<div>so probably we can ignore it ATM.</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 style="font-size: 12pt;"><a href="https://sourceware.org/bugzilla/show_bug.cgi?id=22914">https://sourceware.org/bugzilla/show_bug.cgi?id=22914.</a></span></div>
<div>At the same time as far I know, Linux kernel does not yet has support for </div>
<div>GNU_PROPERTY_STACK_SIZE, so it probably means there are no users at all for it in the wild.</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 style="font-size: 12pt;">capabilities to defend</span></div>
<div><span style="font-size: 12pt;">against ROP/JOP style control-flow subversion </span><span style="font-size: 12pt;">attacks:</span></div>
<div>- Shadow Stack - return address protection to defend against Return <span style="font-size: 12pt;">Oriented Programming,</span></div>
<div>- Indirect branch tracking - free branch protection to defend <span style="font-size: 12pt;">against </span><span style="font-size: 12pt;">Jump/Call Oriented Programming.</span><span style="font-size: 12pt;">"</span></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</div>
<div>with IBT (see Section 13.1.1) when endbr64 instruction starts each valid target where an indirect</div>
<div>branch instruction can land. 8<br>
</div>
<div>* GNU_PROPERTY_X86_FEATURE_1_SHSTK This indicates that all executable sections are compatible</div>
<div>with SHSTK (see Section 13.1.2) where return address popped from shadow stack always matches</div>
<div>return address popped from normal stack.<br>
</div>
<div><br>
</div>
<div>It is not yet supported by gold: https://sourceware.org/bugzilla/show_bug.cgi?id=22915</div>
<div>But supported by bfd: https://sourceware.org/ml/binutils/2017-06/msg00285.html</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</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;">
together with a second PLT. <span style="font-size: 12pt;">That is also what is implemented in bfd it seems: </span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;">
<span style="font-size: 12pt;">https://sourceware.org/ml/binutils/2017-06/msg00285.html.</span></div>
<br>
</div>
<div>GCC started to support it recently and already uses it for building </div>
<div>libobjc, libgfortran, libmpx, libstdc++-v3, libatomic, libbacktrace and other libs:</div>
<div>* https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3c0f15b4cebccdbb6388a8df5933e69c9b773149</div>
<div>* https://gcc.gnu.org/git/?p=gcc.git&a=search&h=743b05ae4918eac3437965016649b2cabbdbb819&st=commit&s=intel+cet</div>
<div><br>
</div>
<div>Technology is backwards compatible. I used GCC version 8.0.1 20180319 </div>
<div>(experimental) for experiments.</div>
<div>For following code and invocations:<br>
</div>
<div>1.cpp:<br>
</div>
<div>int xxx() { return 1; }</div>
<div><br>
</div>
<div>/usr/local/bin/gcc 1.cpp -c -o test1.o -fcf-protection=full -mcet -B.</div>
<div>/usr/local/bin/gcc 1.cpp -c -o test2.o -B.</div>
<div><br>
</div>
<div>Compiler will generate special instructions and emit .note.gnu.property section.</div>
<div>test1.o:</div>
<div>0000000000000000 <_Z3xxxv>:</div>
<div> 0:<span style="white-space:pre"> </span>f3 0f 1e fa <span style="white-space:pre">
</span>endbr64 </div>
<div> 4:<span style="white-space:pre"> </span>b8 01 00 00 00 <span style="white-space:pre">
</span>mov $0x1,%eax<br>
</div>
<div> 9:<span style="white-space:pre"> </span>c3 <span style="white-space:pre">
</span>retq </div>
<div> </div>
<div>readelf output:</div>
<div>Displaying notes found in: .note.gnu.property</div>
<div> Owner Data size<span style="white-space:pre"> </span>Description</div>
<div> GNU 0x00000010<span style="white-space:pre"> </span>NT_GNU_PROPERTY_TYPE_0<br>
</div>
<div> Properties: x86 feature: IBT, SHSTK</div>
<div><br>
</div>
<div>test2.o (no CET):</div>
<div>0000000000000000 <_Z3xxxv>:</div>
<div> 0:<span style="white-space:pre"> </span>b8 01 00 00 00 <span style="white-space:pre">
</span>mov $0x1,%eax</div>
<div> 5:<span style="white-space:pre"> </span>c3 <span style="white-space:pre">
</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. </div>
<div>An important part for the linker</div>
<div>is that it should support .note.gnu.property to properly handle and combine</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 style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">.note.gnu.property</span> and support <span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">GNU_PROPERTY_STACK_SIZE</span>
+ <span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">GNU_PROPERTY_NO_COPY_ON_PROTECTED</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 style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">Linux GABI </span><a href="https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf">https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf</a><br>
</p>
<p>[2] - <span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">"CONTROL-FLOW ENFORCEMENT TECHNOLOGY PREVIEW" (https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf)</span><br>
</p>
<p>[3] - <span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">"System V Application Binary Interface" ch.13 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf)</span><br>
</p>
<p><br>
</p>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div class="BodyFragment"><font size="2">
<div class="PlainText">Best regards,<br>
George | Developer | <span style="background-color:rgb(255,255,255); color:rgb(33,33,33); font-family:Calibri,sans-serif; font-size:13.3333px">Access Softek, Inc</span></div>
</font></div>
</div>
</div>
</body>
</html>