Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 28 Apr 2021 08:14:37 -0700 | Subject | Re: [PATCH v26 0/9] Control-flow Enforcement: Indirect Branch Tracking |
| |
On Wed, Apr 28, 2021 at 7:57 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Wed, Apr 28, 2021 at 7:52 AM Andy Lutomirski <luto@kernel.org> wrote: > > > > On Wed, Apr 28, 2021 at 7:48 AM David Laight <David.Laight@aculab.com> 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 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?
| |