From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 B61DE21D0B662 for ; Wed, 12 Jul 2017 06:59:15 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id 16so3981284qkg.2 for ; Wed, 12 Jul 2017 07:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZPGuo7fvuYFKklwcdrzXBHIW2/E+XrBLBSq+XVZCm0g=; b=UZck+7xFITQ3CVmBMM2O7bgBaeV5pUhlpo/t0jTgaY1DUJnDkojNcCGnEbHEn0zCNd rTQYwos2/aVK9F9Zw3/7a+WRCg+svmDkCMvOEnbhsTol/C9F/fYHdVOF+Ns+3DRjEGWE b/mAZnnU4ZW0IcqrEvjN70uBgPFQKp6nDDMzksRDxI8xqqK9KTgjtB1aID1rBSKAdNeB zEaRzEWYxYNZOQHbNiZa+R7GBk1+wZG3Kp+vlEX7ns2RiNXLBkyCm/n1BYGhtd+4kfQq qsvB6FgJUuxLKQDWC90zZho/VsrSrkMwOY/GkYnAzvGuoRR3SQYg9rvmhZhUqw+oKrRa WeVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=ZPGuo7fvuYFKklwcdrzXBHIW2/E+XrBLBSq+XVZCm0g=; b=qUgHn96GFUcfydb0BDtNB4l3M/aG2Gx7j8sRNprMWlsQSPcrBQMo8IwK2e1MAICX6D PTKEDdD0YGEglUKESD3ItkYV1/g9GXEdtmjrC/D97r/5HCHnrVqpeQP2ju+jhrNmZA3E v/ykZqfa5g/+/W10PPwlv9/YMjRl5cTBnoXLf6FU2G1Fk3pCvjJkrsMV7CYELwkYlbex 0Ow1wbcdvO/IOrAn2yxlWpAY0MlPcNVQAWVszBoUjureJcqYXPPtfDFvd0IMfGyQ9m7+ z64GcjABzFQdvs9V1WI/yfPAKwmGOuIngknRK+f0MV8/epRHs0WtBpjQlKS4RKLUprMS PoKQ== X-Gm-Message-State: AIVw110vH44iKUmFqFz8V1tg4raOGq0/ZSuh3w3vktNbl1ZoTX14KuHU I8kdGPjk7iUmxg== X-Received: by 10.55.190.134 with SMTP id o128mr6305038qkf.58.1499868061664; Wed, 12 Jul 2017 07:01:01 -0700 (PDT) Received: from localhost.localdomain (209-6-200-48.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com. [209.6.200.48]) by smtp.gmail.com with ESMTPSA id s12sm1982537qtc.52.2017.07.12.07.01.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Jul 2017 07:01:00 -0700 (PDT) Sender: Konrad Rzeszutek Date: Wed, 12 Jul 2017 10:00:58 -0400 From: Konrad Rzeszutek Wilk To: Jason Dickens , xen-devel@lists.xenproject.org Cc: Bill Paul , edk2-devel@lists.01.org Message-ID: <20170712140056.GA2415@localhost.localdomain> References: <6703d38b-e99b-c11e-0126-ad24239dacee@grammatech.com> <201707061130.26384.wpaul@windriver.com> <401a788a-49ea-f68f-7ee1-32daa21af3ee@grammatech.com> MIME-Version: 1.0 In-Reply-To: <401a788a-49ea-f68f-7ee1-32daa21af3ee@grammatech.com> User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: OVMF Secure Boot variable storage issue 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: Wed, 12 Jul 2017 13:59:16 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 06, 2017 at 02:55:27PM -0400, Jason Dickens wrote: > Thanks for the response Bill. If I should recognize your name, I'm sorry, > I'm bad with names, but I have been doing a lot of work with Wind River > recently (and in the past) so its possible I should. > > Actually, I should have mentioned I'm using Xen with full virtualization. > This means that OVMF firmware can't change without rebuilding Xen. For > reasons I don't know, it seems the Xen build uses the firmware image by > first converting it to a C array and then compiling it in. > That can be changed - it already has the mechanism to "slurp" binary blobs from the host. The only reason it does that right now is mostly historic - all BIOS images where compiled in 'hvmloader'. > However, I'm not sure that's the real issue. As far as I'm aware, OVMF > implements NvVars on the VM image to provide non-volatile storage instead of > actually modifying the image. As I mentioned, "some" configuration changes > do persist such as changing the screen resolution in the OVMF settings. Also > I can see that NvVars is updating its modification time after setting secure > boot variables. What I'm trying to determine is if there a particular reason > or implementation problem that causes secure boot settings not persist. > > > > On 7/6/2017 2:30 PM, Bill Paul wrote: > > Of all the gin joints in all the towns in all the world, Jason Dickens had to > > walk into mine at 10:31:18 on Thursday 06 July 2017 and say: > > > > > All, > > > > > > I'm trying to understand why the secure boot variables (PK, KEK, db, > > > etc) when using the OVMF build are not retained across reboot? It seems > > > that this code uses roughly the same SetVariable, GetVariable2 approach > > > as say the PlatformConfig uses to store screen resolution (which is > > > retained). Additionally, the NvVars file is being at least touched by > > > the secure boot configuration. So why are none of the keys retained on > > > the next reboot? > > If you're running OVMF in the QEMU simulator, and you're using the -bios > > option, try using the -pflash option instead. > > > > I know that when using -bios, QEMU only pretends to allow writes to the > > firmware region, and if you stop QEMU all changes are discarded. The same > > might be true if you just trigger a hard reboot in the simulator too. > > > > If you use -pflash instead, your changes will be saved. Note that this means > > your OVMF image will be modified, so keep a copy of the original elsewhere so > > that you can start over fresh again if you need to. > > > > (Unfortunately I don't think OVMF has a "load factor defaults" option in its > > internal menus.) > > > > -Bill > > > I know this was an issue in the past, but I haven't found the resolution? > > > > > > Jason > > > > > > > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel