Re: [musl] [PATCH 1/1] feat(x86_64): use wrfsbase if AT_HWCAP2 allows usage

[Rich Felker <dalias@libc.org>]

On Tue, Mar 29, 2022 at 02:24:16PM +0200, Harald Hoyer wrote:
> If `AT_HWCAP2` has `HWCAP2_FSGSBASE` set, then instead of calling
> `arch_prctl()`, the `wrfsbase` instruction will be used.
> 
> This is helpful in SGX contexts, where inside the enclave no other
> mechanism is possible.

Thanks for including this motivation, since otherwise I don't think it
makes any sense to use this feature. BTW what happens with other
syscalls in such a context (at least set_tid_address is called
unconditionally), and how does the process communicate any information
or even exit?

> diff --git a/src/thread/x86_64/__set_thread_area.c b/src/thread/x86_64/__set_thread_area.c
> new file mode 100644
> index 00000000..dcc5d116
> --- /dev/null
> +++ b/src/thread/x86_64/__set_thread_area.c
> @@ -0,0 +1,14 @@
> +#include <libc.h>
> +#include <syscall.h>
> +#include <bits/hwcap.h>
> +
> +hidden int __set_thread_area(void *p)
> +{
> +	if (__hwcap2 & HWCAP2_FSGSBASE) {
> +		__asm__ ("wrfsbase %0" :: "r" (p) : "memory");
> +		return 0;
> +	}
> +
> +	// arch_prctl(SET_FS, arg)
> +	return syscall(__NR_arch_prctl, 0x1002, p);
> +}

I'm guessing this breaks build on anything but recent assembler
versions, no? If so, it should probably be written with a .byte
directive or something.

There's also a question of whether the existence of the hwcap flag is
intended to document a contract for the kernel to permit the process
to perform this operation, and a contract for the kernel to accept it
being set this way (rather than creating a possible inconsistency
between the kernel's idea of the process's %fs base and the actual %fs
base that's active. Is this documented somewhere on the kernel side?
If so then this should be okay, but this needs checking before it can
be merged.

Rich