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]
Date: Mon, 29 Jan 2024 12:06:11 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Tom Lendacky <thomas.lendacky@....com>, Nikita Zhandarovich <n.zhandarovich@...tech.ru>, 
	Kevin Loughlin <kevinloughlin@...gle.com>
Subject: Re: [PATCH] x86/sme: Fix memory encryption if enabled by default and
 not overridden

On Sat, 27 Jan 2024 at 11:53, Borislav Petkov <bp@...en8.de> wrote:
>
> On Fri, Jan 26, 2024 at 05:39:19PM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@...nel.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ