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=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,NICE_REPLY_A,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 5308 invoked from network); 30 Mar 2022 06:58:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Mar 2022 06:58:12 -0000 Received: (qmail 5221 invoked by uid 550); 30 Mar 2022 06:58:09 -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 5173 invoked from network); 30 Mar 2022 06:58:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=profian-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=frqFGrTyNG/nVNfC4P3JsmrX6zuy8i57rtqfVsGudv4=; b=0OaVRfpnf4BMVK2wLlGQJx24WPhLFgcaYNuL5jS5VZwszuyPNfm77GkimEGDthrolu hKKXS5hD/XpBzIukx09PR5G9SEqRO+ToHABa6ZGFwe6kkZLocrXAz2V2rnVpU2KdpWGV w9audJLcsYBS0npK1IORqWQEHP282kplLuCSBMrBt91tVGKLz41hZKWvs3eQJtZv8h63 B3P7M4LVJMZB7BebNU3mq7eX2C8HkbumRnhmvvWXjpVmAsrfSt075+LaZs98KFuhR/cW 6UDcbilS051WIRURJ8IM2JedjraipGxzIY7LsX3mF2//1vN19vmnAhAkDP1h78mBjOfu X9BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=frqFGrTyNG/nVNfC4P3JsmrX6zuy8i57rtqfVsGudv4=; b=i5c1zX683JtyvKYm3w2/w1yVQuGFYSbR3Hzc9V2zT2Grk5lmtJ29qJsDLbn7y2Zvcc D3rY5pROXhwAKGN+kexstHBHtyAuolvVooHndT2IO/MbzlffMT+w8IWY5P10uW9ioc+B Ni1ZS2exV7L0KZnzOLBW9XwB6dZllWGjNeXI9ztPvLRzL2PXO6FprOS7DxUt7Aq8AYwV RKlqxEGPI+YBorY8o2KA0YRIPgqN2mFwMwS6Q73UnaXnqeWVNyiuwmpmXo/tzg2bS8no 6BIAP8ME6ualyQkX71OHzFI3McdSj5+cRAlJClArA3P+xg1pvhuV8s78Ss9UGLkABuIa qILA== X-Gm-Message-State: AOAM530M3iU14u9R8/YYuVJZNCHxgHT9drx9+CVG3psRAYf0T7QM9Vqm HX1PR70kH0360zOCX118YmFVdieTe+8f70Lq X-Google-Smtp-Source: ABdhPJzSYXwQcQ7mooCZwfX92dMWdZbAGSCSVvLK/kisITerl6jguXZlQvdm3985EnlVAPMUc2tJ1Q== X-Received: by 2002:a17:907:1b09:b0:6d8:faa8:4a06 with SMTP id mp9-20020a1709071b0900b006d8faa84a06mr38720847ejc.701.1648623477085; Tue, 29 Mar 2022 23:57:57 -0700 (PDT) Message-ID: Date: Wed, 30 Mar 2022 08:57:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Rich Felker Cc: musl@lists.openwall.com References: <20220329122416.925516-1-harald@profian.com> <20220329122416.925516-2-harald@profian.com> <20220329155453.GF7074@brightrain.aerifal.cx> From: Harald Hoyer In-Reply-To: <20220329155453.GF7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] [PATCH 1/1] feat(x86_64): use wrfsbase if AT_HWCAP2 allows usage 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 >> +#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. Is gcc-4.6.0 old enough? commit 4ee89d5fb78b48b62b507a29d3a576c63ae22505 Author: H.J. Lu Date: Mon Jul 5 21:57:55 2010 +0000 or llvm 3.1.0? commit 228d9131aad9f3553c9c69abf010f41ce43c8423 Author: Craig Topper 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.