Re: 64bit startup

[Sergey Bugaev]

On Tue, Jun 6, 2023, 23:56 Luca <luca@orpolo.org> wrote:
> yes this makes perfectly sense, I think I'm chasing the same bug currently, 
> or some variation of it. With some tracing I saw that this corruption seems 
> to happen when an irq (usually timer) fires when returning from a trap, 
> although not necessarily at one specific point.

Yes, a timer is also what I am suspecting; but OTOH the address is
very reproducible for me, it always happens at this specific place,
and that suggests that it might be something other than a timer.

> I still have to find exactly the reason, in my tests fsbase gets overwritten 
> either with a kernel address or 0x17, which might be a segment value. Btw in 
> locore.S the 64-bit-only segment handling code is doing way too much, e.g. 
> es/ds and such could be ignored, I guess simplifying this part may also solve 
> this issue.

That would be a nice mini-optimization (indeed I'm wondering why
!USER32 build still tracks all the segment stuff), but I don't see how
it would help?

If my theory is correct, what we actually do wrong is assuming that
the fsbase value located on the (PCB) stack beyond the %rsp will not
spontaneously change; but in absence of a red zone that's just not
true — anything on your current stack beyond the %rsp can
spontaneously change to any other value at any moment. So one way to
solve this would be keeping fsbase/gsbase someplace else, outside of
i386_saved_state / the PCB stack, especially given that it doesn't
need to be saved and restored like the other registers. The same place
fp and other kinds of state are kept in, perhaps.

Sergey