linux-kernel - Re: [PATCH 3/3] x86: Disable running 32bit processes if ia32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <278d7231-ee27-602f-4ba7-45d45d6772b3@citrix.com>
Date:   Thu, 8 Jun 2023 00:43:06 +0100
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Nikolay Borisov <nik.borisov@...e.com>, x86@...nel.org
Cc:     linux-kernel@...r.kernel.org, mhocko@...e.com, jslaby@...e.cz
Subject: Re: [PATCH 3/3] x86: Disable running 32bit processes if ia32_disabled
 is passed

On 07/06/2023 10:52 pm, Thomas Gleixner wrote:
> On Wed, Jun 07 2023 at 18:25, Andrew Cooper wrote:
>> You also have to block Linux from taking any SYSRETL or SYSEXITL path
>> out of the kernel, as these will load fixed 32bit mode attributes into
>> %cs without reference to the GDT.
> That's non-trivial as there is no way to disable 32bit SYSCALL on AMD
> (Intel does not support 32bit syscall and you get #UD if CS.L != 1). So
> to be safe you'd need to make ignore_sysret() kill the process w/o
> returning to user space.

ignore_sysret() desperately needs renaming to entry_SYSCALL32_ignore()
or similar.

And yes, wiring this into SIGSEGV/etc would be a sensible move.

The same applies to 32bit SYSENTER if configured. (Linux doesn't, but
other OSes do.)

> Though arguably if GDT does not have USER32_CS and LDT is disabled (or
> the creation of code segments is blocked) then invoking SYSCALL from
> compat mode requires quite some advanced magic (assumed there are no CPU
> and kernel bugs), no?

Plenty of arcane magic exists.  Rowhammer the GDT, or exploit a VMM, SMM
or ACM bug (all 3 of which can load segments behind the kernel's back),
or Red-Unlock mode which can write the segments registers directly, or
you could play with the AVX512 brownout erratum some more - the
descriptor L bit is only a few bits along from DPL...

But if we're assuming no bugs, then no - I'm not aware of any way of
doing this.  There are only 4 instructions which can reduce privilege:
LRET, IRET, SYSEXIT and SYSRET.

>> And you need to prevent any userspace use of the LDT, which might be as
>> simple as just blocking SYS_modify_ldt, but it's been a while since I
>> last looked.
> CONFIG_MODIFY_LDT_SYSCALL=n is the only in kernel option right now, but
> that could be made boottime disabled trivially. Extending LDT to reject
> the creation of code segments is not rocket science either.
>
> Though the real question is:
>
>        What is the benefit of such a change?
>
> So far I haven't seen any argument for that. Maybe there is none :)

Hardening.  The general purpose distros definitely won't care, but
special purpose ones will.

An x86 bytestream is decoded differently in different modes, and malware
can hide in the differences.  Standard tooling can't cope with
multi-mode binaries, and if it happens by accident you tend get very
obscure crash to diagnose.

Furthermore, despite CET-SS explicitly trying to account for and protect
against accidental mismatches, there are errata in some parts which let
userspace forge legal return addresses on the shadow stack by dropping
into 32bit mode because, there's a #GP check missing in a microflow.

For usecases where there ought not to be any 32bit code at all (and
there absolutely are), it would be lovely if this could be enforced,
rather than relying on blind hope that it doesn't happen.

Thanks,

~Andrew