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]

Date:	Wed, 7 Aug 2013 22:23:02 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Andrew Fish <afish@...le.com>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	edk2-devel@...ts.sourceforge.net, Laszlo Ersek <lersek@...hat.com>,
	linux-efi@...r.kernel.org, Gleb Natapov <gleb@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [edk2] Corrupted EFI region

On Wed, Aug 07, 2013 at 02:10:28PM -0700, Andrew Fish wrote:

> Well the issue I see is I don't think OS X or Windows are doing this. 
> So I'm guessing there is some unique thing beings done on the Linux 
> side and we don't have good tests to catch bugs in the EFI 
> implementations. If the Linux loader hides the bugs and we don't hit 
> them with other operating systems they are never going to get fixed. 
> It would be good if we could track down some of these issues and make 
> a request for some tests that can help catch these issues. The tests 
> would be part of UEFI.org, but since some of us play in both worlds we 
> can forward the known issues to the UEFI test work group.

Linux enables NX before calling SetVirtualAddressMap(). If other OSes 
don't do that, you probably won't see the bug.

> Is it possible to have a switch to turn off the not required behavior 
> (hiding EFI implementation bugs) so that bad platforms could be 
> detected? This would be a good thing to try on platforms at the 
> upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI 
> Forum, so the bad behavior can be detected and the vendors can fix the 
> issue.

It's behaviour that we already have to work around due to shipping 
hardware exhibiting it, so while we could certainly develop a test, 
Linux is always going to need to include the workaround code.

That being said, some of what we do with the memory map in Linux right 
now is probably unnecessary - we're modifying the memory map because 
that's a convenient place to store the information, rather than because 
the memory map actually needs to be modified. We could do a better job 
of that.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/