Re: [PATCH] x86/sme: Fix memory encryption if enabled by default and not overridden

From: Ard Biesheuvel <ardb@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Ard Biesheuvel <ardb+git@google.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	 Tom Lendacky <thomas.lendacky@amd.com>,
	Nikita Zhandarovich <n.zhandarovich@fintech.ru>,
	 Kevin Loughlin <kevinloughlin@google.com>
Subject: Re: [PATCH] x86/sme: Fix memory encryption if enabled by default and not overridden
Date: Mon, 29 Jan 2024 12:06:11 +0100	[thread overview]
Message-ID: <CAMj1kXH-RMhkQMWq0jVWbp=UgsE0=k0E-6cMN32rsYuANWY+6w@mail.gmail.com> (raw)
In-Reply-To: <20240127105240.GAZbTgeOwAmYbSfgXR@fat_crate.local>

On Sat, 27 Jan 2024 at 11:53, Borislav Petkov <bp@alien8.de> wrote:
>
> On Fri, Jan 26, 2024 at 05:39:19PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Commit cbebd68f59f0 ("x86/mm: Fix use of uninitialized buffer in
> > sme_enable()") 'fixed' an issue in sme_enable() detected by static
> > analysis, and broke the common case in the process.
> >
> > cmdline_find_option() will return < 0 on an error, or when the command
> > line argument does not appear at all.
>
> Is it just me or cmdline_find_option() should be fixed to return 0 when
> there's no cmdline argument and < 0 only when there was a real error
> parsing?
>
> Hohumm, sounds like a TODO for me or someone who wants to audit all
> callers and fix them up accordingly.
>

I intend to propose removing this occurrence entirely, and move it
into the EFI stub/decompressor.

Parsing external input in security related code when the entire kernel
is still mapped writable is kind of gross, and since I'm cleaning up
the early PIC code anyway, might just as well rip this out.

Another issue here is that it does not honor
CONFIG_CMDLINE_BOOL/CONFIG_CMDLINE_OVERRIDE. I.e., if memory
encryption is enabled by default, and the kernel is configured to
ignore the command line, the current code will still disable memory
encryption when mem_encrypt=off is passed. Probably not a big deal,
but unintuitive nonetheless.

For the other cases, I agree that this would be a good thing to clean
up. Note that someone has been looking into the handling of the
command line recently.

https://lore.kernel.org/all/20231110013817.2378507-6-danielwa@cisco.com/T/#m817c573e25f6f7da237272178a8f6b116192a6ad

but I am not sure what the state of the code is, or whether the
approach is the right one. I was meaning to look at that but haven't
found the time yet.