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: <875d0ab7-4470-25e2-6c01-72e231aae515@citrix.com>
Date:   Wed, 7 Jun 2023 18:25:29 +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 3:49 pm, Thomas Gleixner wrote:
> On Wed, Jun 07 2023 at 16:38, Nikolay Borisov wrote:
>> On 7.06.23 г. 15:53 ч., Thomas Gleixner wrote:
>>>    1) What is the justification for setting the 'present' bit of
>>>       GDT_ENTRY_DEFAULT_USER32_CS to 0?
>> This was something which was suggested by Andrew Cooper on irc, to my 
>> understanding the idea is that by not having a 32bit capable descriptor 
>> it's impossible to run a 32bit code.
> Right, but that's a completely separate change. If it is agreed on then
> it needs to be consistent and not depend on this command line parameter.

And the recommendation was only for debugging purposes.

Segments are not like pagetables.  The present bit is the last of the
checks, not the first, so you'll e.g. get #GP (bad segment type) ahead
of getting #NP[sel].

If you're looking to block 32bit, you should zero the entire GDT entry. 
That way you get #GP to convert into a signal for userspace, rather than
starting down a segment-"paged out" looking route.

>> I guess the scenario where it might be relevant if someone starts a
>> 64bit process and with inline assembly tries to run 32bit code
>> somehow, though it might be a far fetched example and also the fact
>> that the compat_elf_check_arch() forbids loading 32bit processes might
>> be sufficient.
> Guesswork is not helpful. Facts matter.
>
> Fact is that today a 64bit application can do a far jump of far call
> into a 32bit code segment based on the default descriptors or by setting
> them up via LDT. That 32bit code obviously can't do compat syscalls if
> IA32_EMULATION is disabled, but other than that it just works.
>
> Whether that makes sense or not is a completely different question.
>
> Ergo fact is that clearing the present bit is a user space visible
> change, which can't be done nilly willy and burried into a patch
> which is about making CONFIG_IA32_EMULATION a boot time switch.

Removing GDT_ENTRY_DEFAULT_USER32_CS is necessary but not sufficient to
block userspace getting into 32bit mode.

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.

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.

~Andrew