Hi Tom,
On 08/19/19 23:35, Lendacky, Thomas wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> This patch series provides support for running EDK2/OVMF under SEV-ES.
>
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
>
> In order to allow a hypervisor to perform functions on behalf of a guest,
> there is architectural support for notifying a guest's operating system
> when certain types of VMEXITs are about to occur. This allows the guest to
> selectively share information with the hypervisor to satisfy the requested
> function. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
>
> The main areas of the EDK2 code that are updated to support SEV-ES are
> around the exception handling support and the AP boot support.
>
> Exception support is required starting in Sec, continuing through Pei
> and into Dxe in order to handle #VC exceptions that are generated. Each
> AP requires it's own GHCB page as well as a page to hold values specific
> to that AP.
>
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. The GHCB document [2] talks about how SMP
> booting under SEV-ES is performed.
>
> Since the GHCB page must be a shared (unencrypted) page, the processor
> must be running in long mode in order for the guest and hypervisor to
> communicate with each other. As a result, SEV-ES is only supported under
> the X64 architecture.
>
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] https://github.com/AMDESE/ovmf/tree/sev-es-v6
some very high level comments first.
(1) If there is any way, please avoid modifying multiple top-level
directories in a single patch. For example, a patch that currently
modifies both OvmfPkg and UefiCpuPkg, should be split in at least two,
but possibly three, parts. Otherwise, it becomes very difficult to
isolate reviewer responsibilities.
Furthermore, if you can split changes even inside a top-level package
directory, along module boundaries (such that a patch only modify a
single library instance or a driver module, if possible), that's
appreciated.
Clearly this would result in an even larger number of patches in the
series -- for which reason it's usually good to split the series into
"waves" (smaller series). Of course whenever you post a wave, you should
have a functional "whole" (a full stack of waves) in your local tree.
But posting smaller waves is helpful for reviewers (speaking generally),
and the tail of the full work might undergo quite significant updates
due to changes requested for the front.
(2) Please pass "--stat=1000" to git-format-patch. (The additional
"--stat-graph-width=20" option should already be present in your config,
persistently, from running SetupGit.py.) Otherwise, pathnames will be
truncated on the left in the diffstat sections, and that's quite
distracting.
(3) Please consider using "BaseTools/Scripts/GetMaintainer.py", for
determining the set of reviewers for each patch in isolation. Please use
explicit "Cc:" tags in the commit messages. The cover letter should
contain a unified "Cc:" list, also explicitly.
(4) As a general rule, any new memory areas that you access during SEC
and PEI by constant addresses (PCDs) must be considered for S3 resume.
These areas should be reserved from the OS, so that the OS not store
data there, which we'd overwrite during S3. It is also necessary to
guarantee that we never read data from such an area before writing to it
-- in S3, we must not consume any data planted by the OS. So, we should
protect a well-meaning OS during S3, and thwart a malicious OS.
This applies to the new ranges you introduce in [FD.MEMFD]. The current
areas are all covered by PlatformPei explicitly. For details, please
refer to the following document (it could be somewhat out of date, but
the general point stands):
http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
section "A comprehensive memory map of OVMF" -- look for the part saying
"With regard to RAM that is statically used by OVMF, ...".
It's OK if S3 support is out of scope for this work. Even in that case,
the life cycles of the new memory ranges should be investigated and
documented explicitly. If S3 is not to be supported with SEV-ES, then
the S3Verification() function should catch that.
(5) Specifically for the SEC GHCB range: can it be carved out of the
32KB gap at 0x80_8000, i.e. without shuffling around preexistent areas?
(6) Please file a BZ (Product = TianoCore Feature Request) in the
TianoCore bugzilla instance, and assign it to yourself. The patches
should all reference the BZ (in the commit message). The bugzilla should
please contain a high level description of the feature (more or less the
current cover letter). In addition, whenever a new version or wave of
the work is posted to edk2-devel, a mailing list URL should be captured
in the BZ, so that in a few months or years distance, we can see the
posted versions under a single ticket.
Thanks
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#46155): https://edk2.groups.io/g/devel/message/46155
Mute This Topic: https://groups.io/mt/32966274/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-