linux-kernel - Re: [PATCH] Modify UEFI anti-bricking code

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: <51AD7B45.1040603@redhat.com>
Date:	Tue, 04 Jun 2013 13:29:41 +0800
From:	Lingzhu Xiang <lxiang@...hat.com>
To:	Matthew Garrett <matthew.garrett@...ula.com>
CC:	rja@....com, mingo@...nel.org, torvalds@...ux-foundation.org,
	bp@...en8.de, jkosina@...e.cz, jlee@...e.com,
	matt.fleming@...el.com, linux-efi@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	hpa@...ux.intel.com, akpm@...ux-foundation.org
Subject: Re: [PATCH] Modify UEFI anti-bricking code

On 06/02/2013 04:06 AM, Matthew Garrett wrote:
> This patch reworks the UEFI anti-bricking code, including an effective
> reversion of cc5a080c and 31ff2f20. It turns out that calling
> QueryVariableInfo() from boot services results in some firmware
> implementations jumping to physical addresses even after entering virtual
> mode, so until we have 1:1 mappings for UEFI runtime space this isn't
> going to work so well.
>
> Reverting these gets us back to the situation where we'd refuse to create
> variables on some systems because they classify deleted variables as "used"
> until the firmware triggers a garbage collection run, which they won't do
> until they reach a lower threshold. This results in it being impossible to
> install a bootloader, which is unhelpful.
>
> Feedback from Samsung indicates that the firmware doesn't need more than
> 5KB of storage space for its own purposes, so that seems like a reasonable
> threshold. However, there's still no guarantee that a platform will attempt
> garbage collection merely because it drops below this threshold. It seems
> that this is often only triggered if an attempt to write generates a
> genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
> create a variable larger than the remaining space. This should fail, but if
> it somehow succeeds we can then immediately delete it.
>
> I've tested this on the UEFI machines I have available, but I don't have
> a Samsung and so can't verify that it avoids the bricking problem.

This patch works well on my Dell Windows 8 logo machine.

This Dell machine will use up ~2K nvram space on each reboot and do 
garbage collection at boot time when full. With the new 5K threshold, it 
is only a few reboots away from boot time garbage collection anyway.

Run time garbage collection also works. But the write takes 5 seconds.


Lingzhu Xiang
--
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/