Re: Storing Non volatile variables on SD/NAND

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 18 September 2017 at 13:47, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 09/18/2017 10:43 AM, Ard Biesheuvel wrote:
>>
>> On 18 September 2017 at 06:52, Udit Kumar <udit.kumar@nxp.com> wrote:
>>>
>>> Hi EDK-2 Experts,
>>> I am looking to store NV variables on SD/NAND device.
>>>
>>> While browsing, I came across some old post at link,
>>>
>>> http://feishare.com/efimail/messages/20130319-1700-Re__edk2__Regarding_storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html
>>>
>>> Looks like, this is possible easily.
>>
>>
>> That's a bold statement dude :-)
>>
>>>>> What you need to support Non-Volatile UEFI variables is a Non-Volatile
>>>>> Memory. And also a driver that implements the EFI Firmware Volume Block
>>>>> protocol for this NVM device.
>>>
>>>
>>> But MdeModulePkg does Copymem from NV variable start memory to some
>>> allocated buffers.  With SD/NAND Copymem is not possible, Is this something
>>> changes since 2013 or there are some other way to use SD/NAND
>>>
>>
>> No, SD/MMC cannot currently be used as the backing store for the EFI
>> variable store. The problem is that the variable protocols are
>> architectural protocols in PI that need to be present before any
>> driver model drivers are dispatched, and so putting the variable store
>> on block devices is not something that the PI software architecture
>> currently supports (unless you reimplement the whole driver stack as
>> DXE drivers).
>>
>> On top of that, it is almost impossible to share a block device that
>> sits behind a controller between the firmware and the OS at runtime
>> (i.e., for SetVariable() calls made by efibootmgr under Linux),
>> because only a single agent can take ownership of the controller at
>> any given time. (You /could/ dedicate the SD/MMC to the firmware
>> entirely, and boot from SATA or USB, but this is out of the question
>> on most platforms that need to use SD/MMC for that variable backing
>> store, i.e., mobile platforms)
>>
>> The best thing would be for you to convince the hardware architects in
>> your company to design and implement dual-ported SD/MMC controllers
>> that allow a single SD/MMC to have two logical views that are
>> independent (although I'm unsure if that is even possible in the
>> context of the SD/MMC specifications)
>
>
> Which still has the problems of selecting "use whole disk" during an OS
> install bricking the machine. Or similarly if the emmc layout isn't just
> right having gparted automatically "fix" the partition table (as it does
> with many of the hikey images) again bricking the machine.
>
> Having the firmware/variable store and OS root/boot on the same device is
> fundamentally flawed. I've went down the path of simply disabling the
> hikey/emmc for use beyond the firmware/variable storage on the hikey. Of
> course I ran smack into the problem of making the block device DXE's
> run-time safe which I've about concluded is far harder than simply writing a
> monolithic variablestore->emmc driver.
>
> The ideal situation for the Hikey, is probably to solder a SPI flash to the
> SPI controller and put the firmware/variable store on that, and leave the
> eMMC entirely for linux's use.
>

Oh, I completely agree that HiKey is a trainwreck in this regard. I
asked for a 96boards mezzanine board with a SPI NOR more than 2 years
ago so we could prototype this stuff properly, but it never
materialized.

But eMMC *can* potentially be used in a meaningful way, if we use a
MMC boot partition for the UEFI image and the RPMB partition for the
variable store (which would arguably be the only way to get a truly
tamper proof *and* rollback protected varstore, which is what you
minimally need to implement UEFI secure boot)