From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 4189B21D046AB for ; Tue, 19 Sep 2017 09:35:03 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id c195so215768itb.1 for ; Tue, 19 Sep 2017 09:38: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=3cbWCOTIJz3LMBLxP4hFgEps6PlE59nQd5fNa1+WEqY=; b=Z0OB6xqERqWo+MIc3X1IoBhriRgN4gWDh2Wv9W+n0yYRac70+wFWw36phYoBUjVVvG 38OHw3wuHheBrR+xICKGcOc1EVJXF9R3bdUhhUI9lzLgqVVk0JZdM/r7CktROxF+B/UA u6ANSRb3T0njH9nbKmjZhBtfgi4HscD+hg4ao= 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=3cbWCOTIJz3LMBLxP4hFgEps6PlE59nQd5fNa1+WEqY=; b=RyiITCB5JXrY2GmHatL9kGZDm7I2L5ajuVJm6L5905dojmvKAPq6/xWASG7nCKf2uF xSeybHPcPldR+qd7V6souQNX/N1gFUJgnLdElUOX6+VDJm8rqFwPX0GFBDdoLjYuYRva LuDhWU/+JLhO6Z69VGWfUZgrd3JzcknF1lfAe01qGwRJWG+NHw3cqRnPPokGHr/b+Cyx K8uNVt8i8RaDicCLhCXp9mQNPYBjbPAGG2z7c5l9rSWwXfRFy/F74dwagtka36G3Dozy 7ZxSL5MVKmhffEyqzYxTxq3xkkw4ZvpGdLgdhYflm/E7BCfxPSFozVJnJAg/rXxSs9Q9 Yzkw== X-Gm-Message-State: AHPjjUj3/E3ZOx3v5/7djQZ8LK6KiYG94oVz1TzWBBANvoBYlt52sUF+ kbOLtYatOReazQySvEELuySB+eqDYQ4egj1y7II+YA== X-Google-Smtp-Source: AOwi7QDDDe9DMTrfNP92ADQ0gZwLVgmXdM7bGUbk5DbHw3N673Dx7Y8n6ptEGZB/w3n9gDF6zWMWlcFLIfkhNjftGYU= X-Received: by 10.36.65.134 with SMTP id b6mr2288109itd.115.1505839087113; Tue, 19 Sep 2017 09:38:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Tue, 19 Sep 2017 09:38:06 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Tue, 19 Sep 2017 09:38:06 -0700 Message-ID: To: Udit Kumar Cc: Vladimir Olovyannikov , "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: Tue, 19 Sep 2017 16:35:03 -0000 Content-Type: text/plain; charset="UTF-8" On 18 September 2017 at 22:28, Udit Kumar wrote: > Thanks Vladimir, > With your design, you did delayed write to eMMC due to sharing with OS. But it works for you:) > Say if eMMC controllers offers you a status bit, if eMMC storage is being used for not. Then this > could be possible to update at run time, both OS/UEFI needs to check and wait if controller is being used. That is the problem right there. The nice thing about a firmware spec is that you don't have to care about how it was implemented if you adhere to the API rules. Imposing additional restrictions (such as requiring the OS to be careful about not using the eMMC when it may be in use by the firmware) defeats the purpose of using UEFI, since you won't be able to use a generic OS anyway. > For sure, some synchronization issues need to be ironed out (or maybe I am just dreaming here). > > On part 2) where you forked VariableRuntime driver , could we think of updating VariableRuntime driver, > to support non-XIP or memory mapped devices. > I think being able to support non-memorymapped FV volumes for the variable store would be a big improvement. This does require changes to both the FaultTolerantWrite drivers and the VariableRuntime drivers, which both appear in PEI, DXE and SMM flavors, and require thorough review due to the security impact bugs have in this layer, so this is a rather large chunk of work to take on.