Re: Storing Non volatile variables on SD/NAND

[Udit Kumar <udit.kumar@nxp.com>]

Thanks Ard / Jeremy. 

Say SD/NAND is just used for UEFI firmware then this is something doable. 

> > Having the firmware/variable store and OS root/boot on the same device
> > is fundamentally flawed.

I agree in case of SD/NAND, partitioning and synchronization with OS will be tough task. 
Even in case of NOR flash, if this is exposed as mtd device as well, then accessing from 
OS and UEFI poses same challenge .

Thanks
Udit

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Tuesday, September 19, 2017 2:23 AM
> To: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Udit Kumar <udit.kumar@nxp.com>; grant.likely@linaro.org.
> <grant.likely@linaro.org>; edk2-devel@lists.01.org; Olivier.Martin@arm.com
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 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__Regardi
> >>> ng_storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.ht
> >>> ml
> >>>
> >>> 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)