German
English
April 10th, 2013

New Samsung-BIOS: P07RAC ...

... does not change anything! Linux still does not show the efivars, also the NVRAM size is still way to small. Problems are still there - therefore don't think you are safe now. I could not find any changelog, please contact me if you do.

February 22nd, 2013

Samsung Phoenix BIOS UEFI Implementation Bug #2

Further analysis show, that Samsungs UEFI implementation does not seem to follow standards and specifications to strictly. I found some more clues for Samsung mixing UEFI versions 1 and 2. Furthermore the NVRAM size of my firmware seems to be much smaller than the 64 KB requested by Windows 8.

1. Windows 8 NVRAM-Requirements:
Read #28 http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx

Quote:
"28. Mandatory. Reserved Memory for Windows Secure Boot UEFI Variables. A total of at least 64 KB of non-volatile NVRAM storage memory must be reserved for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure Boot and Windows, and the maximum supported variable size must be at least 32kB. There is no maximum NVRAM storage limit."

Using a modified UEFI-Shell v2 I asked my NP300E5C-A05DE for the NVRAM sizes using the function RuntimeServices->QueryVariableInfo()

The available NVRAM size  (upper values) are not even near Microsofts requirements. Not the required 64KB size (first value: 24556 bytes = about 24KB) nor the 32KB per-variable size (last value: 8152 bytes = ca. 8KB) are met.

I have no idea if this hurts Windows 8. I do not know when Windows 8 would need the required sizes. I still don't get it. Samsung recommends Windows 8 for that Notebook on their website.

[Update Februar 24th, 2013:]

I had another thought how that mini NVRAM could eventually make trouble. You should read Matthew Garretts Blog and his windows experiment:  http://mjg59.dreamwidth.org/22855.html. He writes some UEFI variables which bricks his notebook, not even nearly writing 64KB. Sadly Matthew Garrett probably did not check the size of his NVRAM using QueryVariableInfo() - at least he does not mention it. I would bet his UEFI does not support 64KB either.

He also talks about Linux using UEFI NVRAM for crashdumps. Those crashdumps need about 10KB. As you can see my NVRAM just has 11KB left of space (second value, upper row). I can imagine that after a crashdump the NVRAM is almost full. The free space, if any, might not be enough for UEFI to correctly initialize. Maybe that's the porblem. Garrett fills up his NVRAM (because he thinks he has something like 64KB, which is not the case), device wants to reboot, runs in a lack of NVRAM and freezes.

For sure UEFI at least needs to update some NVRAM variables, like "LastBootCurrent" or "BootState". For safety the variable is created completely new and the old one is marked as deleted. So UEFI also needs new space for updating a variable. This would explain bricks with mini NVRAMs, since after a crashdump there might just not be enough space left.

[Update End]

 

2. UEFI 1 vs. UEFI 2

The "malfunction" I found will probably not negatively affect any of you. Still I think it shows how probably careless or naive the UEFI firmware of the notebooks has been programmed.

After I had a working UEFI-Shell v2 when patching that bug found in January I used that shell. Then I realized the command "drivers" is not working correctly. The notebook just gets stuck and does nothing. The "drivers"-command shall list all loaded UEFI drivers. Listing the drivers the last column of the drivers table shows the "DevicePath", the path to the drivers file (which commonly resides inside the firmware). To determine the "DevicePath" of a specific driver, UEFI uses a protocol (as for many things it does), in this case the so called "DEVICE_PATH_PROTOCOL". I am not going to explain the protocol, just some stuff you need: the path which is to be determined is split into DevicePath-sections. These DevicePath-sections are of some type. DevicePath-sections of drivers are of the type "MEDIA_DEVICE_PATH". The sections are chained together for finding out the complete path by following the chain. The paths end is marked by a section of type END_DEVICE_PATH_TYPE (0x7F).

Not at Samsungs. They seem to use some old UEFI 1 type  END_ENTIRE_DEVICE_PATH_TYPE (0xFF). The UEFI-Shell v2 runs into an endless loop for not finding the DevicePaths end. Result: Notebook hangs.

Ok, you can discuss about that. Shall the shell check for the other type too? Or does Samsung use that type improperly? The shell is based on Intel-UEFI, Samsung-UEFI comes from Phoenix. Incompatible?

No. Even at Phoenix' you cannot find that "old type" anymore: http://wiki.phoenix.com/wiki/index.php/EFI_DEVICE_PATH_PROTOCOL
(note: the linked page is dated 2008 - old stuff!)

Samsung uses a Phoenix firmware. Phoenix does not mention the used type, at least not after 2008. Is Samsungs firmware on my new notebook really that old? Or does Samsung re-insert old stuff into their firmwares? Someone enlightens me please!

 

Januar 29th, 2013

Samsung Phoenix BIOS UEFI Implementation Bug 

There does not seem to be any way to contact Samsung for reporting hard- or software related bugs. After I tried for two weeks I want to reveal my knowledge about Samsungs UEFI implementation on their current notebook series.

The Samsung notebook I have is a series 3, NP300E5C-A05DE (German version). Current BIOS version is P06RAC. You can read in some internet forums there are UEFI problems with Linux, that might even brick the devices. In taht case you should send it in if you still have warranty. Be careful to mention Linux, they might tell you about a void warranty for running software not supported by Samsung!

Current Case:

My Samsung Phoenix BIOS supports UEFI-Version 2.3.1, which shall support Windows 8 UEFI boot. BIOS settings are stripped badly, actually you just can turn UEFI-boot on or off. "SecureBoot" is mentioned nowhere. Since my Linux installation runs without SecureBoot and says "no Secureboot" I guess there is none. Well, does not matter. Not being paranoid I would have switched it off anyways for being able to run unsigned bootloaders.

What I can read many people are having problems while installing Linux in UEFI mode or running Live-Distros. I installed it the classic BIOS way without UEFI enabled. After that I switched to UEFI mode (converting MBR partition to GPT, creating an EFI partition, installing EFI-Grub - works!). After switching to UEFI my Linux still worked, but after a week or two I wanted to enter the BIOS setup, which did not work anymore. Nothing F2 could do for me.

What's causing this:

First you need to know a little how UEFI works. All boot entries are no longer managed by your bootloader, which is installed on your hdd, but by UEFI, so the boot entries are directly written to a special data section within your UEFI firmware. When installing a new system, the installer reads all existing boot entries and appends a new one at the end of the list. This surely only works if the installer can read the list of UEFI variables which exist within the data section. All necessary functions for reading and writing or creating are implemented within UEFI in its so called Runtime Services. One of those important functions is GetNextVariableName(). It's used for scanning through all UEFI variables, searching for boot entries. An explanation of that function can be found on http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetNextVariableName.28.29
The implementation in Samsungs UEFI shows some weird behavior. Error code EFI_INVALID_PARAMETER should only be returned, if one of the given pointers to variables is NULL and pointing to an invalid memory section. Samsungs implementation also throughs this error, if the given memory blocksize is not exactly 128 bytes, so for example (like the Linux-efivars module does) 1024 bytes. The Linux module does not expect the strange error code (it checks for NULL pointers itself) and does not report any UEFI variables, no boot entries, no nothing. The installer accepts that and installs the Linux boot entry into the first slot, where actually the boot entry for the setup is located - overwriting that entry! Setup is dead since Linux took its boot entry.

This bug does not only cause Linux to stumble, also UEFI Shell version 2.0 does not start at all. The shell also allocates a larger buffer for the variable name, which causes the shell to exit with error trying to allocation the environment variables within the data section. A small change within the source code and it runs like a charm: Samsung UEFI-Shell 2.0 64Bit (patched 64-bit shell, put in on FAT16/32-USB-stick as /EFI/BOOT/BOOTx64.efi, then boot from stick with UEFI boot switched on)

The error probably has its origin in mixing up UEFI version 1 and 2. In version 1 variable names still had a fixed size of 128 Byte. Version 2 changed this, but Samsung didn't.

Solution:

There is no official solution available. Finally Samsung will have to fix this. Since you can find the source code for the efivars module and the UEFI shell on the internet, a small patch will fix this issue, changing the size to a fixed amount of 128 bytes. Well, this actually is not a good solution, thou. Furthermore I expect more errors to exist within the BIOSes, since this error does not explain complete BIOS bricks.

A patched efivars module suddenly shows UEFI variables in /sys/firmware/efi/vars that were not visible before:

before:

after:

(the "efi2" within the path should be "efi" - I just replaced it for being able to load both modules at the same time)