Re: [RFC PATCH 8/9 gnumach] Add i386_fsgs_base_state

[Sergey Bugaev]

On Sun, Feb 19, 2023 at 12:34 AM Luca <luca@orpolo.org> wrote:
>
> Hi!
>
> Il 18/02/23 21:37, Sergey Bugaev ha scritto:
> > +struct i386_fsgs_base_state {
> > +     unsigned long fs_base;
> > +     unsigned long gs_base;
> > +};
>
> The fs and gs registers are also set by i386_REGS_SEGS_STATE. If they
> are better set separately (as it seems from the other patch, but I don't
> really know the glibc hurd part) should we remove them from the
> i386_REGS_SEGS_STATE case for x86_64, to avoid conflicts?

Hi!

This state controls fs/gs *base* addresses, not the actual values of
the fs/gs registers. Base addresses are used when you use fs- (or gs-)
relative addressing:

mov %fs, %rbx  // rbx = fs (the register itself)
mov %fs:0x1234, %rax  // rax = memory[fs_base + 0x1234] (the base address)

On i386, fs/gs _base addresses_ are set by setting up some segment
descriptors (no idea if that's the correct term) and placing the
segment selector into the fs/gs *register*. On x86_64, you're
apparently not supposed to use segmentation, and instead there is a
MSR that you write to (and read from?) to access fs and gs base
addresses. I don't know whether fs/gs values actually influence
anything, or are relevant/significant for anything on x86_64. I don't
know how segmentation and MSR values interact / don't conflict when a
x86_64 machine runs i386 code (maybe it's dependent on long mode or
something?).

Should the same i386_fsgs_base_state API be made available on i386? On
the one hand, this seems like a nice abstraction, but on the other
hand userland would not be able to use it anyway out of compatibility
concerns -- even now glibc has two different code paths for kernels
that do or do not support i386_{g,s}et_gdt ...

Please also see this discussion from last week:
https://sourceware.org/pipermail/libc-alpha/2023-February/145516.html

And again, I don't really know anything about this, mabe what I'm
saying makes no sense. That's why I'm asking for feedback: whether
this API looks reasonable or not.

Sergey