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

[Sergey Bugaev]

On Sat, Apr 22, 2023 at 2:17 PM Luca Dariz <luca@orpolo.org> wrote:
> Hi Sergey,

Hi,

> Il 20/04/23 13:51, Sergey Bugaev ha scritto:
> > On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev <bugaevc@gmail.com> wrote:
> > We do reach the call to __thread_set_state (), but then it uses
> > __mig_memcpy (), which is just 'return memcpy (...)'. And (because of
> > the static build?), that memcpy () is the full real ifunc-selected
> > memcpy. So it jumps to the memcpy@plt, which jumps to
> > *(memcpy@got.plt), which is supposed to jump into the rtld and then
> > run the ifunc resolver and do its smarts and eventually jump to the
> > right memcpy...
>
> I don't know if you already found a good solution for this, but if not
> maybe we could add an x86_64-specific plain syscall to set fsbase/gsbase
> during bootstrap, if it can make things more manageable.

Thank you, but that won't help much, since thread_set_state is not the
only offender, there are more memcpy/memmove calls further (in
RPC_exec_startup_get_info and hurdstartup.c). So we need to solve this
in userspace one way or another.

My pre-filling GOT thing seems to work well, although it hasn't
received any positive feedback from glibc maintainers. Alternatively
we could use Adhemerval Zanella Netto's suggestion to redirect memcpy
to a baseline implementation in some .c files at compile time.

Rather, please look into why device_write () hangs in ast_taken (),
and into enabling > 4 GB address space, and into the crash when not
using console=com0.

Once you figure out the hang in device_write (), I'd like to
experiment with building and running some REPL -- like maybe Python or
Bash or some Lisp; but it needs to work without forking (so Bash
wouldn't really work...) and without accessing any files (Python wants
to load its stdlib from the fs I believe). So please suggest your
favorite REPL :)

Sergey