From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E06C221D046C8 for ; Mon, 18 Sep 2017 13:50:04 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g32so5324472ioj.2 for ; Mon, 18 Sep 2017 13:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vwWLpgA94tqCoFb8vm9mCScExvDmelnUoEe2tAQ2sm8=; b=RphcSxWvM+JMB4w0gO6Nm/0I4SUol74ZJ8hrlUajrDugNErW1MV/ojkjm5vU3kr6pc JT/I7TAe2SRISvqSlTQRwiOAKkiCt0cW1qIFczwu4O4q44Vh7J8wclqHIukryXtyPUuf HQK2M4Y+AEmX++j+S588Ge7L5mwVGmF2FDVWo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vwWLpgA94tqCoFb8vm9mCScExvDmelnUoEe2tAQ2sm8=; b=N9rblQbbyiLUvLQolMbRhbGLRAd5qoM+b7ZFkj2FhwxKak2crDbhuNvjn/2CqoLHVu R4hXDkUHU/NjFtDueK0+e1635SQSpc5ViFJwGjRREzlEG6AiJFNDPklmkuLqujkK6bfv OJRSYZFzPz4k28uFyWn+yKXFUUh7R23TkyI08mPSA6+Mkk3z77u5Bp3+b8v64gpMPo5k kH5P8rXpBAexeLQ3pGN8LhTHcmchYHI/UiiyfiRnIs9kG1k9pdmexbLx4AUedzJhWAs6 +B2hbEJwLcw7y85YgxTe3ldr/EovJd+IOuxh53bRcyo5b9Ebq9mRmIi8KnL5aiN5txeO 4KZg== X-Gm-Message-State: AHPjjUjIhqceR9PCQ7Kkbg/SjDfNVMORgOHHpDPQuSC3tJx9LS5cpe5G N5lQSpX9PlJkMtmsJ8E4BzI2s9Cd+qgespCLHv3tiQ== X-Google-Smtp-Source: AOwi7QA0g5DxvShUY3ebFs63ayMxjtvOgCrxVl8ej7YF7xtix9jMdzfUqJMFyKEFkEFCCvBO2IyRyBefiveB+2RGK5M= X-Received: by 10.107.132.226 with SMTP id o95mr6570374ioi.79.1505767987950; Mon, 18 Sep 2017 13:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Mon, 18 Sep 2017 13:53:07 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Mon, 18 Sep 2017 13:53:07 -0700 Message-ID: To: Jeremy Linton Cc: Udit Kumar , "grant.likely@linaro.org." , "edk2-devel@lists.01.org" , "Olivier.Martin@arm.com" Subject: Re: Storing Non volatile variables on SD/NAND X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:50:05 -0000 Content-Type: text/plain; charset="UTF-8" On 18 September 2017 at 13:47, Jeremy Linton wrote: > On 09/18/2017 10:43 AM, Ard Biesheuvel wrote: >> >> On 18 September 2017 at 06:52, Udit Kumar 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)