This is the mail archive of the
mailing list for the glibc project.
Re: V4 [PATCH 04/12] x86/CET: Extend arch_prctl syscall for CET control
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Sergey Senozhatsky <sergey dot senozhatsky at gmail dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: Sergey Senozhatsky <sergey dot senozhatsky dot work at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 13 Aug 2018 13:11:36 -0400
- Subject: Re: V4 [PATCH 04/12] x86/CET: Extend arch_prctl syscall for CET control
- References: <CAMe9rOqKkgBp7PN9m-L7-r33brXO+Eu_=-7n74B=nS9FEujJhQ@mail.gmail.com> <20180813045118.GA1193@jagdpanzerIV> <email@example.com> <20180813123606.GA409@tigerII.localdomain>
On 08/13/2018 08:36 AM, Sergey Senozhatsky wrote:
> On (08/13/18 13:10), Florian Weimer wrote:
>> On 08/13/2018 06:51 AM, Sergey Senozhatsky wrote:
>>> [ 8.864561] process: tty: Unsupported common prctl 3001
>>> [ 8.865664] expr: Unsupported prctl 3001
>>> Which is, maybe fine, though I'm not entirely sure since I don't
>>> really see ARCH_CET being supported by any arch (neither in linux-next
>>> nor in Linus' tree), so maybe as of now those syscalls are unneeded.
>> Which kernel version is that? The above looks like a kernel bug because
>> there doesn't seem to be any rate limiting.
> Oh, my bad. Sorry, I should have mentioned that it was my own kernel
> modification just to see how often I get -EINVAL prctl syscalls.
You should only see them at startup when we query the kernel for support.
Like *all* glibc features we query for support to see if we're running on
a new enough kernel to enable the feature.
The is similar to how set_robust_list() was handled for robust mutexes and
checking for kernel support in 2.6.17.
>>> The part where, I believe, these -EINVAL prctls begin to backfire is
>>> valgrind - I can't run it anymore with glibc 2.28. It gives me the
>>> following error:
>> valgrind has already been fixed:
> Nice, thanks for the info!
> The fact that there are so many -EINVAL syscalls is still a bit
> misleading, tho.
Is it? You get a '-1' ENOENT return for every process when it starts and
tries to look for /etc/ld.so.preload. This is similar.
Unless you know exactly what the runtime is doing there will be syscalls
that return errors, particularly when testing for newer features.