Re: [PATCH 1/2] hurd: Don't migrate reply port into __init1_tcbhead

Applied, thanks! Sergey Bugaev, le jeu. 20 avril 2023 21:42:19 +0300, a ecrit: > Properly differentiate between setting up the real TLS with > TLS_INIT_TP, and setting up the early TLS (__init1_tcbhead) in static > builds. In the latter case, don't yet migrate the reply port into the > TCB, and do

Re: [PATCH 1/4] hurd: Don't pass fd flags in CMSG_DATA

Sergey Bugaev, le ven. 21 avril 2023 00:47:43 +0300, a ecrit: > You could think of it that way: the > infrastructure for passing an integer value along with the port is > still there, but currently no valid flags for it are defined, and so 0 > is always used. We could spell it as > > fds[i] = desc

Re: [PATCH 1/4] hurd: Don't pass fd flags in CMSG_DATA

On Fri, Apr 21, 2023 at 12:14 AM Samuel Thibault wrote: > Sergey Bugaev, le lun. 17 avril 2023 16:38:59 +0300, a ecrit: > > The only valid flag defined here is FD_CLOEXEC. It is of no concern to > > the receiving process whether or not the sender process wants to close > > its copy of sent file de

Re: [PATCH 1/4] hurd: Don't pass fd flags in CMSG_DATA

Sergey Bugaev, le lun. 17 avril 2023 16:38:59 +0300, a ecrit: > The only valid flag defined here is FD_CLOEXEC. It is of no concern to > the receiving process whether or not the sender process wants to close > its copy of sent file descriptor upon exec, Ok, but couldn't there be some flags that we

Re: [RFC PATCH v2 5/7] hurd: Make dl-sysdep's open () cope with O_IGNORE_CTTY

Applied, thanks! Sergey Bugaev, le mer. 19 avril 2023 19:02:05 +0300, a ecrit: > Signed-off-by: Sergey Bugaev > --- > sysdeps/mach/hurd/dl-sysdep.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c > index

Re: [PATCH 5/5] add setting gs/fsbase

Hello, Sergey Bugaev, le jeu. 20 avril 2023 16:08:45 +0300, a ecrit: > Is that actually configurable somewhere (at gcc/binutils build time, I > mean)? It's probably in the link script, somewhere in /usr/lib/*/ldscripts/elf*x86_64* > I'm thinking we will want to map the lower 4GB of address space

Re: [PATCH 2/5] fix copyoutmsg for 64-bit userspace

Applied, thanks! Luca Dariz, le mer. 19 avril 2023 21:47:00 +0200, a ecrit: > * x86_64/copy_user.c: use the correct user/kernel msg structure > --- > x86_64/copy_user.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/x86_64/copy_user.c b/x86_64/copy_user.c > index b

Re: [PATCH 1/5] fix address fault for 32-on-64-bit syscall

Applied, thanks! Luca Dariz, le mer. 19 avril 2023 21:46:59 +0200, a ecrit: > * x86_64/locore.S: the faulty address is found in %rbp and not in > %rsi, so copy that in CR2 > --- > x86_64/locore.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/x86_64/locore.S b/x86_64/

Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

On 20/04/23 17:25, H.J. Lu via Libc-alpha wrote: > 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 th

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

Re: [PATCH 3/5] fix exception message format for 64-bit userspace

Hi Flavio, Il 20/04/23 04:04, Flávio Cruz ha scritto: On Wed, Apr 19, 2023 at 3:47 PM Luca Dariz > wrote: * kern/exception.c: message fields need to be aligned to 8 bytes for a   64-bit userspace, so add the required padding if needed, as done by   MIG. I

[VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

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_s

[PATCH 1/2] hurd: Don't migrate reply port into __init1_tcbhead

Properly differentiate between setting up the real TLS with TLS_INIT_TP, and setting up the early TLS (__init1_tcbhead) in static builds. In the latter case, don't yet migrate the reply port into the TCB, and don't yet set __libc_tls_initialized to 1. This also lets us move the __init1_desc assign

Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

On 20/04/23 09:06, Cristian Rodríguez wrote: > > > On Thu, Apr 20, 2023 at 7:47 AM Adhemerval Zanella Netto > mailto:adhemerval.zane...@linaro.org>> wrote: > > > > > I am not really sure how effective is this hardening, it seems more a > development one to enforce that system daem

Re: [PATCH 5/5] add setting gs/fsbase

FWIW, mach-bootstrap-hello is supposed to then echo back what you type on the console, but it doesn't work. From some debugging, it seems that once I input something, the following device_write () call hangs here: (gdb) ast_taken () at ../kern/ast.c:88 88 if (reasons & AST_NETWORK) (gdb) 96 if (se

Re: [PATCH 5/5] add setting gs/fsbase

Il 20 aprile 2023 13:18:29 UTC, Sergey Bugaev ha scritto: >On Thu, Apr 20, 2023 at 4:08 PM Sergey Bugaev wrote: >> > Would it work for you to shrink temporarily the VM space, at least for >> > testing? >> >> Yeah, that's also what I've been thinking to try out next. I'm >> somewhat surprised tha

Re: [PATCH 5/5] add setting gs/fsbase

Sergey Bugaev, le jeu. 20 avril 2023 16:18:29 +0300, a ecrit: > On Thu, Apr 20, 2023 at 4:08 PM Sergey Bugaev wrote: > > > Would it work for you to shrink temporarily the VM space, at least for > > > testing? > > > > Yeah, that's also what I've been thinking to try out next. I'm > > somewhat surp

Re: [PATCH 5/5] add setting gs/fsbase

On Thu, Apr 20, 2023 at 4:01 PM Luca wrote: > There is likely some limitation in the pmap module in gnumach, IIRC it should > statically allocate the user L3 page tables as long as the limit is below the > first 512GB, but I never really tested it yet. That sounds plausible, yes, I've seen some

Re: [PATCH 5/5] add setting gs/fsbase

Il 20 aprile 2023 12:46:51 UTC, Sergey Bugaev ha scritto: >On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault >wrote: >> Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit: >> > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault >> > wrote: >> > > > > See 56010b73e81e2cb1082e418699f9835359

Re: [PATCH 5/5] add setting gs/fsbase

On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault wrote: > Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit: > > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault > > wrote: > > > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy. > > > > > > > > Interesting; but that

Re: [PATCH 5/5] add setting gs/fsbase

Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit: > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault > wrote: > > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy. > > > > > > Interesting; but that one's dealing with the SHARED case, isn't it? > > > > Yes but I gue

Re: [PATCH 5/5] add setting gs/fsbase

On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault wrote: > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy. > > > > Interesting; but that one's dealing with the SHARED case, isn't it? > > Yes but I guess it fixed the static case too? We must be talking past each other -- evide

Re: [PATCH 5/5] add setting gs/fsbase

Sergey Bugaev, le jeu. 20 avril 2023 15:05:25 +0300, a ecrit: > On Thu, Apr 20, 2023 at 2:56 PM Samuel Thibault > wrote: > > > > Hello, > > > > Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit: > > > Why was this not an issue for us on i386? > > > > See 56010b73e81e2cb1082e418699f9835

Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

On Thu, Apr 20, 2023 at 7:47 AM Adhemerval Zanella Netto < adhemerval.zane...@linaro.org> wrote: > > > > I am not really sure how effective is this hardening, it seems more a > development one to enforce that system daemon are spawned correctly. > Exactly, my understanding is that it is a futile

Re: [PATCH 5/5] add setting gs/fsbase

On Thu, Apr 20, 2023 at 2:56 PM Samuel Thibault wrote: > > Hello, > > Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit: > > Why was this not an issue for us on i386? > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy. Interesting; but that one's dealing with the SHA

Re: [PATCH 5/5] add setting gs/fsbase

Hello, Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit: > Why was this not an issue for us on i386? See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy. > VM_MAX_USER_ADDRESS, which is defined to VM_MAX_ADDRESS, which is then > defined to 0xc000, same as on i386. T

Re: [PATCH 5/5] add setting gs/fsbase

On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev wrote: > On Wed, Apr 19, 2023 at 10:48 PM Luca Dariz wrote: > > * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and > > implement accessors in thread setstatus/getstatus > > * i386/i386/thread.h: add new state to thread saved state > > *

Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

On 19/04/23 18:16, Sergey Bugaev wrote: > On Wed, Apr 19, 2023 at 11:45 PM Adhemerval Zanella Netto is this really needed now? playing silly games with this fds will always result in silly prices. >> >> My understanding of this code is to enforce that on setuid program with >> stdin/s