Frankly I am amazed at the amount of poor and misleading information there is on the Internet about this problem. The story exploded like wildfire last week but the reality is that this particular problem had been known for many months if not years. See this kernel bug report for example. The specific Samsung problem that hit the news is detailed here.
Bricking firmware is not a new problem. It has been possible to do so since firmware was invented. The ability to brick a motherboard with UEFI firmware has been known for a long time. I, for example, bricked an Intel DX48BT2 (BoneTrail 2) UEFI motherboard over 2 years ago simply by using the efibootmgr utility. By design, there is a large amount of NVRAM available with UEFI firmware which is used to customize the firmware. The danger is that if you start poking away at memory locations in this NVRAM, you can change the value of variable such that your system firmware will no longer work. You need to know exactly what you are doing when you are working at this level to avoid trouble.
Running out of space in (U)EFI firmware is implementation dependent. The EFI and UEFI specifications are silent on this issue and for good reason. Moreover I suspect that this scenario is not well tested in practice by firmware vendors. The EFI specification does not have an API to test the amount of NVRAM space. The UEFI specification has the query_variable_info API and this API should be always used to query available free space before attempting to write a variable. Unfortunately many applications do not bother to do so and assume that variable space is unlimited.
The current workaround for the Samsung problem was already in the works before the problem was sensationalized by the media. See below:
From: Matt Fleming
Subject: [PATCH 2/2] samsung-laptop: Disable on EFI hardware Date: Mon, 21 Jan 2013 20:40:38 +0000 Cc: < ....> To: firstname.lastname@example.org, email@example.com From: Matt Fleming It has been reported that running this driver on some Samsung laptops with EFI can cause those machines to become bricked as detailed in the following report, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557 There have also been reports of this driver causing Machine Check Exceptions on recent EFI-enabled Samsung laptops, https://bugzilla.kernel.org/show_bug.cgi?id=47121 So disable it if booting from EFI since this driver relies on grovelling around in the BIOS memory map which isn't going to work. Acked-by: H. Peter Anvin Cc: Corentin Chary Cc: Matthew Garrett Cc: Colin Ian King Cc: Steve Langasek Cc: firstname.lastname@example.org Cc: email@example.com Signed-off-by: Matt Fleming --- drivers/platform/x86/samsung-laptop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/x86/samsung-laptop.c b/drivers/platform/x86/samsung-laptop.c index dd90d15..a94c0ee 100644 --- a/drivers/platform/x86/samsung-laptop.c +++ b/drivers/platform/x86/samsung-laptop.c @@ -1534,6 +1534,9 @@ static int __init samsung_init(void) struct samsung_laptop *samsung; int ret; + if (efi_enabled(EFI_BOOT)) + return -ENODEV; + quirks = &samsung_unknown; if (!force && !dmi_check_system(samsung_dmi_table)) return -ENODEV;
As for the Jacob Heinemann blog pointed to by many news articles, did anybody actually take the time to seriously read his post and the UEFI specification before accepting what Heinemann said in his post as being correct?
The real problem was poor coding on the part of Linux kernel developers but nobody is really admitting to that. Just follow the linux-efi mailing list if you wish to see how EFI support is incrementally added to the Linux kernel without any real consideration for existing implementations out there. It is truly an agile development process. Try, fail, try, fail, … You get the idea! Nothing wrong with this process but expect to brick a significant number of motherboards before the codebase firms up.