[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fsbase getting clobbered (was: Re: 64bit startup)

From: Sergey Bugaev
Subject: fsbase getting clobbered (was: Re: 64bit startup)
Date: Fri, 9 Jun 2023 16:58:09 +0300

On Wed, Jun 7, 2023 at 12:15 AM Sergey Bugaev <bugaevc@gmail.com> wrote:
> 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.

Ping? Does the ^above^ make sense?

Other than for fsbase/gsbase that are x86_64-specific, how is this
*supposed* to work, on both i386 and x86_64, for the other members
of the i386/i386/thread.h:struct pcb that are "beyond" our stack
pointer when running on the PCB stack? Beyond, in this case, meaning
lower addresses, so specifically 'struct i386_interrupt_state iis[2];'
is in danger of being spontaneously overwritten. And then after
(before) that, there's some other memory, possibly another struct pcb
allocated in the pcb_cache. So we could be corrupting that too.

Again, how is this *supposed* to work? Possibly there's some mechanism
in place that prevents this that I'm not aware of? If not, then how
come this never causes any issues on i386?

Should we implement some protective measures? Perhaps figure out an
upper limit on the number of bytes that can get pushed should an
interrupt happen, and add an explicit buffer of that size before the

But then is there an upper limit? -- what if yet another interrupt
happens while we're processing the previous one, then another one and
so on? Perhaps we're supposed to turn interrupts off and then back on?

Maybe we can just turn interrupts off while we're on the PCB stack?
>From what I have found online, there is a difference between trap and
interrupt "gates" (whatever those are, I have no clue), and it's that
one of them automatically disables nested interrupts on entry and
reenables them on iret, a lot like a Unix signal gets masked off while
its handler runs (unless you specify SA_NODEFER). Can we make use of
this mechanism? Are we perhaps making use of it already? If so, how is
the corruption issue still happening?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]