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

[Sergey Bugaev]

On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault <samuel.thibault@gnu.org> 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 -- evidently it did not fix the
static case, because I'm running into that issue now. On x86_64, that
is; while on i386 it is working for the two reasons I listed.

Moreover, I don't see how it could have changed anything for the
static case. For the shared case, yes, lib*user will now reference
__mig_memcpy from libc.so, and that one needs a simple relocation
without ifunc. For the static case, it's all in the same binary; the
only relocations left after static linking are the ifunc relocations,
and the issue I'm having is different (and happens at an earlier
stage).

Or in other words: the issue I am/was running into was not that ifunc
resolvers wouldn't work because of yet unrelocated _rtld_global_ro or
some such, but that they aren't getting called in the first place.
Instead we fetch some garbage pointers from the GOT *before* they are
initialized by calling the ifunc resolvers, and jump there and
eventually crash. (Or are they not garbage? It's suspicious that they
really point back to the PLT.)

> > > > VM_MAX_USER_ADDRESS, which is defined to VM_MAX_ADDRESS, which is then
> > > > defined to 0xc0000000, same as on i386. That's of course too small.
> > > > Can we bump this substantially?
> > >
> > > Of course !
> >
> > Let me actually try doing #define VM_MAX_ADDRESS KENEL_MAP_BASE...
>
> It doesn't need to be that high :)
>
> And actually it probably cannot: IIRC not all bits can be used in amd64
> virtual addresses anyway.

Yes, but apparently it still works for the kernel? Or is that some
other kind of address?

What would be a correct value then, 1 << 48?

Sergey