From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Wildt Date: Mon, 18 Nov 2019 07:56:17 +0100 Subject: [U-Boot] [PATCH 12/16] cmd: env: use appropriate guid for authenticated UEFI variable In-Reply-To: <20191118063445.GQ22427@linaro.org> References: <20191113005306.30356-1-takahiro.akashi@linaro.org> <20191113005306.30356-13-takahiro.akashi@linaro.org> <83bed1e9-9047-f263-c77f-d87ce332258a@gmx.de> <20191118063445.GQ22427@linaro.org> Message-ID: <20191118065617.GA13053@nox.fritz.box> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Nov 18, 2019 at 03:34:46PM +0900, AKASHI Takahiro wrote: > Heinrich, > > On Sat, Nov 16, 2019 at 09:10:35PM +0100, Heinrich Schuchardt wrote: > > On 11/13/19 1:53 AM, AKASHI Takahiro wrote: > > >A signature database variable is associated with a specific guid. > > >For convenience, if user doesn't supply any guid info, "env set|print -e" > > >should complement it. > > > > If secure boot is enforced, users should not be able to change any > > security relevant variables. > > I disagree. In fact, UEFI specification allows users to modify > security database variables if their signatures are verified. > For example, "db" must be signed by one of certificates in PK or KEK, > and updating its value will should be authenticated in SetVariable API. > That is what my patch#7 exactly does. > > Thanks, > -Takahiro Akashi I agree. It must be possible for any user of the EFI subsystem to be able to update db/KEK/PK *if* he provides a valid signatures. The thing is that keys are replaced and rerolled, not only because keys were com- promised, but also because some policies say it's useful to replace the keys regularly so that attempts to crack the key have less time to be successfull. There are more use-cases then that, but what is important is that it's possible to change them, if properly signed. Thanks, Patrick