mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Harald Hoyer <harald@profian.com>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH 1/1] feat(x86_64): use wrfsbase if AT_HWCAP2 allows usage
Date: Wed, 30 Mar 2022 08:57:55 +0200	[thread overview]
Message-ID: <c31ee11e-1653-3577-c887-e6f8779ed303@profian.com> (raw)
In-Reply-To: <20220329155453.GF7074@brightrain.aerifal.cx>

Am 29.03.22 um 17:54 schrieb Rich Felker:
> 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?

In our project (enarx) we catch the `syscall` exception and handle it by proxying
it to the host (with filtering and sanity checks). Because `arch_prctl` sets a
hardware register, which is handled special in enclave context switching,
we can't do that for this syscall.

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

Is gcc-4.6.0 old enough?

commit 4ee89d5fb78b48b62b507a29d3a576c63ae22505
Author: H.J. Lu <hongjiu.lu@intel.com>
Date:   Mon Jul 5 21:57:55 2010 +0000

or llvm 3.1.0?

commit 228d9131aad9f3553c9c69abf010f41ce43c8423
Author: Craig Topper <craig.topper@gmail.com>
Date:   Sun Oct 30 19:57:21 2011 +0000

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

linux Documentation/x86/x86_64/fsgs.rst:

  The kernel provides reliable information about the enabled state in the
  ELF AUX vector. If the HWCAP2_FSGSBASE bit is set in the AUX vector, the
  kernel has FSGSBASE instructions enabled and applications can use them.

  reply	other threads:[~2022-03-30  6:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 12:24 [musl] [PATCH V3 0/1] " Harald Hoyer
2022-03-29 12:24 ` [musl] [PATCH 1/1] " Harald Hoyer
2022-03-29 15:54   ` Rich Felker
2022-03-30  6:57     ` Harald Hoyer [this message]
2022-03-30 12:32       ` Rich Felker
  -- strict thread matches above, loose matches on Subject: below --
2022-03-29 11:42 [musl] [PATCH] " Harald Hoyer
2022-03-29 11:54 ` [musl] [PATCH V2 0/1] " Harald Hoyer
2022-03-29 11:54   ` [musl] [PATCH 1/1] " Harald Hoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c31ee11e-1653-3577-c887-e6f8779ed303@profian.com \
    --to=harald@profian.com \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).