linux-kernel - Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

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:	Wed, 4 May 2016 12:36:36 +0200
From:	Borislav Petkov <bp@...e.de>
To:	Alex Thorlton <athorlton@....com>
Cc:	linux-kernel@...r.kernel.org,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-efi@...r.kernel.org, Russ Anderson <rja@....com>,
	Dimitri Sivanich <sivanich@....com>,
	mike travis <travis@....com>, Nathan Zimmer <nzimmer@....com>
Subject: Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to
 isolated page table

On Tue, May 03, 2016 at 01:47:51PM -0500, Alex Thorlton wrote:
> I think this will work for us, for the most part.  Only issue is that
> the efi_call_virt macro is only accessible from inside
> runtime-wrappers.c.  If we could pull that macro (and whatever else it
> needs) up to the header file, I think that might work for us.  Not sure
> if that's the appropriate solution, but it's a start.

Should be doable. You could give it a try and see how ugly it can get.

> Yes, I do have CONFIG_EFI_PGT_DUMP=y.  I don't *think* I see anything
> strange in there, but I could be missing something.  I will send you a
> full dump of my log buffer wit MLs et. al. off of Cc.

Sure.

> Take note that the Oops bits here indicate that it was a *write* from
> kernel space that triggered this most recent Oops, whereas the ones we
> were hitting before were all just missing pages in the mappings.
> 
> This means my suggestiong about the "if(efi_scratch..." bit was wrong.
> This issue is still rolling around in my head.  I'll address it below.

One thing I don't see in your uv_call_virt() is you're not grabbing
efi_runtime_lock like the rest of the EFI callers do. And there's
__wake_up_common() somewhere there in the callstack, not on the current
frame but there's also another uv_bios_call() in there and this all
looks like some locking issue...

So please convert it to the generic one first, do the calls as runtime
services in drivers/firmware/efi/runtime-wrappers.c do and we can
continue debugging.

> This is probably the answer for the future, when we can expect the
> changes to these macros be merged with the mainline kernel, but I don't
> know exactly how long it will be before that happens.

What's the hurry exactly here? You want stuff fixed in 4.6 when it
releases in less than two weeks?

Lemme try to understand the fallout range: that's only UV1 or UV3 too?
Because the latest oops comes from UV3...

If it is UV1 only, I'd say we don't care since you guys wanted to even
kill that support :-)

Btw, does "efi=old_memmap" fix things and could it be used as an interim
workaround until we've fixed everything properly and stuff has trickled
into -stable.?

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--