Messages in this thread | | | Date | Thu, 9 May 2024 18:22:38 -0700 | From | Pawan Gupta <> | Subject | Re: [PATCH] x86/entry_32: Move CLEAR_CPU_BUFFERS before CR3 switch |
| |
On Thu, May 09, 2024 at 05:20:31PM -0700, Dave Hansen wrote: > On 4/26/24 16:48, Pawan Gupta wrote: > > Move the VERW before the CR3 switch for 32-bit kernels as a workaround. > > I look at the 32-bit code so rarely, I seem to forget have to re-learn > this gunk every time I look at it. Take a look at RESTORE_INT_REGS. On > 32-bit, we actually restore %ds: > > popl %ds > > So even doing this: > > > + CLEAR_CPU_BUFFERS > > /* Restore user state */ > > RESTORE_REGS pop=4 # skip orig_eax/error_code > > - CLEAR_CPU_BUFFERS > > .Lirq_return: > > fixes the issue. Moving it above the CR3 switch also works of course, > but I don't think this has anything to do with CR3. It's just that > userspace sets a funky %ds value and CLEAR_CPU_BUFFERS uses ds:.
I will test it out, but I think you are right. VERW documentation says:
#GP(0) If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit.
> I don't think any of the segment registers can have secrets in them, can > they? I mean, it's possible, but in practice I can't imagine.
I don't think so they are secrets. AFAICT, their values are build-time constants, and can be easily deduced.
> So why not just do the CLEAR_CPU_BUFFERS in RESTORE_REGS but after > RESTORE_INT_REGS? You might be able to do it universally, or you could > pass in a macro argument to do it conditionally.
Sounds good. I will try that, possibly tomorrow.
> P.S. Can we remove 32-bit support yet? Please? :)
+1 ... or atleast the mitigations for 32-bit :)
| |