On 4/28/2021 8:14 AM, Andy Lutomirski wrote:

On Wed, Apr 28, 2021 at 7:57 AM H.J. Lu [off-list ref] wrote:

quoted

On Wed, Apr 28, 2021 at 7:52 AM Andy Lutomirski [off-list ref] wrote:

quoted

On Wed, Apr 28, 2021 at 7:48 AM David Laight [off-list ref] wrote:

quoted

From: Yu-cheng Yu

quoted

Sent: 27 April 2021 21:47

Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks.  Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].

...

Does this feature require that 'binary blobs' for out of tree drivers
be compiled by a version of gcc that adds the ENDBRA instructions?

David, do you mean kernel loadable drivers here?  Do not worry about it 
for now, since shadow stack/ibt is not enabled for kernel-mode yet.

quoted

quoted

quoted

If enabled for userspace, what happens if an old .so is dynamically
loaded?

CET will be disabled by ld.so in this case.

What if a program starts a thread and then dlopens a legacy .so?

quoted

quoted

quoted

Or do all userspace programs and libraries have to have been compiled
with the ENDBRA instructions?

Correct.  ld and ld.so check this.

quoted

If you believe that the userspace tooling for the legacy IBT table
actually works, then it should just work.  Yu-cheng, etc: how well
tested is it?

Legacy IBT bitmap isn't unused since it doesn't cover legacy codes
generated by legacy JITs.

How does ld.so decide whether a legacy JIT is in use?

Let me clarify.  IBT bitmap isn't used at all.  How dlopen() works 
depends entirely on the tunable of glibc.cpu.x86_ibt.  There are three 
values: on, off, permissive.  On is always on, and off is always off, 
regardless of the .so having ibt or not.  The default is "permissive," 
which turns off ibt upon dlopen a legacy .so.  I hope this also answers 
Andy's question above.

Yu-cheng