From: Thomas Gleixner <tglx@linutronix.de>
To: Nikolay Borisov <nik.borisov@suse.com>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, mhocko@suse.com, jslaby@suse.cz,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 3/3] x86: Disable running 32bit processes if ia32_disabled is passed
Date: Wed, 07 Jun 2023 16:49:01 +0200 [thread overview]
Message-ID: <87a5xbjpk2.ffs@tglx> (raw)
In-Reply-To: <ba15bccd-9580-c20e-ae9c-b8d60f49fa07@suse.com>
On Wed, Jun 07 2023 at 16:38, Nikolay Borisov wrote:
> On 7.06.23 г. 15:53 ч., Thomas Gleixner wrote:
>> So why would boottime disabling of IA32_EMULATION affect X32_ABI in any
>> way?
>
> In this case it shouldn't affect it and the check should be
>
> ((elf_check_arch_ia32(x) && !ia32_disabled) ||
> (IS_ENABLED(CONFIG_X86_X32_ABI) && (x)->e_machine == EM_X86_64)).
Correct.
>> 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.
> 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.
Thanks,
tglx
next prev parent reply other threads:[~2023-06-07 14:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 7:29 [RFC PATCH 0/3] Add ability to disable ia32 at boot time Nikolay Borisov
2023-06-07 7:29 ` [PATCH 1/3] x86: Introduce ia32_disabled boot parameter Nikolay Borisov
2023-06-07 8:55 ` Thomas Gleixner
2023-06-07 7:29 ` [PATCH 2/3] x86/entry: Disable IA32 syscalls in the presence of ia32_disabled Nikolay Borisov
2023-06-07 9:11 ` Thomas Gleixner
2023-06-08 3:18 ` Brian Gerst
2023-06-07 7:29 ` [PATCH 3/3] x86: Disable running 32bit processes if ia32_disabled is passed Nikolay Borisov
2023-06-07 12:01 ` Thomas Gleixner
2023-06-07 12:19 ` Nikolay Borisov
2023-06-07 12:53 ` Thomas Gleixner
2023-06-07 13:38 ` Nikolay Borisov
2023-06-07 14:49 ` Thomas Gleixner [this message]
2023-06-07 17:25 ` Andrew Cooper
2023-06-07 21:52 ` Thomas Gleixner
2023-06-07 23:43 ` Andrew Cooper
2023-06-08 0:25 ` Thomas Gleixner
2023-06-08 6:16 ` Jiri Slaby
2023-06-08 6:36 ` Jiri Slaby
2023-06-08 15:30 ` Thomas Gleixner
2023-06-08 15:32 ` Andrew Cooper
2023-06-08 6:29 ` Jiri Slaby
2023-06-08 11:25 ` Andrew Cooper
2023-06-08 15:56 ` Thomas Gleixner
2023-06-08 21:29 ` Nikolay Borisov
2023-06-07 12:55 ` Thomas Gleixner
2023-06-08 4:37 ` Brian Gerst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a5xbjpk2.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andrew.cooper3@citrix.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=nik.borisov@suse.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.