linux-kernel - Re: [edk2] Corrupted EFI region

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: <51FFB660.4060400@redhat.com>
Date:	Mon, 05 Aug 2013 16:27:44 +0200
From:	Laszlo Ersek <lersek@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	edk2-devel@...ts.sourceforge.net,
	David Woodhouse <dwmw2@...radead.org>,
	linux-efi@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...hat.com>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [edk2] Corrupted EFI region

On 08/05/13 16:03, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 03:39:31PM +0200, Laszlo Ersek wrote:
>> My question was: is my understanding correct that you only see this
>> problem with "-enable-kvm"? Because,
>>
>> On 08/01/13 18:49, Borislav Petkov wrote:
>>> so I'm seeing this funny thing where an EFI region changes when we
>>> enter efi_enter_virtual_mode when booting with edk2 on kvm. Here's
>>> the diff:
>>
>> You said "on kvm", and provided a diff. I think (hope) I understand the
>> environment you've denoted with "after", but what's your "before"? The
>> absence of "-enable-kvm", or something else?
> 
> Ah, I see.
> 
> So 'before' is the initial dump of the EFI regions, very early during
> boot:

<snip>

> and with 'after' I've denoted the dump of the EFI regions a second time,
> a bit later, when we enter efi_enter_virtual_mode():

<snip>

> 
> during the *same* boot.
> 
> So, it is one boot but two dumps of the EFI regions. And yes, I'm
> booting with the 'kvm' executable which has '-enable-kvm'

Okay. Thanks for clarifying it.

> 
>> What's the purpose of that series? Can you please provide a link (if
>> you posted versions of it already)?
> 
> Not yet posted but working on it.
> 
> The idea is to map the runtime regions at stable addresses so that when
> we kexec a kernel, it can use runtime services too. And we have to do
> that because of the braindead design of SetVirtualAddressMap() being
> callable only once per boot.

I wouldn't call the design of SetVirtualAddressMap() braindead.

I'd rather call kexec unique and somewhat unexpected :)

> 
>>> So what basically happens is the end boundary of the region becomes the
>>> start, practically turning it into a 0-size one.
>>
>> ... and you guys suspect that some firmware code is responsible, code
>> that runs between the initial memory map dump, and efi_enter_virtual_mode():
>>
>> https://lkml.org/lkml/2013/7/31/550
> 
> I wouldn't wonder if we f*cked it up again like the last time. I'll give
> it a long hard look.

Ah sorry, by "and you guys suspect" I didn't mean to imply anything
between the lines, I was simply trying to ascertain your working idea :)

Laszlo
--
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/