From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id C12893858D1E for ; Sun, 12 Feb 2023 16:11:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C12893858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRExJ-0000mS-6Z; Sun, 12 Feb 2023 11:11:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=qv9Pcek0tOvWaD/VofMxgStXTyBmrXKPxVagy9aMRtU=; b=FuvMVWrc1g89DsNxIRvI iu2pUjg2+gDFzF2wTDG0JnU06xZo85n6rFWLqd7q+a2W6k1t4LGrSMTFq1ynGYqPsT/SKNjBzYTVt fjRaRIUZncAoRQ7C3Ili60vySlAv1ruywnU+IGXS4/lWd84HETPCc8sjcoMM0h6fvPZbWCFWXh5zv QVva/1D/krbyDRUWuSho0+Ox9TRdTtx1Ea75IswVznaGlLPaa3BiUQtuOimq5x4ZRyUml0NwZQgff wGsZLK3hWdWNUvwengzc5+KoVO799gw81U2m9QdhdRltTBzJhC6zQ9uqOfelOC0xEgXCKu9tVrlcW XaM7zTGPWTkjsA==; Received: from lfbn-bor-1-1163-184.w92-158.abo.wanadoo.fr ([92.158.138.184] helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRExI-0005gi-UO; Sun, 12 Feb 2023 11:11:56 -0500 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pRExF-004sAX-1s; Sun, 12 Feb 2023 17:11:53 +0100 Date: Sun, 12 Feb 2023 17:11:53 +0100 From: Samuel Thibault To: Sergey Bugaev Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz Subject: Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code Message-ID: <20230212161153.q4km4h2ql3k5pasp@begin> Mail-Followup-To: Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz References: <20230212111044.610942-1-bugaevc@gmail.com> <20230212111044.610942-12-bugaevc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230212111044.610942-12-bugaevc@gmail.com> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit: > It seems that GCC expects TLS on x86_64 to be done relative to %fs, not %gs, so > that's what I attempted to do in tls.h. The main thing missing there is the > ability to actually set (and read) the %fs base address of a thread. It is my > understanding (but note that I have no idea what I'm talking about) that on > x86_64 the segment descriptors (as in GDT/LDT) are not used for this, segmentation has somewhat disappeared in x86_64, yes. > and instead the address can be set by writing to a MSR. Linux exposes > the arch_prctl (ARCH_[GS]ET_[FG]S) syscall for this; so maybe GNU Mach > could also have an explicit routine for this, perhaps like this: > > routine i386_set_fgs_base ( > target_thread: thread_t; > which: int; > value: rpc_vm_address_t); Indeed. > We should not need a getter routine, because one can simply inspect the target > thread's state (unless, again, I misunderstand things horribly). For 16bit fs/gs values we could read them from userland yes. But for fs/gs base, the FSGSBASE instruction is not available on all 64bit processors. And ATM in THREAD_TCB we want to be able to get the base of another thread. > diff --git a/sysdeps/mach/hurd/x86_64/static-start.S b/sysdeps/mach/hurd/x86_64/static-start.S > new file mode 100644 > index 00000000..982d3d52 > --- /dev/null > +++ b/sysdeps/mach/hurd/x86_64/static-start.S > @@ -0,0 +1,27 @@ > +/* Type of the TCB. */ > +typedef struct > +{ > + void *tcb; /* Points to this structure. */ > + dtv_t *dtv; /* Vector of pointers to TLS data. */ > + thread_t self; /* This thread's control port. */ > + int __glibc_padding1; > + int multiple_threads; > + int gscope_flag; > + uintptr_t sysinfo; > + uintptr_t stack_guard; > + uintptr_t pointer_guard; > + long __glibc_padding2[2]; > + int private_futex; ? Isn't that rather feature_1 ? > + int __glibc_padding3; > + /* Reservation of some values for the TM ABI. */ > + void *__private_tm[4]; > + /* GCC split stack support. */ > + void *__private_ss; > + /* The lowest address of shadow stack. */ > + unsigned long long int ssp_base; > + > + /* Keep these fields last, so offsets of fields above can continue being > + compatible with the x86_64 NPTL version. */ > + mach_port_t reply_port; /* This thread's reply port. */ > + struct hurd_sigstate *_hurd_sigstate; > + > + /* Used by the exception handling implementation in the dynamic loader. */ > + struct rtld_catch *rtld_catch; > +} tcbhead_t; > + > +/* GCC generates %fs:0x28 to access the stack guard. */ > +_Static_assert (offsetof (tcbhead_t, stack_guard) == 0x28, > + "stack guard offset"); > +/* libgcc uses %fs:0x70 to access the split stack pointer. */ > +_Static_assert (offsetof (tcbhead_t, __private_ss) == 0x70, > + "split stack pointer offset"); Indeed. Could you perhaps also add them to the i386 tls.h? > +/* FIXME */ > +# define __LIBC_NO_TLS() 0 We'll want an efficient way to know whether we have configured TLS indeed. At worse we can make it a global variable. > +/* The TCB can have any size and the memory following the address the > + thread pointer points to is unspecified. Allocate the TCB there. */ > +# define TLS_TCB_AT_TP 1 > +# define TLS_DTV_AT_TP 0 > + Also copy the comment above TCB_ALIGNMENT. > +/* Install new dtv for current thread. */ > +# define INSTALL_NEW_DTV(dtvp) THREAD_SETMEM (THREAD_SELF, dtv, dtvp) > +/* Return the address of the dtv for the current thread. */ > +# define THREAD_DTV() THREAD_GETMEM (THREAD_SELF, dtv) While at it, try to make the i386 version use that too? Samuel