From: Andy Lutomirski <firstname.lastname@example.org> To: Matthew Garrett <email@example.com> Cc: Daniel Kiper <firstname.lastname@example.org>, Ross Philipson <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, the arch/x86 maintainers <email@example.com>, firstname.lastname@example.org, email@example.com, Thomas Gleixner <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, "H. Peter Anvin" <email@example.com>, firstname.lastname@example.org, Ard Biesheuvel <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, James Bottomley <James.Bottomley@hansenpartnership.com>, email@example.com Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support Date: Thu, 26 Mar 2020 13:33:17 -0700 Message-ID: <FE871C2B-15BB-4089-A912-40F2E9FE680B@amacapital.net> (raw) In-Reply-To: <CACdnJutT1F7YJ5KFkyuaZv=nj8GqC+mrnoAsHZfMP1ZRNUQg3Q@mail.gmail.com> > On Mar 26, 2020, at 1:19 PM, Matthew Garrett <firstname.lastname@example.org> wrote: > > On Thu, Mar 26, 2020 at 6:40 AM Daniel Kiper <email@example.com> wrote: >>> On Wed, Mar 25, 2020 at 01:29:03PM -0700, 'Matthew Garrett' via trenchboot-devel wrote: >>> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson >>> <firstname.lastname@example.org> wrote: >>>> To enable the kernel to be launched by GETSEC or SKINIT, a stub must be >>>> built into the setup section of the compressed kernel to handle the >>>> specific state that the late launch process leaves the BSP. This is a >>>> lot like the EFI stub that is found in the same area. Also this stub >>>> must measure everything that is going to be used as early as possible. >>>> This stub code and subsequent code must also deal with the specific >>>> state that the late launch leaves the APs in. >>> >>> How does this integrate with the EFI entry point? That's the expected >> >> It does not. We do not want and need to tie secure launch with UEFI. > > I agree that it shouldn't be required, but it should be possible. We > shouldn't add new entry points that don't integrate with the standard > way of booting the kernel. > >>> What's calling ExitBootServices() in >> >> Currently it is a bootloader, the GRUB which I am working on... OK, this >> is not perfect but if we want to call ExitBootServices() from the kernel >> then we have to move all pre-launch code from the bootloader to the >> kernel. Not nice because then everybody who wants to implement secure >> launch in different kernel, hypervisor, etc. has to re-implement whole >> pre-launch code again. > > We call ExitBootServices() in the EFI stub, so this is fine as long as > the EFI stub hands over control to the SL code. But yes, I think it's > a requirement that it be kernel-owned code calling ExitBootServices(). > >>> this flow, and does the secure launch have to occur after it? It'd be >> >> Yes, it does. > > Ok. The firmware TPM interfaces are gone after ExitBootServices(), so > we're going to need an additional implementation. > >> I think any post-launch code in the kernel should not call anything from >> the gap. And UEFI belongs to the gap. OK, we can potentially re-use UEFI >> TPM code in the pre-launch phase but I am not convinced that we should >> (I am looking at it right now). And this leads us to other question >> which pops up here and there. How to call UEFI runtime services, e.g. to >> modify UEFI variables, update firmware, etc., from MLE or even from the >> OS started from MLE? In my opinion it is not safe to call anything from >> the gap after secure launch. However, on the other hand we have to give >> an option to change the boot order or update the firmware. So, how to >> do that? I do not have an easy answer yet... > > How does Windows manage this? Retaining access to EFI runtime services > is necessary, and the areas in the memory map marked as runtime > services code or data should be considered part of the TCB and > measured - they're very much not part of the gap. As a straw-man approach: make the rule that we never call EFI after secure launch. Instead we write out any firmware variables that we want to change on disk somewhere. When we want to commit those changes, we reboot, commit the changes, and re-launch. Or we deactivate the kernel kexec-style, seal the image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PCRs, and continue on our merry way. I’m not sure how SMM fits in to this whole mess. If we insist on allowing EFI calls and SMM, then we may be able to *measure* our exposure to potentially malicious firmware, but we can’t eliminate it. I personally trust OEM firmware about as far as I can throw it.
next prev parent reply index Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-25 19:43 Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 01/12] x86: Secure Launch Kconfig Ross Philipson 2020-03-26 18:06 ` Daniel Kiper 2020-03-26 19:42 ` Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 02/12] x86: Secure Launch main header file Ross Philipson 2020-03-26 19:00 ` Daniel Kiper 2020-03-25 19:43 ` [RFC PATCH 03/12] x86: Add early SHA support for Secure Launch early measurements Ross Philipson 2020-03-26 3:44 ` Andy Lutomirski 2020-03-26 22:49 ` Daniel P. Smith 2020-03-25 19:43 ` [RFC PATCH 04/12] x86: Add early TPM TIS/CRB interface support for Secure Launch Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 05/12] x86: Add early TPM1.2/TPM2.0 " Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 06/12] x86: Add early general TPM " Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 07/12] x86: Secure Launch kernel early boot stub Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 08/12] x86: Secure Launch kernel late " Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 09/12] x86: Secure Launch SMP bringup support Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 10/12] x86: Secure Launch adding event log securityfs Ross Philipson 2020-03-25 20:21 ` Matthew Garrett 2020-03-25 21:43 ` Daniel P. Smith 2020-03-25 19:43 ` [RFC PATCH 11/12] kexec: Secure Launch kexec SEXIT support Ross Philipson 2020-03-25 19:43 ` [RFC PATCH 12/12] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson 2020-03-25 20:29 ` [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support Matthew Garrett 2020-03-25 22:51 ` Andy Lutomirski 2020-03-26 20:50 ` Daniel P. Smith 2020-03-26 23:13 ` Andy Lutomirski 2020-05-11 19:00 ` Daniel P. Smith 2020-03-26 13:40 ` Daniel Kiper 2020-03-26 20:19 ` Matthew Garrett 2020-03-26 20:33 ` Andy Lutomirski [this message] 2020-03-26 20:40 ` Matthew Garrett 2020-03-26 20:59 ` Daniel P. Smith 2020-03-26 21:07 ` Andy Lutomirski 2020-03-26 21:28 ` Matthew Garrett 2020-03-26 22:52 ` Andy Lutomirski 2020-03-26 22:59 ` Matthew Garrett 2020-03-26 23:04 ` Andy Lutomirski 2020-03-27 0:01 ` Daniel P. Smith 2020-03-26 23:50 ` Daniel P. Smith 2020-05-11 19:00 ` Daniel P. Smith 2020-03-26 20:50 ` Daniel P. Smith 2020-03-26 20:54 ` Matthew Garrett 2020-03-26 22:37 ` Daniel P. Smith 2020-03-26 22:41 ` Matthew Garrett 2020-03-26 23:55 ` Daniel P. Smith
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=FE871C2B-15BB-4089-A912-40F2E9FE680B@amacapital.net \ --email@example.com \ --cc=James.Bottomley@hansenpartnership.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Linux-Doc Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-doc/0 linux-doc/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-doc linux-doc/ https://lore.kernel.org/linux-doc \ email@example.com public-inbox-index linux-doc Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-doc AGPL code for this site: git clone https://public-inbox.org/public-inbox.git