* Yu-cheng Yu: > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote: >> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote: >> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect >> > Branch Tracking features. >> > >> > Introduce: >> > >> > arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned long *addr) >> > Enable the Indirect Branch Tracking legacy code bitmap. >> > >> > The parameter 'addr' is a pointer to a user buffer. >> > On returning to the caller, the kernel fills the following: >> > >> > *addr = IBT bitmap base address >> > *(addr + 1) = IBT bitmap size >> >> Again, some structure with a size field would be better from >> UAPI/extensibility standpoint. >> >> One additional point: "size" in the structure from kernel should have >> structure size expected by kernel, and at least providing there "0" from >> user space shouldn't lead to failure (in fact, it is possible to provide >> structure size back to userspace even if buffer is too small, along >> with error). > > This has been in GLIBC v2.28. We cannot change it anymore. In theory, you could, if you change the ARCH_CET_LEGACY_BITMAP constant, so that glibc will not use the different arch_prctl operation. We could backport the change into the glibc 2.28 dynamic linker, so that existing binaries will start using CET again. Then only statically linked binaries will be impacted. It's definitely not ideal, but it's doable if the interface is terminally broken or otherwise unacceptable. But to me it looks like this threshold isn't reached here.
