Re: [PATCH] Hurd: Enable ifunc by default
On Mon, Jan 18, 2021 at 4:04 PM Samuel Thibault via Libc-alpha
wrote:
>
> (leaving gcc out, it's really out of the story, it just happens to
> expose support for ifunc)
>
> Joseph Myers, le lun. 18 janv. 2021 20:05:44 +, a ecrit:
> > /scratch/jmyers/glibc-bot/install/compilers/i686-gnu/lib/gcc/i686-glibc-gnu/11.0.0/../../../../i686-glibc-gnu/bin/ld:
> >
> > /scratch/jmyers/glibc-bot/build/compilers/i686-gnu/glibc/i686-gnu/elf/librtld.os:
> > in function `hurd_file_name_lookup_retry':
> > (.text+0x1e08e): undefined reference to `strncpy'
>
> The story seems complex and related to the glibc rtld build rules.
>
> - We need hurd/lookup-retry.c in the rtld
> - It happens to use strncpy since ee11682d4f5 ("hurd: Fix strcpy calls")
> - strncpy happens to have a hidden def in libc
> - hurd/lookup-retry.os thus refers to __GI_strncpy rather than strncpy
> - dl-allobjs.os thus includes strncpy-c.os (that provides __GI_strncpy),
> and not strncpy.os (that provides strncpy)
> - librtld.map thus contains strncpy-c.os only, and not strncpy.os
> - thus no rtld-strncpy.os is getting built
> - thus strncpy is not available in rtld
> - but strncpy doesn't have a hidden def in rtld
> - and thus hurd/rtld-lookup-retry.os refers to strncpy, not __GI_strncpy
> - thus the link failure.
>
> The base issue I see here is that dl-allobjs is based on libc-built
> objects that might be using hidden defs while rtld-built objects might
> not.
>
> But we could also say that it's strncpy that should also have a hidden
> def in rtld. The attached patch does this, is this ok?
>
String function usage in ld.so must be carefully managed. Why doesn't
hurd ld.so build script mark strncpy as needed?
--
H.J.
Re: [PATCH] Hurd: Enable ifunc by default
On Mon, Jan 18, 2021 at 4:24 PM Samuel Thibault wrote: > > Samuel Thibault, le mar. 19 janv. 2021 01:21:05 +0100, a ecrit: > > H.J. Lu, le lun. 18 janv. 2021 16:17:16 -0800, a ecrit: > > > Why doesn't hurd ld.so build script mark strncpy as needed? > > > > I don't even know what "hurd ld.so build script" is. > > More precisely, I don't see why hurd should be doing anything special > while everything is already taken care of by elf/Makefile's librtld.map > file scripts. > I am taking a look. -- H.J.
[PATCH] Hurd: Add rtld-strncpy-c.c
On Mon, Jan 18, 2021 at 4:40 PM H.J. Lu wrote: > > On Mon, Jan 18, 2021 at 4:24 PM Samuel Thibault > wrote: > > > > Samuel Thibault, le mar. 19 janv. 2021 01:21:05 +0100, a ecrit: > > > H.J. Lu, le lun. 18 janv. 2021 16:17:16 -0800, a ecrit: > > > > Why doesn't hurd ld.so build script mark strncpy as needed? > > > > > > I don't even know what "hurd ld.so build script" is. > > > > More precisely, I don't see why hurd should be doing anything special > > while everything is already taken care of by elf/Makefile's librtld.map > > file scripts. > > > > I am taking a look. > Try this. I have no idea if it really works on hurd. -- H.J. From a73010aaab13c5cd67ded77091601b8cd01e3fcf Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Mon, 18 Jan 2021 18:19:16 -0800 Subject: [PATCH] Hurd: Add rtld-strncpy-c.c All IFUNC functions which are used in ld.so must have a rtld version if the IFUNC version isn't safe to use in ld.so. --- sysdeps/mach/hurd/i386/i686/multiarch/rtld-strncpy-c.c | 1 + 1 file changed, 1 insertion(+) create mode 100644 sysdeps/mach/hurd/i386/i686/multiarch/rtld-strncpy-c.c diff --git a/sysdeps/mach/hurd/i386/i686/multiarch/rtld-strncpy-c.c b/sysdeps/mach/hurd/i386/i686/multiarch/rtld-strncpy-c.c new file mode 100644 index 00..b759c999eb --- /dev/null +++ b/sysdeps/mach/hurd/i386/i686/multiarch/rtld-strncpy-c.c @@ -0,0 +1 @@ +#include -- 2.29.2
Re: [PATCH] Hurd: Add rtld-strncpy-c.c
On Tue, Jan 19, 2021 at 1:02 AM Samuel Thibault wrote: > > H.J. Lu via Libc-alpha, le lun. 18 janv. 2021 18:24:48 -0800, a ecrit: > > On Mon, Jan 18, 2021 at 4:40 PM H.J. Lu wrote: > > > > > > On Mon, Jan 18, 2021 at 4:24 PM Samuel Thibault > > > wrote: > > > > > > > > Samuel Thibault, le mar. 19 janv. 2021 01:21:05 +0100, a ecrit: > > > > > H.J. Lu, le lun. 18 janv. 2021 16:17:16 -0800, a ecrit: > > > > > > Why doesn't hurd ld.so build script mark strncpy as needed? > > > > > > > > > > I don't even know what "hurd ld.so build script" is. > > > > > > > > More precisely, I don't see why hurd should be doing anything special > > > > while everything is already taken care of by elf/Makefile's librtld.map > > > > file scripts. > > > > > > I am taking a look. > > > > Try this. I have no idea if it really works on hurd. > > It is working indeed. > > Samuel Should I check it in? -- H.J.
Re: [PATCH] Hurd: Add rtld-strncpy-c.c
On Tue, Jan 19, 2021 at 4:26 AM Adhemerval Zanella wrote: > > > > On 19/01/2021 09:21, H.J. Lu via Libc-alpha wrote: > > On Tue, Jan 19, 2021 at 1:02 AM Samuel Thibault > > wrote: > >> > >> H.J. Lu via Libc-alpha, le lun. 18 janv. 2021 18:24:48 -0800, a ecrit: > >>> On Mon, Jan 18, 2021 at 4:40 PM H.J. Lu wrote: > >>>> > >>>> On Mon, Jan 18, 2021 at 4:24 PM Samuel Thibault > >>>> wrote: > >>>>> > >>>>> Samuel Thibault, le mar. 19 janv. 2021 01:21:05 +0100, a ecrit: > >>>>>> H.J. Lu, le lun. 18 janv. 2021 16:17:16 -0800, a ecrit: > >>>>>>> Why doesn't hurd ld.so build script mark strncpy as needed? > >>>>>> > >>>>>> I don't even know what "hurd ld.so build script" is. > >>>>> > >>>>> More precisely, I don't see why hurd should be doing anything special > >>>>> while everything is already taken care of by elf/Makefile's librtld.map > >>>>> file scripts. > >>>> > >>>> I am taking a look. > >>> > >>> Try this. I have no idea if it really works on hurd. > >> > >> It is working indeed. > >> > >> Samuel > > > > Should I check it in? > > > > > Yes please, the loader should not use ifunc on its own string usage and > it is a build issue. Done. -- H.J.
Re: [RFC PATCH glibc 13/34] x86-64: Disable prefer_map_32bit_exec tunable on non-Linux
On Mon, Apr 3, 2023 at 3:10 AM Sergey Bugaev wrote:
>
> On Mon, Apr 3, 2023 at 2:09 AM Samuel Thibault
> wrote:
> > Sergey Bugaev, le dim. 19 mars 2023 18:09:56 +0300, a ecrit:
> > > While we could/should implement MAP_32BIT for the Hurd port by setting
> > > all the high bits of mask in a vm_map () call, neither MAP_32BIT nor
> > > glibc.cpu.prefer_map_32bit_exec exist on the Hurd as of now. Compile
> > > this code out to fix build failures.
> >
> > Rather use defined(MAP_32BIT)? That way it will nicely work for BSD
> > ports as well, and when hurd eventually supports MAP_32BIT.
>
> Not really. What breaks compilation here is not missing MAP_32BIT, but
> rather the undefined set_prefer_map_32bit_exec tunable. It is defined
> declaratively in sysdeps/unix/sysv/linux/x86_64/64/dl-tunables.list
> (see commit 317f1c0a8a71a862b1e600ff5386b08e02cf4b95); so as-is, it
> really is x86_64 Linux specific.
>
> Is there some way to check if a specific tunable is defined, like #if
> HAVE_TUNABLE (prefer_map_32bit_exec)? AFAICS the generated
> dl-tunable-list.h defines the C enum members, but not any checkable
> preprocessor macros.
>
> Alternatively: maybe this part of cpu-features.c should be moved into
> sysdeps/unix/sysv/linux/x86_64/64/cpu-features.c and #include_next the
> common cpu-features.c?
>
Or something like this.
--
H.J.
From 24090a219d8bf902db530bfd9bd73e837f13c435 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Mon, 3 Apr 2023 11:54:30 -0700
Subject: [PATCH] x86-64: Make glibc.cpu.prefer_map_32bit_exec Linux specific
Add to make glibc.cpu.prefer_map_32bit_exec Linux
specific.
---
.../sysv/linux/x86_64/64/map-32bit-exec.h | 29 +++
sysdeps/x86/cpu-features.c| 16 ++
sysdeps/x86/map-32bit-exec.h | 19
3 files changed, 50 insertions(+), 14 deletions(-)
create mode 100644 sysdeps/unix/sysv/linux/x86_64/64/map-32bit-exec.h
create mode 100644 sysdeps/x86/map-32bit-exec.h
diff --git a/sysdeps/unix/sysv/linux/x86_64/64/map-32bit-exec.h b/sysdeps/unix/sysv/linux/x86_64/64/map-32bit-exec.h
new file mode 100644
index 00..74763853e1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86_64/64/map-32bit-exec.h
@@ -0,0 +1,29 @@
+/* Handle glibc.cpu.prefer_map_32bit_exec. Linux/x86-64 version.
+ This file is part of the GNU C Library.
+ Copyright (C) 2023 Free Software Foundation, Inc.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <https://www.gnu.org/licenses/>. */
+
+static void
+TUNABLE_CALLBACK (set_prefer_map_32bit_exec) (tunable_val_t *valp)
+{
+ if (valp->numval)
+GLRO(dl_x86_cpu_features).preferred[index_arch_Prefer_MAP_32BIT_EXEC]
+ |= bit_arch_Prefer_MAP_32BIT_EXEC;
+}
+
+#define TUNABLE_GET_prefer_map_32bit_exec() \
+ TUNABLE_GET (prefer_map_32bit_exec, tunable_val_t *, \
+ TUNABLE_CALLBACK (set_prefer_map_32bit_exec));
diff --git a/sysdeps/x86/cpu-features.c b/sysdeps/x86/cpu-features.c
index 978eb29f72..75a011dab7 100644
--- a/sysdeps/x86/cpu-features.c
+++ b/sysdeps/x86/cpu-features.c
@@ -22,20 +22,11 @@
#include
#include
#include
+#include
extern void TUNABLE_CALLBACK (set_hwcaps) (tunable_val_t *)
attribute_hidden;
-#ifdef __LP64__
-static void
-TUNABLE_CALLBACK (set_prefer_map_32bit_exec) (tunable_val_t *valp)
-{
- if (valp->numval)
-GLRO(dl_x86_cpu_features).preferred[index_arch_Prefer_MAP_32BIT_EXEC]
- |= bit_arch_Prefer_MAP_32BIT_EXEC;
-}
-#endif
-
#if CET_ENABLED
extern void TUNABLE_CALLBACK (set_x86_ibt) (tunable_val_t *)
attribute_hidden;
@@ -710,10 +701,7 @@ no_cpuid:
TUNABLE_GET (hwcaps, tunable_val_t *, TUNABLE_CALLBACK (set_hwcaps));
-#ifdef __LP64__
- TUNABLE_GET (prefer_map_32bit_exec, tunable_val_t *,
- TUNABLE_CALLBACK (set_prefer_map_32bit_exec));
-#endif
+ TUNABLE_GET_prefer_map_32bit_exec ();
bool disable_xsave_features = false;
diff --git a/sysdeps/x86/map-32bit-exec.h b/sysdeps/x86/map-32bit-exec.h
new file mode 100644
index 00..9771338df3
--- /dev/null
+++ b/sysdeps/x86/map-32bit-exec.h
@@ -0,0 +1,19 @@
+/* Handle glibc.cpu.prefer_map_32bit_exec. Generic x86 version.
+ This file is part of the GNU C Library.
+ Copyright (C) 2023 Free Software Foundation, I
Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early
On Thu, Apr 20, 2023 at 11:43 AM Sergey Bugaev wrote: > > Normally, in static builds, the first code that runs is _start, in e.g. > sysdeps/x86_64/start.S, which quickly calls __libc_start_main, passing > it the argv etc. Among the first things __libc_start_main does is > initializing the tunables (based on env), then CPU features, and then > calls _dl_relocate_static_pie (). Specifically, this runs ifunc > resolvers to pick, based on the CPU features discovered earlier, the > most suitable implementation of "string" functions such as memcpy. > > Before that point, calling memcpy (or other ifunc-resolved functions) > will not work. > > In the Hurd port, things are more complex. In order to get argv/env for > our process, glibc normally needs to do an RPC to the exec server, > unless our args/env are already located on the stack (which is what > happens to bootstrap processes spawned by GNU Mach). Fetching our > argv/env from the exec server has to be done before the call to > __libc_start_main, since we need to know what our argv/env are to pass > them to __libc_start_main. > > On the other hand, the implementation of the RPC (and other initial > setup needed on the Hurd before __libc_start_main can be run) is not > very trivial. In particular, it may (and on x86_64, will) use memcpy. > But as described above, calling memcpy before __libc_start_main can not > work, since the GOT entry for it is not yet initialized at that point. > > Work around this by pre-filling the GOT entry with the baseline version > of memcpy, __memcpy_sse2_unaligned. This makes it possible for early > calls to memcpy to just work. Once _dl_relocate_static_pie () is called, > the baseline version will get replaced with the most suitable one, and > that's what subsequent calls of memcpy are going to call. > > Also, apply the same treatment to __stpncpy, which can also be used by > the RPCs (see mig_strncpy.c), and is an ifunc-resolved function on both > x86_64 and i386. > > Tested on x86_64-gnu (!). > > Signed-off-by: Sergey Bugaev > --- > > Please tell me: > > * if the approach is at all sane > * if there's a better way to do this without hardcoding > "__memcpy_sse2_unaligned" > * are the GOT entries for indirect functions supposed to be statically > initialized to anything (in the binary)? if yes, why? if not, why is > PROGBITS and not NOBITS? > * am I doing all this _GLOBAL_OFFSET_TABLE_, @GOT, @GOTOFF, @GOTPCREL > correctly? > * should there be a !PIC version as well? does the GOT exist under > !PIC (to access indirect functions), and if it does then how do I > access it? it would seem gcc just generates a direct $function even > for indirect functions in this case. > > sysdeps/mach/hurd/i386/static-start.S | 7 +++ > sysdeps/mach/hurd/x86_64/static-start.S | 8 > 2 files changed, 15 insertions(+) > > diff --git a/sysdeps/mach/hurd/i386/static-start.S > b/sysdeps/mach/hurd/i386/static-start.S > index c5d12645..1b1ae559 100644 > --- a/sysdeps/mach/hurd/i386/static-start.S > +++ b/sysdeps/mach/hurd/i386/static-start.S > @@ -19,6 +19,13 @@ > .text > .globl _start > _start: > +#ifdef PIC > + call __x86.get_pc_thunk.bx > + addl $_GLOBAL_OFFSET_TABLE_, %ebx > + leal __stpncpy_ia32@GOTOFF(%ebx), %eax > + movl %eax, __stpncpy@GOT(%ebx) > +#endif > + > call _hurd_stack_setup > xorl %edx, %edx > jmp _start1 > diff --git a/sysdeps/mach/hurd/x86_64/static-start.S > b/sysdeps/mach/hurd/x86_64/static-start.S > index 982d3d52..81b3c0ac 100644 > --- a/sysdeps/mach/hurd/x86_64/static-start.S > +++ b/sysdeps/mach/hurd/x86_64/static-start.S > @@ -19,6 +19,14 @@ > .text > .globl _start > _start: > + > +#ifdef PIC > + leaq __memcpy_sse2_unaligned(%rip), %rax > + movq %rax, memcpy@GOTPCREL(%rip) > + leaq __stpncpy_sse2_unaligned(%rip), %rax > + movq %rax, __stpncpy@GOTPCREL(%rip) > +#endif > + > call _hurd_stack_setup > xorq %rdx, %rdx > jmp _start1 > -- > 2.40.0 > Doesn't it disable IFUNC for memcpy and stpncpy? -- H.J.
Re: Upstreaming the glibc Hurd port
On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault wrote: > Hello, > > Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> > remaining TODOs, there are >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README >> needs to be removed, > > Oh, I was unaware of that mention. > > mig master branch failed to build on Fedora 27: gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o parser.o routine.o server.o statement.o string.o type.o user.o utils.o vprint.o /usr/local/bin/ld: lexxer.o: in function `yylex': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: undefined reference to `yywrap' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:495: migcom] Error 1 H.J.
Re: Upstreaming the glibc Hurd port
On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault wrote: > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault >> wrote: >> > Hello, >> > >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> >> > remaining TODOs, there are >> >> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in README >> >> needs to be removed, >> > >> > Oh, I was unaware of that mention. >> >> mig master branch failed to build on Fedora 27: >> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o >> vprint.o >> /usr/local/bin/ld: lexxer.o: in function `yylex': >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: >> undefined reference to `yywrap' > > Could you post config.log? configure is supposed to detect this: > > checking lex library... -lfl > checking lex library... none needed -- H.J.
Re: Upstreaming the glibc Hurd port
On Mon, Apr 2, 2018 at 10:15 AM, Samuel Thibault wrote: > H.J. Lu, on lun. 02 avril 2018 10:06:14 -0700, wrote: >> On Mon, Apr 2, 2018 at 9:16 AM, Samuel Thibault >> wrote: >> > H.J. Lu, on lun. 02 avril 2018 09:01:30 -0700, wrote: >> >> On Mon, Apr 2, 2018 at 7:47 AM, Samuel Thibault >> >> wrote: >> >> > Hello, >> >> > >> >> > Joseph Myers, on lun. 02 avril 2018 14:22:28 +, wrote: >> >> >> On Mon, 2 Apr 2018, Samuel Thibault wrote: >> >> >> >> >> >> > This means that build-glibcs i686-gnu now builds fine. Among the >> >> >> > remaining TODOs, there are >> >> >> >> >> >> Thanks! I'd add: the "requires out-of-tree patches" statement in >> >> >> README >> >> >> needs to be removed, >> >> > >> >> > Oh, I was unaware of that mention. >> >> >> >> mig master branch failed to build on Fedora 27: >> >> >> >> gcc -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o >> >> parser.o routine.o server.o statement.o string.o type.o user.o utils.o >> >> vprint.o >> >> /usr/local/bin/ld: lexxer.o: in function `yylex': >> >> /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lexxer.c:1834: >> >> undefined reference to `yywrap' >> > >> > Could you post config.log? configure is supposed to detect this: >> > >> > checking lex library... -lfl >> >> checking lex library... none needed > > Please really config.log, not only the configure output. > configure:4096: checking lex library configure:4110: gcc -o conftest -g -O2 conftest.c >&5 /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `input': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:1185: undefined reference to `yywrap' /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `yylex': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/lex.yy.c:879: undefined reference to `yywrap' /usr/local/bin/ld: /tmp/ccDAnO2r.o: in function `main': /export/gnu/import/git/toolchain/build/compilers/i686-gnu/mig/conftest.l:18: undefined reference to `yywrap' collect2: error: ld returned 1 exit status configure:4110: $? = 1 configure:4460: result: no ... configure: exit 0 -- H.J.
Re: [RFC PATCH 00/23] aarch64-gnu port
On Wed, Jan 3, 2024 at 9:15 AM Sergey Bugaev wrote: > > Hello! > > This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. > > To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), > and GNU Mach headers for AArch64. I have posted the patches for > binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches > are required to build aarch64-gnu-mig. > > glibc fully builds and produces all the exepected libraries (including > libmvec) and binaries. It can then be used to build other programs, in > particular many core Hurd servers seem to build just fine. > > There is no AArch64 port of GNU Mach yet; I'm trying to get the ball > rolling by making this port of glibc. I have only added some AArch64 > headers to GNU Mach, but no actual runnable code. My versions of > , (and others) > are by no means final, they are more of preliminary sketches of the API > so I have something to port glibc against. If there are changes > resulting from discussions and (hopefully) an eventual Mach AArch64 > port, we'll need to make corresponding changes to glibc. > > There not being a Mach build means that it's not currently possible to > run or test any of this port on a real Mach. It is possible to run > simple statically linked executables on Linux (or, I guess, other > kernels which use ELF and similar enough ABI wrt how the arguments are > placed on the stack) as long as you emulate the syscalls and RPCs in > some way. I have done that, and verified that simple statically linked > executables in the bootstrap configuration (i.e. without a Hurd exec > server, with arguments already placed on the stack by Mach) start up > fine. > > I have also done a quick i686-gnu build (to see if static-start.S or > init-first.c changes have broken something), and a statically linked > hello world seems to still work as expected. > > As usual, the disclaimer about me not knowing what I'm doing: I don't! > I especially am not at all familiar with AArch64, even less so than with > x86_64. I could have done something incredibly stupid; please do review! > > That being said, these changes seem smaller and a lot less radical than > the x86_64 port patchset; they're mostly adding things rather than > reworking them, so there is less of a chance to break the x86 targets. > Evidently, we've done enough rewrokings and portability fixes (notably, > various 64-bit fixes) during the x86_64 port to make it easier to add > new ports. This port itself continues this trend somewhat too, with > init-first.c now finally becoming only sysdeps/mach/hurd -specific, and > HTL gaining support for TLS_DTV_AT_TP. > > As I said in the previous letter on bug-hurd, the hardware hardening > features (BTI, MTE, PAC) are currently "not really supported", but I do > want to support them in the future. I'm extremely interested in getting > feedback or suggestions about these. For example: what should our API > for controlling PAC keys look like, should we just allow userland to > read and write all the keys? Are there, for example, any gotchas with > BTI that we need to be aware of? Is it possible to start using PAC after > initial start-up (once /dev/random becomes available, so PAC keys can be > initialized) — how would we do that without crashing on e.g. ret > pointers that have not been encrypted? > > Finally, a couple of words about the page size. My plan is for userland > to not assume any static value of page size, and always query it > dynamically, unlike on x86, even though GNU Mach will likely be compiled > with some fixed value of page size; my understanding is this is also how > things are done on GNU/Linux. To that end, I've tried to reduce the > reliance on and on EXEC_PAGESIZE being defined. > Currently, Mach headers still define *something* named PAGE_SIZE > unconditionally, causing __mach_init () to pick it up and use it instead > of querying the page size dynamically. We should make sure this does not > happen (i.e. should not define PAGE_SIZE on AArch64), > this is just something I haven't figured out a nice way to fix yet. > > Sergey > > P.S. I have not forgotten about my other unmerged patch series! (Most > importantly, O_IGNORE_CTTY everywhere and the fcntl fortification.) I > hope to find some time to hack on them, hopefully some time soon. > > Sergey Bugaev (23): > hurd: Add some missing includes > hurd: Declare _hurd_intr_rpc_msg* with protected visibility > Allow glibc to be compiled without EXEC_PAGESIZE > mach: Drop some unnecessary vm_param.h includes > hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for now > mach: Drop SNARF_ARGS macro > hurd: Pass the data pointer to _hurd_stack_setup explicitly > hurd: Drop x86-specific assembly from init-first.c > hurd: Make init-first.c no longer x86-specific > hurd: Only init early static TLS if it's used to store stack or > pointer guards > hurd: Initializy _dl_pagesize early in static builds > aarch64: Make cpu-features definitions
Re: [PATCH] Fix spurious glibc version dependency with -z mark-plt on non-Linux
On Tue, Jul 9, 2024, 8:55 AM Samuel Thibault
wrote:
> 916730425594 ("elf: Add elf_backend_add_glibc_version_dependency")
> introduced adding an extra GLIBC_2.36 version dependency for x86_64. But
> on x86_64 GNU/Hurd, there has never been a glibc 2.36 port, and thus the
> GLIBC_2.36 version is not defined. The additional version dependency is
> thus spurious and produces binaries that cannot be executed:
>
> ./test: /lib/x86_64-gnu/libc.so.0.3: version `GLIBC_2.36' not found
> (required by ./test)
>
> This change fixes this by adding the version dependency only on x86_64
> Linux.
>
That is wrong. Your patch checks the
building system, which can be different
from the target.
H.J.
>
Re: [PATCH] Fix spurious glibc version dependency with -z mark-plt on non-Linux
Please open a binutils bug and CC me.
H.J.
On Tue, Jul 9, 2024, 9:01 AM H.J. Lu wrote:
>
> On Tue, Jul 9, 2024, 8:55 AM Samuel Thibault
> wrote:
>
>> 916730425594 ("elf: Add elf_backend_add_glibc_version_dependency")
>> introduced adding an extra GLIBC_2.36 version dependency for x86_64. But
>> on x86_64 GNU/Hurd, there has never been a glibc 2.36 port, and thus the
>> GLIBC_2.36 version is not defined. The additional version dependency is
>> thus spurious and produces binaries that cannot be executed:
>>
>> ./test: /lib/x86_64-gnu/libc.so.0.3: version `GLIBC_2.36' not found
>> (required by ./test)
>>
>> This change fixes this by adding the version dependency only on x86_64
>> Linux.
>>
>
> That is wrong. Your patch checks the
> building system, which can be different
> from the target.
>
> H.J.
>
>>
