From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20767 invoked from network); 29 Mar 2022 15:55:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2022 15:55:10 -0000 Received: (qmail 20042 invoked by uid 550); 29 Mar 2022 15:55:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20007 invoked from network); 29 Mar 2022 15:55:06 -0000 Date: Tue, 29 Mar 2022 11:54:53 -0400 From: Rich Felker To: Harald Hoyer Cc: musl@lists.openwall.com Message-ID: <20220329155453.GF7074@brightrain.aerifal.cx> References: <20220329122416.925516-1-harald@profian.com> <20220329122416.925516-2-harald@profian.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220329122416.925516-2-harald@profian.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH 1/1] feat(x86_64): use wrfsbase if AT_HWCAP2 allows usage 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 > +#include > +#include > + > +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