From: Bobby Eshleman <bobbyeshleman@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: michal.zygowski@3mdeb.com, daniel.kiper@oracle.com,
ardb@kernel.org, krystian.hebel@3mdeb.com,
olivier.lambert@vates.fr, piotr.krol@3mdeb.com
Subject: Re: [RFC] UEFI Secure Boot on Xen Hosts
Date: Tue, 19 May 2020 18:39:11 -0500 [thread overview]
Message-ID: <20200519233911.GA22451@piano> (raw)
In-Reply-To: <20200429225108.GA54201@bobbye-pc>
On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
>
> # Option #1: PE/COFF and Shim
>
... snip ...
>
> # Option #3: Lean on Grub2's LoadFile2() Verification
>
... snip ...
It's safe to say that the options boiled down to #1 and #3. Seeing as how we
may not be able to start playing with the new Grub functionality for some time,
and also seeing as how the security properties of each approach are very
similar, I think that option #1 is probably the best path for what we are
looking to achieve in supporting UEFI SB. With out any strong objections
against this, that'll be the path we start heading down (starting with Daniel's
patch set) and will be hoping to get upstream.
If possible, the implementation would support both SHIM_LOCK and LoadFile2(),
potentially by one falling back to other upon reporting a security violation,
or detecting the functionality provided by Grub in some manner... but this
will be easier to evaluate after seeing how the LoadFile2() mechanism will
work.
If LoadFile2() proves itself a better approach, we would not be opposed to
moving in that direction when it is available.
I started joining community calls shortly after the intent of 'docs/design'
was discussed there. Is this a change that merits a 'docs/design' RFC?
Best regards,
Bobby
prev parent reply other threads:[~2020-05-19 23:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 22:51 [RFC] UEFI Secure Boot on Xen Hosts Bobby Eshleman
2020-04-30 7:01 ` Jan Beulich
2020-04-30 11:15 ` Daniel Kiper
2020-04-30 11:41 ` Ard Biesheuvel
2020-05-05 21:58 ` Bobby Eshleman
2020-05-06 6:58 ` Ard Biesheuvel
2020-04-30 22:27 ` Marek Marczykowski-Górecki
2020-04-30 22:42 ` Christopher Clark
2020-05-01 11:59 ` Daniel Kiper
2020-05-01 12:42 ` Marek Marczykowski-Górecki
2020-05-19 23:39 ` Bobby Eshleman [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=20200519233911.GA22451@piano \
--to=bobbyeshleman@gmail.com \
--cc=ardb@kernel.org \
--cc=daniel.kiper@oracle.com \
--cc=krystian.hebel@3mdeb.com \
--cc=michal.zygowski@3mdeb.com \
--cc=olivier.lambert@vates.fr \
--cc=piotr.krol@3mdeb.com \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.