This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V4 [PATCH 04/12] x86/CET: Extend arch_prctl syscall for CET control
- From: Sergey Senozhatsky <sergey dot senozhatsky dot work at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Sergey Senozhatsky <sergey dot senozhatsky at gmail dot com>, Florian Weimer <fweimer at redhat dot com>, 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: Tue, 14 Aug 2018 09:46:39 +0900
- 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> <7d236db3-aaa5-3d94-73ac-2ba368ad19ec@redhat.com> <20180813123606.GA409@tigerII.localdomain> <ff5550dd-5adb-6bf1-d4e7-3d6abe25bf30@redhat.com>
On (08/13/18 13:11), Carlos O'Donell wrote:
> > 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.
Right. I'm not arguing, one extra syscall per-process is not a big deal.
> Like *all* glibc features we query for support to see if we're running on
> a new enough kernel to enable the feature.
[..]
> 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.
These all are valid points, sure. But, somehow, testing for a feature
that no kernel or HW supports looks *a bit* different. /etc/ld.so.preload
at least exists on some hosts, while ARCH_CET does not. Maybe it's OK.
My only real problem with ARCH_CET was valgrind.
-ss