| Message ID | 20210427204720.25007-1-yu-cheng.yu@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Control-flow Enforcement: Indirect Branch Tracking | expand |
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? Or do all userspace programs and libraries have to have been compiled with the ENDBRA instructions? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
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? > Or do all userspace programs and libraries have to have been compiled > with the ENDBRA instructions? 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? --Andy
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. > > 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.
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?
From: Andy Lutomirski > Sent: 28 April 2021 16:15 > > 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 has shadow stack enabled and opens a .so that uses retpolines? > > > > 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? 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. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On 4/28/2021 8:14 AM, Andy Lutomirski wrote: > 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? 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. >>>> >>>> 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? > 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
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@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 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) >
On Wed, Apr 28, 2021 at 9:25 AM Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote: > > 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@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 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. > If you have a Tiger Lake laptop, you can install the CET kernel on Fedora 34 or Ubuntu 20.10/21.04.
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]. This is the second part of CET and enables Indirect Branch Tracking (IBT). It is built on top of the shadow stack series. Changes in v26: - Rebase to Linus tree v5.12. Changes in v25: - Make updates to Kconfig and CPU feature flags for the removal of Kconfig X86_CET and software-defined X86_FEATURE_CET. - Update ENDBR definition. - Rebase to Linus tree v5.12-rc7. [1] Intel 64 and IA-32 Architectures Software Developer's Manual: https://software.intel.com/en-us/download/intel-64-and-ia-32- architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4 [2] Indirect Branch Tracking patches v25: https://lore.kernel.org/r/20210415221734.32628-1-yu-cheng.yu@intel.com/ H.J. Lu (3): x86/cet/ibt: Update arch_prctl functions for Indirect Branch Tracking x86/vdso: Insert endbr32/endbr64 to vDSO x86/vdso/32: Add ENDBR to __kernel_vsyscall entry point Yu-cheng Yu (6): x86/cet/ibt: Add Kconfig option for Indirect Branch Tracking x86/cet/ibt: Add user-mode Indirect Branch Tracking support x86/cet/ibt: Handle signals for Indirect Branch Tracking x86/cet/ibt: Update ELF header parsing for Indirect Branch Tracking x86/vdso: Introduce ENDBR macro x86/vdso: Add ENDBR to __vdso_sgx_enter_enclave arch/x86/Kconfig | 21 +++++++++ arch/x86/entry/vdso/Makefile | 4 ++ arch/x86/entry/vdso/vdso32/system_call.S | 2 + arch/x86/entry/vdso/vsgx.S | 4 ++ arch/x86/include/asm/cet.h | 9 ++++ arch/x86/include/asm/disabled-features.h | 8 +++- arch/x86/include/asm/vdso.h | 20 ++++++++- arch/x86/include/uapi/asm/sigcontext.h | 1 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cet_prctl.c | 5 +++ arch/x86/kernel/fpu/signal.c | 33 ++++++++++++-- arch/x86/kernel/ibt.c | 57 ++++++++++++++++++++++++ arch/x86/kernel/process_64.c | 8 ++++ 13 files changed, 168 insertions(+), 5 deletions(-) create mode 100644 arch/x86/kernel/ibt.c