On Fri, Aug 28, 2020 at 10:39 AM Andy Lutomirski [off-list ref] wrote:

On Fri, Aug 28, 2020 at 4:38 AM H.J. Lu [off-list ref] wrote:

quoted

On Thu, Aug 27, 2020 at 11:24 PM Florian Weimer [off-list ref] wrote:

quoted

* H. J. Lu:

quoted

Can you think of ANY issues of passing more arguments to arch_prctl?

On x32, the glibc arch_prctl system call wrapper only passes two
arguments to the kernel, and applications have no way of detecting that.
musl only passes two arguments on all architectures.  It happens to work
anyway with default compiler flags, but that's an accident.

In the current glibc, there is no arch_prctl wrapper for i386.  There are
arch_prctl wrappers with 2 arguments for x86-64 and x32.  But this isn't an
issue for glibc since glibc is both the provider and the user of the new
arch_prctl extension.  Besides,

long syscall(long number, ...);

is always available.

Userspace is probably full of tools and libraries that contain tables
of system calls and their signatures.  Think tracing, audit, container
management, etc.  I don't know how they will react to the addition of
new arguments.

Yes, they need to be updated to understand other new operations
added for CET.

-- 
H.J.