On 4/28/2021 8:33 AM, David Laight wrote:
From: Andy Lutomirski
Sent: 28 April 2021 16:15
On Wed, Apr 28, 2021 at 7:57 AM H.J. Lu <hjl.tools@xxxxxxxxx> wrote:
On Wed, Apr 28, 2021 at 7:52 AM Andy Lutomirski <luto@xxxxxxxxxx> wrote:
On Wed, Apr 28, 2021 at 7:48 AM David Laight <David.Laight@xxxxxxxxxx> wrote:
From: Yu-cheng Yu
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?
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?
Or has shadow stack enabled and opens a .so that uses retpolines?
When shadow stack is enabled, retpolines are not necessary. I don't
know if glibc has been updated for detection of this case. H.J.?
Or do all userspace programs and libraries have to have been compiled
with the ENDBRA instructions?
Correct. ld and ld.so check this.
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?
What if your malware just precedes its 'jump into the middle of a function'
with a %ds segment override?
Do you mean far jump? It is not tracked by ibt, which tracks near
indirect jump. The details can be found in Intel SDM.
I may have a real problem here.
We currently release program/library binaries that run on Linux
distributions that go back as far as RHEL6 (2.6.32 kernel era).
To do this everything is compiled on a userspace of the same vintage.
I'm not at all sure a new enough gcc to generate the ENDBR64 instructions
will run on the relevant system - and may barf on the system headers
even if we got it to run.
I really don't want to have to build multiple copies of everything.
This is likely OK. We have tested many combinations. Should you run
into any issue, please let glibc people know.
Thanks!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
