Re: [PATCH 3/3] x86: Disable running 32bit processes if ia32_disabled is passed

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 08/06/2023 7:16 am, Jiri Slaby wrote:
> On 08. 06. 23, 2:25, Thomas Gleixner wrote:
>> I really wish that we could disable syscall32 reliably on AMD and make
>> it raise #UD as it does on Intal.
>
> Sorry, I am likely missing something, but why is not #GP enough when
> we set CSTAR = 0?

Yeah, don't be setting CSTAR to 0.

If you set CSTAR to 0, and userspace has mapped something at 0, then the
CPU will start executing from 0 in kernel mode.

If you've got SMEP active, this doesn't help.  Instead of executing from
0, you'll take #PF.  Except you were already in kernel mode and #PF
isn't an IST vector, so you'll then start executing the #PF handler on
the same stack as before... which is the user stack, and it can still
hijack execution by hooking a return address.

If you've got (just) SMAP active, then this doesn't help.  The hijacked
execution doesn't need to touch the stack to execute STAC and re-permit
user data accesses.

If you've got SMEP, SMAP, *and* FMASK configured to clear AC
automatically on syscall, then you end up in #DF from a SMEP violation
trying to fetch the code, and a SMAP violation while trying to push the
SMEP violation's #PF IRET frame.


It's almost as if not switching the stack was a terrible terrible idea...

~Andrew