From: Patrick Wildt <patrick@blueri.se>
To: u-boot@lists.denx.de
Subject: [PATCH v3 2/2] efi_loader: identify EFI system partition
Date: Wed, 6 May 2020 14:51:37 +0200 [thread overview]
Message-ID: <20200506125137.GB2983@jump> (raw)
In-Reply-To: <20200422175133.6664-3-xypron.glpk@gmx.de>
On Wed, Apr 22, 2020 at 07:51:33PM +0200, Heinrich Schuchardt wrote:
> In subsequent patches UEFI variables shalled be stored on the EFI system
> partition. Hence we need to identify the EFI system partition.
Hi,
I'm sorry, but, I'm wondering if this is a good idea? The EFI system
partition is just some FAT-Partition, and if the system is using secure
boot and someone happens to manage to mount that partition, then the
variables can be changed pretty easily.
Also I guess changing variables using the Runtime Services would then
try to access the partition? What if the OS is accessing the partition
as well at the same time?
I'm currently storing the U-Boot environment, including the UEFI Secure
Boot environment, on a eMMC partition with a temporary write protect.
This means I cannot change the variables with Runtime Services after
leaving U-Boot, but it also means that an exploit on my OS doesn't
allow the attacker to change the variables, because they are write-
protected until the machine reboots and enters U-Boot again.
I hope we will keep the possibility to store the UEFI variables in
the U-Boot environment, or in some raw sector on the MMC partition,
since otherwise the safety of those variables could be in danger.
Best regards,
Patrick
prev parent reply other threads:[~2020-05-06 12:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 17:51 [PATCH v3 0/2] efi_loader: identify EFI system partition Heinrich Schuchardt
2020-04-22 17:51 ` [PATCH v3 1/2] part: detect " Heinrich Schuchardt
2020-04-22 17:51 ` [PATCH v3 2/2] efi_loader: identify " Heinrich Schuchardt
2020-04-23 0:19 ` AKASHI Takahiro
2020-04-30 5:20 ` Heinrich Schuchardt
2020-05-06 12:51 ` Patrick Wildt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200506125137.GB2983@jump \
--to=patrick@blueri.se \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox