SSE registers in thread state
Hello, it occurred to me that as far as userland is concerned, the FPU/SEE thread state only consists of i386_fp_save & i386_fp_regs, and userland simply uses frstor to restore it when sigreturning. It seems that gnumach has grown better support for the fancier SSE registers in its internal state tracking (i386_fpsave_state / i386_xfp_save), but this doesn't seem to be exported to userland. I don't know much about SSE and those registers and fxsave/fxrstor and xsave/xrstor, but it seems clear enough that this will result in string operations breaking after a thread receives a signal (assuming gnumach does things correctly -- otherwise, after any context switch). Let's do something about this. Sergey
Re: SSE registers in thread state
Hello, Sergey Bugaev, le mar. 20 juin 2023 12:15:23 +0300, a ecrit: > It seems that gnumach has grown better support for the fancier > SSE registers in its internal state tracking (i386_fpsave_state / > i386_xfp_save), but this doesn't seem to be exported to userland. It enables CR4_OSFXSR, which is enough for userland to be allowed to handle save/restore. > (assuming gnumach does things correctly -- otherwise, after any > context switch). I believe it does. > it occurred to me that as far as userland is concerned, the FPU/SEE > thread state only consists of i386_fp_save & i386_fp_regs, and > userland simply uses frstor to restore it when sigreturning. That probably needs to be looked at, indeed. > I don't know much about SSE and those registers and fxsave/fxrstor and > xsave/xrstor, but it seems clear enough that this will result in > string operations breaking after a thread receives a signal AIUI the problem only happens if one uses SSE (e.g. string operations) in the signal handler while the interrupted thread uses SSE, thus not that common (and thus probably why we didn't notice the problem). Samuel
Re: Recent patches break ACPI tables
Almudena Garcia, le lun. 19 juin 2023 18:35:51 +, a ecrit: > phystokv will doesn't solve fully the problem, because the lapic address is > out of the range allowed by this function. Ah, right. > Currently, we are using paging to map every ACPI table which we need to > access (to get a virtual address of this). > > But the search of the initial ACPI address is based in a physical address > range. Can't this be mapped with kmem_map_aligned_table as well? Samuel
Re: Recent patches break ACPI tables
El martes 20 de junio de 2023, Samuel Thibault escribió: > Almudena Garcia, le lun. 19 juin 2023 18:35:51 +, a ecrit: > > phystokv will doesn't solve fully the problem, because the lapic address is > > out of the range allowed by this function. > > Ah, right. > > > Currently, we are using paging to map every ACPI table which we need to > > access (to get a virtual address of this). > > > > But the search of the initial ACPI address is based in a physical address > > range. > > Can't this be mapped with kmem_map_aligned_table as well? > > Samuel > I think that lapic is already mapped here. The problem is that there are some CPU_NUMBER calls before lapic initialization. -- Enviado desde mi dispositivo Sailfish
Re: SSE registers in thread state
On Tue, Jun 20, 2023 at 12:24 PM Samuel Thibault wrote: > > I don't know much about SSE and those registers and fxsave/fxrstor and > > xsave/xrstor, but it seems clear enough that this will result in > > string operations breaking after a thread receives a signal > > AIUI the problem only happens if one uses SSE (e.g. string operations) > in the signal handler while the interrupted thread uses SSE, thus not > that common (and thus probably why we didn't notice the problem). Yes, but on x86_64 the availability of SSE2 is guaranteed (I believe), so the compilers will use it for basic data manipulation even if you don't call a string function explicitly. That is where the 16-byte stack alignment requirement comes from: the compiler can just use SSE without any checking and assume it will work. We also have to think about sigreturn itself potentially using SSE. Well, that could perhaps be solved by compiling it with a flag to disable that, but then it calls _hurd_sigstate_unlock (and that can call gsync things) and __mach_port_mod_refs, and we definitely wouldn't want to deoptimize generic code. Oh, and the i386 version of sigreturn calls memcpy right after frstor, tha is surely bound to go very well... At least mine doesn't do that. Sergey
[PATCH gnumach] i386/apic.c: Pre-initialize the lapic pointer with a dummy structure
Fixes an early crash when APIC is defined, NCPUS > 1 and LINUX_DEV is not
defined.
CPU_NUMBER can now be called before the local apic pointer is properly
initialized.
---
i386/i386/apic.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/i386/i386/apic.c b/i386/i386/apic.c
index ff7ba3e2..c399074d 100644
--- a/i386/i386/apic.c
+++ b/i386/i386/apic.c
@@ -27,7 +27,13 @@
#include
-volatile ApicLocalUnit* lapic = NULL;
+/*
+ * This dummy structure is needed so that CPU_NUMBER can be called
+ * before the lapic pointer is initialized to point to the real Local Apic.
+ * It causes the apic_id to be faked as 0, which is the master processor.
+ */
+static ApicLocalUnit dummy_lapic = {0};
+volatile ApicLocalUnit* lapic = &dummy_lapic;
ApicInfo apic_data;
--
2.39.0
Re: 64bit startup
Could you please (when you have time, no rush) make another image without the vm_param.h hack? Ideally, with curl and netcat and a DHCP client included. (Curl used to be present in the apt packages cache, but seems to have disappeared from the last image.) Context: I have some changes here that add the inaccessible lower 4 GB mapping, tweak ELF loading in the exec server (preallocate space first, map at that address later), and add some kind of ASLR to gnumach. It all kind of works, but BRK_START being in the lower 4 GB messes things up as one might expect. Also: any reason the Hurd executables are not compiled as PIE? It seems that the rest of Debian is. We'd really prefer PIE for x86_64 at least, otherwise the 4 GB mapping thing doesn't work. Sergey
Re: [PATCH gnumach] i386/apic.c: Pre-initialize the lapic pointer with a dummy structure
Applied, thanks!
Damien Zammit, le mar. 20 juin 2023 10:29:38 +, a ecrit:
> Fixes an early crash when APIC is defined, NCPUS > 1 and LINUX_DEV is not
> defined.
>
> CPU_NUMBER can now be called before the local apic pointer is properly
> initialized.
> ---
> i386/i386/apic.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/i386/i386/apic.c b/i386/i386/apic.c
> index ff7ba3e2..c399074d 100644
> --- a/i386/i386/apic.c
> +++ b/i386/i386/apic.c
> @@ -27,7 +27,13 @@
> #include
>
>
> -volatile ApicLocalUnit* lapic = NULL;
> +/*
> + * This dummy structure is needed so that CPU_NUMBER can be called
> + * before the lapic pointer is initialized to point to the real Local Apic.
> + * It causes the apic_id to be faked as 0, which is the master processor.
> + */
> +static ApicLocalUnit dummy_lapic = {0};
> +volatile ApicLocalUnit* lapic = &dummy_lapic;
>
> ApicInfo apic_data;
>
> --
> 2.39.0
>
>
>
Re: 64bit startup
Sergey Bugaev, le mar. 20 juin 2023 13:42:03 +0300, a ecrit: > Could you please (when you have time, no rush) make another image > without the vm_param.h hack? Ah, yes. That's terribly easy thanks to the rebootstrap script :) > Ideally, with curl and netcat and a DHCP client included. (Curl used > to be present in the apt packages cache, but seems to have disappeared > from the last image.) Indeed, since we are quite limited in terms of initrd size I had dropped a bit, but I included them again. Concerning dhcp, isc-dhcp currently FTBFS. > Also: any reason the Hurd executables are not compiled as PIE? ? € file bin/bash bin/bash: ELF 64-bit LSB pie executable [...] € file hurd/pfinet hurd/pfinet: ELF 64-bit LSB pie executable [...] Samuel
Re: 64bit startup
Samuel Thibault, le mar. 20 juin 2023 14:59:55 +0200, a ecrit: > Sergey Bugaev, le mar. 20 juin 2023 13:42:03 +0300, a ecrit: > > Could you please (when you have time, no rush) make another image > > without the vm_param.h hack? > > Ah, yes. That's terribly easy thanks to the rebootstrap script :) (done so)
Re: 64bit startup
On Tue, Jun 20, 2023 at 3:59 PM Samuel Thibault wrote: > Concerning dhcp, isc-dhcp currently FTBFS. Oh :( > € file hurd/pfinet > hurd/pfinet: ELF 64-bit LSB pie executable I must have been looking in the wrong place then, good. But non-PIE is definitely the case for hurd-i386, and only for binaries from the hurd and netdde packages, it appears. hurd-recommended is PIE. Sergey
Re: 64bit startup
Sergey Bugaev, le mar. 20 juin 2023 16:14:33 +0300, a ecrit: > On Tue, Jun 20, 2023 at 3:59 PM Samuel Thibault > wrote: > > € file hurd/pfinet > > hurd/pfinet: ELF 64-bit LSB pie executable > > But non-PIE is definitely the case for hurd-i386, > > and only for binaries from the hurd and netdde packages, it appears. Indeed, I don't know why, it's probably worth checking why, the gcc default really is pie. Samuel
Re: 64bit startup
On Tue, Jun 20, 2023 at 4:00 PM Samuel Thibault wrote: > (done so) Works beautifully, thank you :D root@hurd:/# ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x01dc) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x0100e000) /lib/ld-x86-64.so.1 (0x0800) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x01e73000) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x01e31000) root@hurd:/# ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x03785000) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x02ecb000) /lib/ld-x86-64.so.1 (0x0800) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x037d3000) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x03713000) root@hurd:/# ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x03c2b000) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x034f9000) /lib/ld-x86-64.so.1 (0x0800) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x03f15000) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x034b6000) root@hurd:/# vminfo $$ 0[0x1000] (prot=0) 0x1000[0x36000] (prot=RX, max_prot=RWX, mem_obj=12) 0x37000[0x2000] (prot=R, max_prot=RWX, mem_obj=12) 0x39000[0x1000] (prot=RW, max_prot=RWX, mem_obj=12) 0x3a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=10) 0x3b000[0x1000] (prot=0, max_prot=RWX, offs=0x1000) 0x3c000[0x100] (prot=RWX, mem_obj=16) 0x5de[0x1000] (prot=RW, max_prot=RWX, mem_obj=18) 0x732d000[0x1000] (prot=RW, max_prot=RWX, mem_obj=18, offs=0x1000) 0x733[0x2000] (prot=RW, max_prot=RWX, mem_obj=19) 0x7332000[0x2000] (prot=R, max_prot=RWX, mem_obj=20) 0x7334000[0x5000] (prot=RW, max_prot=RWX, mem_obj=22) 0x7339000[0x1000] (prot=0, max_prot=RWX) 0x733a000[0x9000] (prot=RW, max_prot=RWX, mem_obj=23) 0x764a000[0x233000] (prot=RX, max_prot=RWX, mem_obj=24) 0x787d000[0x4000] (prot=R, max_prot=RWX, mem_obj=24) 0x7881000[0x3000] (prot=RW, max_prot=RWX, mem_obj=24) 0x7884000[0x5000] (prot=RW, max_prot=RWX, mem_obj=25) 0x791b000[0x2c000] (prot=RX, max_prot=RWX, mem_obj=26) 0x7947000[0x4000] (prot=R, max_prot=RWX, mem_obj=26) 0x794b000[0x1000] (prot=RW, max_prot=RWX, mem_obj=26, offs=0x4000) 0x794c000[0x2e000] (prot=RX, max_prot=RWX, mem_obj=27) 0x797a000[0x1000] (prot=R, max_prot=RWX, mem_obj=27) 0x797b000[0x1000] (prot=RW, max_prot=RWX, mem_obj=27) 0x797c000[0x4000] (prot=RW, max_prot=RWX, mem_obj=28) 0x798[0x14000] (prot=RX, max_prot=RWX, mem_obj=29) 0x7994000[0x1000] (prot=R, max_prot=RWX, mem_obj=29) 0x7995000[0x1000] (prot=RW, max_prot=RWX, mem_obj=29) 0x7996000[0x2000] (prot=RW, max_prot=RWX, mem_obj=30) 0x803b000[0x10f000] (prot=RX, max_prot=RWX, mem_obj=31) 0x814a000[0x4000] (prot=R, max_prot=RWX, mem_obj=31) 0x814e000[0x8000] (prot=RW, max_prot=RWX, mem_obj=31) 0x8156000[0x1000] (prot=RW, max_prot=RWX, mem_obj=31) 0x8157000[0x9000] (prot=RW, max_prot=RWX, mem_obj=32) 0x2000[0x21000] (prot=RWX, mem_obj=33) 0x20021000[0x21000] (prot=RWX, mem_obj=34) 0x20042000[0x21000] (prot=RWX, mem_obj=35) 0x20063000[0x7f9d000] (prot=0, max_prot=RWX, offs=0x63000)
Re: 64bit startup
On Tue, Jun 20, 2023 at 4:55 PM Sergey Bugaev wrote: > Works beautifully, thank you :D ...no it does not! -- and it's visible from the output I posted. ASLR works, the huge heap mapping works, but not the other two things. Investigating now. Sergey
Re: 64bit startup
On Tue, Jun 20, 2023 at 5:07 PM Sergey Bugaev wrote: > ...no it does not! -- and it's visible from the output I posted. ASLR > works, the huge heap mapping works, but not the other two things. > Investigating now. I must have just used the wrong exec server accidentally. Here: # ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x0002319bd000) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x0002361d5000) /lib/ld-x86-64.so.1 (0x0001) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x00023465e000) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x000235cd4000) # ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x004be7fe4000) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x004bd3123000) /lib/ld-x86-64.so.1 (0x0001) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x004bce5b9000) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x004bcce5b000) # ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x00469d756000) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x00467b83a000) /lib/ld-x86-64.so.1 (0x0001) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x00467946) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x00467990e000) # ldd /bin/bash libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x0183a517d000) libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x0183cd306000) /lib/ld-x86-64.so.1 (0x0001) libmachuser.so.1 => /lib/x86_64-gnu/libmachuser.so.1 (0x0183da6e3000) libhurduser.so.0.3 => /lib/x86_64-gnu/libhurduser.so.0.3 (0x0183d4995000) # vminfo $$ 0[0x1] (prot=0) 0x1[0x10f000] (prot=RX, max_prot=RWX, mem_obj=11) 0x10010f000[0x4000] (prot=R, max_prot=RWX, mem_obj=11) 0x100113000[0x8000] (prot=RW, max_prot=RWX, mem_obj=11) 0x10011b000[0x1000] (prot=RW, max_prot=RWX, mem_obj=11) 0x10011c000[0x9000] (prot=RW, max_prot=RWX, mem_obj=4) 0x100125000[0x36000] (prot=RX, max_prot=RWX, mem_obj=10) 0x10015b000[0x2000] (prot=R, max_prot=RWX, mem_obj=10) 0x10015d000[0x1000] (prot=RW, max_prot=RWX, mem_obj=10) 0x10015e000[0x1000] (prot=RW, max_prot=RWX, mem_obj=16) 0x10015f000[0x1000] (prot=0, max_prot=RWX, offs=0x1000) 0x10016[0x100] (prot=RWX, mem_obj=17) 0x2000[0x21000] (prot=RWX, mem_obj=18) 0x20021000[0x21000] (prot=RWX, mem_obj=19) 0x20042000[0x7fbe000] (prot=0, max_prot=RWX, offs=0x42000) 0x70decf7a5000[0x1000] (prot=RW, max_prot=RWX, mem_obj=20) 0x7d938a35[0x1000] (prot=RW, max_prot=RWX, mem_obj=22) 0x7d938a38d000[0x2e000] (prot=RX, max_prot=RWX, mem_obj=23) 0x7d938a3bb000[0x1000] (prot=R, max_prot=RWX, mem_obj=23) 0x7d938a3bc000[0x1000] (prot=RW, max_prot=RWX, mem_obj=23) 0x7d938a3bd000[0x1000] (prot=0, max_prot=RWX) 0x7d938a3be000[0x8000] (prot=RW, max_prot=RWX, mem_obj=24) 0x7d938a3cf000[0x14000] (prot=RX, max_prot=RWX, mem_obj=25) 0x7d938a3e3000[0x1000] (prot=R, max_prot=RWX, mem_obj=25) 0x7d938a3e4000[0x1000] (prot=RW, max_prot=RWX, mem_obj=25) 0x7d938a3e5000[0x2000] (prot=RW, max_prot=RWX, mem_obj=26) 0x7d938a3e7000[0x3000] (prot=RW, max_prot=RWX, mem_obj=27) 0x7d938a3ea000[0x3000] (prot=RW, max_prot=RWX, mem_obj=28) 0x7d938a3ed000[0x2000] (prot=RW, max_prot=RWX, mem_obj=29) 0x7d938a3ef000[0x2000] (prot=RW, max_prot=RWX, mem_obj=30) 0x7d938a3f1000[0x233000] (prot=RX, max_prot=RWX, mem_obj=31) 0x7d938a624000[0x4000] (prot=R, max_prot=RWX, mem_obj=31) 0x7d938a628000[0x3000] (prot=RW, max_prot=RWX, mem_obj=31) 0x7d938a62b000[0x5000] (prot=RW, max_prot=RWX, mem_obj=32) 0x7d938b563000[0x2c000] (prot=RX, max_prot=RWX, mem_obj=33) 0x7d938b58f000[0x4000] (prot=R, max_prot=RWX, mem_obj=33) 0x7d938b593000[0x1000] (prot=RW, max_prot=RWX, mem_obj=33, offs=0x4000) 0x7d938b7a3000[0x2000] (prot=RW, max_prot=RWX, mem_obj=34)
[PATCH] maint: Add empty "check" target.
Provide a "check" target like any GNU package, as is advertised in INSTALL. * Makefile (check): New target. --- Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c611a9ea..c023ea3e 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ # # Copyright (C) 1993-1999, 2001, 2002, 2004, 2006, 2009, -# 2011-2013, 2015-2019 Free Software Foundation, Inc. +# 2011-2013, 2015-2019, 2023 Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License as @@ -336,3 +336,6 @@ stamp-version: version.h.in config.make < $< > version.h.new $(move-if-change) version.h.new version.h touch $@ + +check: + true -- 2.40.1
Re: [PATCH] maint: Add empty "check" target.
Janneke Nieuwenhuizen, le mar. 20 juin 2023 18:07:06 +0200, a ecrit: > Provide a "check" target like any GNU package, as is advertised in > INSTALL. Well, I'd say that if doesn't make anything, better just drop the mention of it from INSTALL. > * Makefile (check): New target. > --- > Makefile | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index c611a9ea..c023ea3e 100644 > --- a/Makefile > +++ b/Makefile > @@ -1,6 +1,6 @@ > # > # Copyright (C) 1993-1999, 2001, 2002, 2004, 2006, 2009, > -# 2011-2013, 2015-2019 Free Software Foundation, Inc. > +# 2011-2013, 2015-2019, 2023 Free Software Foundation, Inc. > # > # This program is free software; you can redistribute it and/or > # modify it under the terms of the GNU General Public License as > @@ -336,3 +336,6 @@ stamp-version: version.h.in config.make > < $< > version.h.new > $(move-if-change) version.h.new version.h > touch $@ > + > +check: > + true > -- > 2.40.1 > > -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
Re: [PATCH] maint: Add empty "check" target.
Samuel Thibault, le mer. 21 juin 2023 00:10:37 +0200, a ecrit: > Janneke Nieuwenhuizen, le mar. 20 juin 2023 18:07:06 +0200, a ecrit: > > Provide a "check" target like any GNU package, as is advertised in > > INSTALL. > > Well, I'd say that if doesn't make anything, better just drop the > mention of it from INSTALL. (done so). > > * Makefile (check): New target. > > --- > > Makefile | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index c611a9ea..c023ea3e 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1,6 +1,6 @@ > > # > > # Copyright (C) 1993-1999, 2001, 2002, 2004, 2006, 2009, > > -# 2011-2013, 2015-2019 Free Software Foundation, Inc. > > +# 2011-2013, 2015-2019, 2023 Free Software Foundation, Inc. > > # > > # This program is free software; you can redistribute it and/or > > # modify it under the terms of the GNU General Public License as > > @@ -336,3 +336,6 @@ stamp-version: version.h.in config.make > > < $< > version.h.new > > $(move-if-change) version.h.new version.h > > touch $@ > > + > > +check: > > + true > > -- > > 2.40.1 > > > > > > -- > Samuel > --- > Pour une évaluation indépendante, transparente et rigoureuse ! > Je soutiens la Commission d'Évaluation de l'Inria. -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria.
