[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions for IBT
> On Oct 4, 2018, at 8:37 AM, Yu-cheng Yu <> wrote:
>> 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.

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

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*.

 \ /
  Last update: 2018-10-04 18:09    [W:0.049 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site