From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, brijesh.singh@amd.com
Cc: James Bottomley <jejb@linux.ibm.com>, Min Xu <min.m.xu@intel.com>,
Jiewen Yao <jiewen.yao@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Erdem Aktas <erdemaktas@google.com>
Subject: Re: [edk2-devel] [PATCH RFC v2 05/28] MdePkg: Add AsmPvalidate() support
Date: Wed, 5 May 2021 20:56:00 +0200 [thread overview]
Message-ID: <b4581309-5956-065e-1170-a84dd3784de8@redhat.com> (raw)
In-Reply-To: <2d5e8530-7433-f27e-3a89-9a9ce49bcc08@amd.com>
On 05/04/21 21:07, Brijesh Singh wrote:
>
> On 5/4/21 8:58 AM, Laszlo Ersek wrote:
>> (4) The order of parameters listed in this comment block differs from
>> the actual parameter list.
>>
>> The ECC plugin of the edk2 CI will catch this issue anyway. So,
>> before submitting the patch set to the list, please submit a personal
>> PR on github.com against the main repo, just to run CI on your
>> patches.
>>
> Interestingly I did ran the series with edk2 CI and everything passed
> before I submitted for the review. But, I will go ahead and fix the
> order.
Thank you for being careful up-front -- and then I don't understand this
result. The "EccCheck" plugin is not disabled in
"MdePkg/MdePkg.ci.yaml", and I distinctly remember ECC being incredibly
pedantic about any function leading comment matching the function's
declaration.
Anyway, thanks for updating this, in the next version.
>> Return EFI_UNSUPPORTED (0x8000_0003), or even EFI_NO_MAPPING
>> (0x8000_0017), for value 6 (FAIL_SIZEMISMATCH).
>
> I am not sure if we really want to do this. You will see later in the
> patches that in some cases the PVALIDATE will return a failure and we
> will need to know the failure code to determine the next steps.
> Especially this particular error code is used later. This error
> happens when the page size of the backing pages does not match with
> the pvalidated size. In those cases we need to retry the PVALIDATE
> with lower page size so that a validation succeed. One such a example
> is:
>
> - Guest ask hypervisor to add the page as 2M in RMP table.
>
> - Hypervisor added the page as 512 4K pages - because it was not able
> to find a large backing pages.
>
> - Guest attempts to pvalidate the page as a 2M. The pvalidate will
> return a failure saying its a size mismatch between the requested
> pvalidated and RMP table. The recommendation is that guest should try
> with a smaller page size.
>
> I would prefer to pass the pvalidate error as-is to caller so that it
> can make the correct decision.
My intent is certainly not to mask, or collapse, distinct outputs from
PVALIDATE.
The EFI_STATUS codes that I suggested for AsmPvalidate() keep the
distinct PVALIDATE results distinct. The AMD APM (vol3) describes three
result codes (SUCCESS, FAIL_INPUT, FAIL_SIZEMISMATCH), and I suggested a
*bijective* EFI_STATUS mapping for those -- EFI_SUCCESS,
EFI_INVALID_PARAMETER, and EFI_UNSUPPORTED; in that order.
EFI_NO_MAPPING was only an alternative for EFI_UNSUPPORTED -- in case
you preferred EFI_NO_MAPPING to EFI_UNSUPPORTED, for representing
FAIL_SIZEMISMATCH.
Each one of the EFI_STATUS codes I suggest corresponds uniquely to a
direct PVALIDATE result code (injectivity), and each direct PVALIDATE
result code is covered (surjectivity). So it's a bijection.
CF is only meaningful on output if PVALIDATE succeeds, according to the
AMD APM:
If the instruction completed successfully, the rFLAGS bit CF
indicates if the contents of the RMP entry were changed or not.
Therefore CF should only be checked (and it *can* be checked, via the
BOOLEAN "RmpEntryUpdated" output parameter that I also recommended) if
EFI_SUCCESS is returned by AsmPvalidate().
Furthermore, I *did* check the (sole) AsmPvalidate() call site in the
series, before posting my earlier comment. It goes like this, in patch
#21 ("OvmfPkg/MemEncryptSevLib: Add support to validate system RAM"):
> Ret = AsmPvalidate (RmpPageSize, Validate, Address, &EFlags);
>
> //
> // Check the rFlags.CF to verify that PVALIDATE updated the RMP entry.
> // If there was a no change in the RMP entry then we are either double
> // validating or invalidating the memory. This can lead to a security compromise.
> //
> if (EFlags.Bits.CF) {
> DEBUG ((
> DEBUG_ERROR, "%a:%a: Double %a detected for address 0x%Lx\n",
> gEfiCallerBaseName,
> __FUNCTION__,
> Validate ? "Validate" : "Invalidate",
> Address
> ));
> SnpPageStateFailureTerminate ();
> }
>
> return Ret;
This logic is incorrect, in my opinion. CF should not be checked before
ensuring that Ret equal SUCCESS.
The correct logic for IssuePvalidate() would be:
Status = AsmPvalidate (RmpPageSize, Validate, Address, &RmpEntryUpdated);
if (EFI_ERROR (Status)) {
return Status;
}
if (!RmpEntryUpdated) {
SnpPageStateFailureTerminate ();
}
And then the caller of IssuePvalidate() -- PvalidateRange() -- can rely
on the status codes, returned by IssuePvalidate(), with the following
meanings:
- EFI_SUCCESS: PVALIDATE completed *and* it successfully updated the RMP
entry
- EFI_INVALID_PARAMETER: PVALIDATE failed with FAIL_INPUT (and CF was
meaningless on output)
- EFI_UNSUPPORTED (or EFI_NO_MAPPING, if you like): PVALIDATE failed
with FAIL_SIZEMISMATCH (and CF was meaningless on output); PVALIDATE
should be retried with the small (4K) page size.
I entirely agree with your high-level goal here. My point is that the
mapping that I'm proposing loses *no* information, it is more idiomatic
for edk2, and it's not difficult to implement in assembly.
If you absolutely insist on returning status codes 0, 1, and 6, from
AsmPvalidate(), I can live with that too (although I do think it's a lot
less idiomatic for edk2); in that case however, please make the return
type of AsmPvalidate() UINT32.
(And to repeat: my other point is that the CF checking logic in
IssuePvalidate() is currently wrong, as it relies on a value (CF) which
may be indeterminate in some cases.)
Thanks!
Laszlo
next prev parent reply other threads:[~2021-05-05 18:56 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 11:51 [PATCH RFC v2 00/28] Add AMD Secure Nested Paging (SEV-SNP) support Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 01/28] MdePkg: Expand the SEV MSR to include the SNP definition Brijesh Singh
2021-05-03 8:39 ` [edk2-devel] " Laszlo Ersek
2021-05-03 11:42 ` Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 02/28] MdePkg: Define the GHCB Hypervisor features Brijesh Singh
2021-05-03 10:10 ` [edk2-devel] " Laszlo Ersek
2021-05-03 12:20 ` Brijesh Singh
2021-05-03 13:40 ` Laszlo Ersek
2021-04-30 11:51 ` [PATCH RFC v2 03/28] MdePkg: Define the GHCB GPA structure Brijesh Singh
2021-05-03 10:24 ` [edk2-devel] " Laszlo Ersek
2021-05-03 12:19 ` Laszlo Ersek
2021-05-03 12:55 ` Brijesh Singh
2021-05-03 13:50 ` Laszlo Ersek
2021-05-03 13:55 ` Laszlo Ersek
2021-04-30 11:51 ` [PATCH RFC v2 04/28] MdePkg: Define the Page State Change VMGEXIT structures Brijesh Singh
2021-05-04 12:33 ` [edk2-devel] " Laszlo Ersek
2021-05-04 13:59 ` Laszlo Ersek
2021-05-04 14:48 ` Lendacky, Thomas
2021-05-04 18:07 ` Laszlo Ersek
2021-05-04 18:53 ` Brijesh Singh
2021-05-05 18:24 ` Laszlo Ersek
2021-05-05 19:27 ` Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 05/28] MdePkg: Add AsmPvalidate() support Brijesh Singh
2021-05-04 13:58 ` [edk2-devel] " Laszlo Ersek
2021-05-04 14:09 ` Laszlo Ersek
2021-05-04 19:07 ` Brijesh Singh
2021-05-05 18:56 ` Laszlo Ersek [this message]
[not found] ` <167BF2A01FA60569.6407@groups.io>
2021-05-04 19:55 ` Brijesh Singh
2021-05-05 19:10 ` Laszlo Ersek
[not found] ` <167BF53DA09B327E.22277@groups.io>
2021-05-04 20:28 ` Brijesh Singh
2021-05-04 23:03 ` Brijesh Singh
2021-05-05 19:19 ` Laszlo Ersek
2021-05-05 19:17 ` Laszlo Ersek
2021-04-30 11:51 ` [PATCH RFC v2 06/28] OvmfPkg/BaseMemEncryptSevLib: Introduce MemEncryptSevClearMmioPageEncMask() Brijesh Singh
2021-05-06 10:39 ` [edk2-devel] " Laszlo Ersek
2021-05-06 19:18 ` Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 07/28] OvmfPkg: Use MemEncryptSevClearMmioPageEncMask() to clear EncMask from Mmio Brijesh Singh
2021-05-06 10:50 ` [edk2-devel] " Laszlo Ersek
2021-05-06 19:20 ` Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 08/28] OvmfPkg/BaseMemEncryptSevLib: Remove CacheFlush parameter Brijesh Singh
2021-05-06 11:08 ` [edk2-devel] " Laszlo Ersek
2021-04-30 11:51 ` [PATCH RFC v2 09/28] OvmfPkg/VmgExitLib: Allow PMBASE register access in Dxe phase Brijesh Singh
2021-05-06 14:08 ` [edk2-devel] " Laszlo Ersek
2021-05-06 14:12 ` Laszlo Ersek
2021-05-07 13:29 ` Brijesh Singh
2021-05-07 15:10 ` Laszlo Ersek
2021-05-07 15:19 ` Brijesh Singh
2021-05-07 15:47 ` Laszlo Ersek
2021-04-30 11:51 ` [PATCH RFC v2 10/28] OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled() Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 11/28] OvmfPkg: Reserve Secrets page in MEMFD Brijesh Singh
2021-05-05 6:42 ` [edk2-devel] " Dov Murik
2021-05-05 13:11 ` Brijesh Singh
2021-05-05 19:33 ` Laszlo Ersek
2021-05-06 10:57 ` Dov Murik
2021-05-06 15:06 ` Laszlo Ersek
2021-05-06 16:12 ` James Bottomley
2021-05-06 16:02 ` James Bottomley
2021-04-30 11:51 ` [PATCH RFC v2 12/28] OvmfPkg: Reserve CPUID page for the SEV-SNP guest Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 13/28] OvmfPkg: Validate the data pages used in the Reset vector and SEC phase Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 14/28] UefiCpuPkg: Define the SEV-SNP specific dynamic PCDs Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 15/28] OvmfPkg/MemEncryptSevLib: extend the workarea to include SNP enabled field Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 16/28] OvmfPkg/MemEncryptSevLib: Extend Es Workarea to include hv features Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 17/28] OvmfPkg/ResetVector: Invalidate the GHCB page Brijesh Singh
2021-05-03 13:05 ` Erdem Aktas
2021-05-03 14:28 ` Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 18/28] OvmfPkg: Add a library to support registering GHCB GPA Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 19/28] OvmfPkg: register GHCB gpa for the SEV-SNP guest Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 20/28] UefiCpuPkg/MpLib: add support to register GHCB GPA when SEV-SNP is enabled Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 21/28] OvmfPkg/MemEncryptSevLib: Add support to validate system RAM Brijesh Singh
2021-05-03 14:04 ` Erdem Aktas
2021-05-03 18:56 ` Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 22/28] OvmfPkg/BaseMemEncryptSevLib: Skip the pre-validated " Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 23/28] OvmfPkg/MemEncryptSevLib: Add support to validate > 4GB memory in PEI phase Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 24/28] OvmfPkg/SecMain: Pre-validate the memory used for decompressing Fv Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 25/28] OvmfPkg/PlatformPei: Validate the system RAM when SNP is active Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 26/28] OvmfPkg/MemEncryptSevLib: Change the page state in the RMP table Brijesh Singh
2021-04-30 11:51 ` [PATCH RFC v2 27/28] OvmfPkg/AmdSev: Expose the SNP reserved pages through configuration table Brijesh Singh
2021-05-05 7:10 ` [edk2-devel] " Dov Murik
2021-05-05 19:37 ` Laszlo Ersek
2021-04-30 11:51 ` [PATCH RFC v2 28/28] MdePkg/GHCB: Increase the GHCB protocol max version Brijesh Singh
2021-04-30 16:49 ` [edk2-devel] [PATCH RFC v2 00/28] Add AMD Secure Nested Paging (SEV-SNP) support Laszlo Ersek
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-list 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=b4581309-5956-065e-1170-a84dd3784de8@redhat.com \
--to=devel@edk2.groups.io \
/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