On Oct 4, 2018, at 8:37 AM, Yu-cheng Yu [off-list ref] wrote:

quoted

On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:

quoted

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.

Sure you can. Just change ARCH_CET_LEGACY_BITMAP to a new number.  You
might need to change all the constants.  And if the ELF note by itself
causes a problem too, you may need to rename it.  And maybe ask glibc
to kindly not enable code that depends on non-upstreamed kernel
features.

There is not, and has never been, any ABI compatibility requirement
that says that, if glibc 2.28 "enables" a feature, that the kernel
will ever enable it in a way that makes glibc 2.28 actually support
it.  All the kernel needs to do is avoid making glibc 2.28 *crash*.