On Wed, Jun 7, 2023 at 12:15 AM Sergey Bugaev <buga...@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 iss? 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? Sergey