linux-kernel - Re: [PATCH] x86/mm, efi: Check for valid image type

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: <20150729164118.GC10114@x>
Date:	Wed, 29 Jul 2015 09:41:18 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>,
	Matt Fleming <matt.fleming@...el.com>, x86@...nel.org,
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mm, efi: Check for valid image type

On Wed, Jul 29, 2015 at 10:30:51AM +0200, Sebastian Andrzej Siewior wrote:
> On 07/29/2015 02:10 AM, josh@...htriplett.org wrote:
> >> On Wed, 22 Jul, at 05:32:44PM, Sebastian Andrzej Siewior wrote:
> >>> now and then. The data behind that pointer changes on each boot because
> >>> nobody preserves the content across kexec.
> > 
> > Right.  The kernel copies this image precisely because it may go away at
> > ExitBootServices or similar, or when ACPI reclaim space is freed.  This
> > ties into the various work about trying to make kexec handle EFI and
> > ACPI.  Is there some way we can indicate to the kexec kernel that this
> > won't work?  (Or fix it so it will?)
> 
> From what I know kexec entry is transparent. Could you remove the table
> from ACPI? There is no point on having this bitmap information now,
> right? The last way out would be to patch kexec and let it read the
> table from /sys and put it at the spot mentioned in the ACPI table.

Assuming that memory isn't already in use.  Seems non-trivial.  Another
alternative would be to patch the address in the ACPI table.  But for a
first pass, I think it'd suffice to just stop attempting to parse the
BGRT at all from the kexec'd kernel.

> >>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> >>> ---
> >>>
> >>> I don't know much about the requirement of having the .bmp in memory all the
> >>> time. Would it be a bad thing to compress the bmp and uncompress on cat from
> >>> userland? In my case the bmp has 272 KiB and LZO gets it down to 12KiB,
> >>> XZ 7.4KiB.
> >>
> >> The usual use for BGRT is to display it during kernel boot, so
> >> interacting with userland doesn't help you there.
> > 
> > If we're going to be storing a large image, applying simple in-kernel
> > compression doesn't seem unreasonable, if we then decompress it when
> > read from the BGRT sysfs file.  That's entirely separate from this issue
> > though.
> 
> This is correct. However I miss the point of saving the image in the
> first place. From what I see is that I have now 272 KiB in memory which
> are never used again. Is there a usecase why we have it? From the code
> it looks like we save it during boot and make it available later via
> sysfs.

That's the point, yes.  A splash screen or an about box can then read it
from there later and display it to the user.

> >>>  arch/x86/platform/efi/efi-bgrt.c | 4 ++++
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> >>> index d7f997f7c26d..59710f0875bb 100644
> >>> --- a/arch/x86/platform/efi/efi-bgrt.c
> >>> +++ b/arch/x86/platform/efi/efi-bgrt.c
> >>> @@ -79,6 +79,10 @@ void __init efi_bgrt_init(void)
> >>>  	memcpy_fromio(&bmp_header, image, sizeof(bmp_header));
> >>>  	if (ioremapped)
> >>>  		early_iounmap(image, sizeof(bmp_header));
> >>> +	if (bmp_header.id != 0x4d42) {
> >>> +		pr_err("BGRT: Not a valid BMP file.\n");
> >>> +		return;
> >>> +	}
> > 
> > That's a good idea as an additional cross-check, but not a complete fix
> > for the problem.
> 
> But it is one additional check to make sure we look at proper data. The
> (ACPI-table) header has an image type which is to BMP (the only
> currently support image type) so this is the double check.

I agree completely with adding the check; I'm just saying it isn't a
complete fix.

> And the
> kernel should be able to read from any address as long as it is within
> its DRAM.

Then what caused the oops on early_ioremap?

> >  As you pointed out above, a wild pointer could cause a
> > WARN from early_ioremap.  We need to never follow the pointer in the
> > first place after a kexec, unless we have some way to know that it's
> > actually valid.
> 
> So you assume that the information from ACPI is always correct then?
> The pointer is correct, the information it points to is no longer.
> 
> If we run always under EFI then it looks like the variable efi_setup
> which is checked in efi_enter_virtual_mode() is 0 during normal boot
> and != 0 on kexec entry. This hint is set via setup_data / SETUP_EFI
> since commit 1fec053369 ("x86/efi: Pass necessary EFI data for kexec
> via setup_data"). So maybe we could use this to check if we run under
> kexec or not.

That sounds like a sensible fix; don't try to parse the BGRT if
efi_setup.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/