[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240701162336.ox6yedgovb7qdwde@desk>
Date: Mon, 1 Jul 2024 09:23:36 -0700
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Brian Gerst <brgerst@...il.com>
Cc: Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
Robert Gill <rtgill82@...il.com>,
Jari Ruusu <jariruusu@...tonmail.com>,
"Linux regression tracking (Thorsten Leemhuis)" <regressions@...mhuis.info>,
antonio.gomez.iglesias@...ux.intel.com,
daniel.sneddon@...ux.intel.com
Subject: Re: [PATCH v2] x86/entry_32: Move CLEAR_CPU_BUFFERS before restoring
segments
On Sat, Jun 29, 2024 at 11:41:07AM -0400, Brian Gerst wrote:
> > #GP(0) - If a memory operand effective address is outside the CS, DS, ES,
> > FS, or GS segment limit.
>
> This isn't limited to just VM86 mode, since any user DS that isn't a
> flat segment can also cause problems.
Right.
> > CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to
> > user space. Add CLEAR_CPU_BUFFERS to the macro RESTORE_REGS before it
> > restores segment registers. In vm86 mode kernel does not support SYSCALL
> > and SYSENTER instructions, so the problem is only limited to int80 path
> > in 32-bit mode. In the opportunistic SYSEXIT path use
> > CLEAR_CPU_BUFFERS_SAFE that ensures a sane %ds value.
>
> The simpler fix is to use an SS segment override (verw
> %ss:mds_verw_sel), since the stack segment is still valid right up to
> the IRET/SYSEXIT.
Thanks a lot, I have verified that your suggestion works. I will send a new
version with your suggestion.
Powered by blists - more mailing lists