From: "Laszlo Ersek" <lersek@redhat.com>
To: James Bottomley <jejb@linux.ibm.com>, devel@edk2.groups.io
Cc: dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com,
ashish.kalra@amd.com, brijesh.singh@amd.com, tobin@ibm.com,
david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com,
frankeh@us.ibm.com,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v2 3/6] OvmfPkg: convert ES Reset Block structure to be guided
Date: Mon, 23 Nov 2020 23:16:21 +0100 [thread overview]
Message-ID: <a6a2821a-d4c5-bf84-a5fa-982295a5a41d@redhat.com> (raw)
In-Reply-To: <20201120184521.19437-4-jejb@linux.ibm.com>
On 11/20/20 19:45, James Bottomley wrote:
> Convert the current ES reset block structure to an extensible guid
> based structure by appending a header and length, which allow for
> multiple guid based data packets to be inserted.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
> Signed-off-by: James Bottomley <jejb@linux.ibm.com>
>
> ---
>
> v2: added
> ---
> OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 49 +++++++++++++++-----
> 1 file changed, 38 insertions(+), 11 deletions(-)
(1) Please update the subject line to:
OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDed
- edk2 prefers including module names too in the patch subjects
- "ES" is harder to understand than "SEV-ES"
- "GUIDed" is harder to misread as "guided"
- subject length is still OK (70 chars)
>
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> index 980e0138e7fe..baf9d09f3625 100644
> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> @@ -25,21 +25,40 @@ ALIGN 16
> TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
> %endif
>
> +;
> +; Padding to ensure first guid starts at 0xffffffd0
> +;
> +TIMES (32 - ((guidedStructureEnd - guidedStructureStart) % 32)) DB 0
(2) This will insert 32 zero bytes if the size is already aligned to 32
bytes (because 32-0 = 32). In other words, the above produces 1 to 32
zero bytes, dependent on table size.
The variant I proposed in point (5) at
https://edk2.groups.io/g/devel/message/67621
https://www.redhat.com/archives/edk2-devel-archive/2020-November/msg00781.html
takes this into account, and only prepends 0 to 31 bytes (inclusive):
TIMES (31 - (guidedStructureEnd - guidedStructureStart + 31) % 32) DB 0
- This variant subtracts 1 inside the remainder operation (which is
expressed as adding 31).
- For compensation, it adds 1 just outside of the remainder operation.
This addition in effect increases the subtrahend for the leftmost 32.
Therefore this (-1) addend is ultimately folded into the leftmost 32,
yielding 31 on the leftmost side.
TIMES (32 - ((guidedStructureEnd - guidedStructureStart - 1) % 32 + 1)) DB 0
^^^ ^^^
| |
| compensate
| in the
| remainder
|
slide down residue
class modulo 32
TIMES (32 - ((guidedStructureEnd - guidedStructureStart + 31) % 32) - 1) DB 0
^^^^ ^^^
| |
| unnest
| increment
| from
| subtrahend
|
express modular
subtraction as
addition, to avoid
using % on a negative
integer (in case size
were 0)
TIMES (31 - ((guidedStructureEnd - guidedStructureStart + 31) % 32)) DB 0
^^
|
fold previous (-1) addend into leftmost constant
- This juggling of 1 results in no changes for residue classes 1 through
31, but wraps the outermost result (the padding size) for residue
class 0, from 32 to 0.
> +
> +; Guided structure. To traverse this you should first verify the
> +; presence of the table header guid
(3) suggest "table footer GUID" (the GUID follows the data, in address
order)
> +; (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffffffd0. If that
> +; is found, the two bytes at 0xffffffce are the entire table length.
(4) can we make the whole table size field 32-bit? I don't have a
particular use case in mind, it just looks more extensible than 16-bit.
We can still keep the individual structs we have in mind 16-bit sized.
> +;
> +; The table is composed of structures with the form:
> +;
> +; Data (arbitrary bytes identified by guid)
> +; length from start of guid to end of data (2 bytes)
(5) This is hard to interpret, as "data" precedes "guid" in address
space (guid is a footer, not a header).
I suggest "length from start of data to end of GUID"
> +; guid (16 bytes)
> +;
> +; so work back from the header using the length to traverse until you
(6) suggest "from the footer"
> +; either find the guid you're looking for or run off the end of the
> +; table.
(7) suggest "run off the beginning of the table"
... I realize "start" and "end" can be interpreted temporally and
spatially. In a forward traversal they are the same, but now they
aren't. I suggest we use the spatial (address space order)
interpretation.
> +;
> +guidedStructureStart:
> +
> ;
> ; SEV-ES Processor Reset support
> ;
> ; sevEsResetBlock:
> ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be
> -; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset
> -; and GUID will be used to locate this block in the firmware and extract
> -; the build time RIP value. The GUID must always be 48 bytes from the
> -; end of the firmware.
> +; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. The data
> +; format is
> ;
> -; 0xffffffca (-0x36) - IP value
> -; 0xffffffcc (-0x34) - CS segment base [31:16]
> -; 0xffffffce (-0x32) - Size of the SEV-ES reset block
> -; 0xffffffd0 (-0x30) - SEV-ES reset block GUID
> -; (00f771de-1a7e-4fcb-890e-68c77e2fb44e)
> +; IP value [0:15]
> +; CS segment base [31:16]
> +;
> +; SEV-ES reset block GUID: 00f771de-1a7e-4fcb-890e-68c77e2fb44e
(8) Did I understand from the v1 discussion that the corresponding QEMU
parser is not upstream yet? (Or at least not released?)
(9) The 16-bit size field of the SEV-ES reset block structure is not
documented.
> ;
> ; A hypervisor reads the CS segement base and IP value. The CS segment base
> ; value represents the high order 16-bits of the CS segment base, so the
> @@ -48,8 +67,6 @@ ALIGN 16
> ; program the EIP register with the IP value as read.
> ;
>
> -TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0
> -
> sevEsResetBlockStart:
> DD SEV_ES_AP_RESET_IP
> DW sevEsResetBlockEnd - sevEsResetBlockStart
> @@ -57,6 +74,16 @@ sevEsResetBlockStart:
> DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E
> sevEsResetBlockEnd:
>
> +;
> +; Table header: length of whole table followed by table header
(10) I suggest "table footer" (twice)
> +; guid: 96b582de-1fb2-45f7-baea-a366c55a082d
> +;
> + DW guidedStructureEnd - guidedStructureStart
> + DB 0xDE, 0x82, 0xB5, 0x96, 0xB2, 0x1F, 0xF7, 0x45
> + DB 0xBA, 0xEA, 0xA3, 0x66, 0xC5, 0x5A, 0x08, 0x2D
> +
> +guidedStructureEnd:
> +
> ALIGN 16
>
> applicationProcessorEntryPoint:
>
Thanks!
Laszlo
next prev parent reply other threads:[~2020-11-23 22:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 18:45 [PATCH v2 0/6] SEV Encrypted Boot for Ovmf James Bottomley
2020-11-20 18:45 ` [PATCH v2 1/6] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley
2020-11-23 18:01 ` Laszlo Ersek
2020-11-23 23:25 ` James Bottomley
2020-11-23 23:43 ` Laszlo Ersek
2020-11-20 18:45 ` [PATCH v2 2/6] OvmfPkg/AmdSev: add Grub Firmware Volume Package James Bottomley
2020-11-23 21:08 ` Laszlo Ersek
2020-11-24 6:38 ` James Bottomley
2020-11-24 8:23 ` Laszlo Ersek
2020-11-24 14:54 ` Laszlo Ersek
2020-11-24 15:58 ` Laszlo Ersek
2020-11-24 16:22 ` [edk2-devel] " James Bottomley
2020-11-24 23:22 ` Laszlo Ersek
2020-11-24 23:42 ` James Bottomley
2020-11-25 1:27 ` James Bottomley
2020-11-25 14:01 ` Laszlo Ersek
2020-11-25 16:02 ` James Bottomley
2020-11-25 17:09 ` James Bottomley
2020-11-25 18:17 ` James Bottomley
2020-11-25 19:20 ` Laszlo Ersek
2020-11-25 20:11 ` James Bottomley
2020-11-25 18:35 ` Laszlo Ersek
2020-11-25 19:08 ` Laszlo Ersek
2020-11-25 19:14 ` Laszlo Ersek
2020-11-20 18:45 ` [PATCH v2 3/6] OvmfPkg: convert ES Reset Block structure to be guided James Bottomley
2020-11-23 22:16 ` Laszlo Ersek [this message]
2020-11-24 14:57 ` Lendacky, Thomas
2020-11-24 19:07 ` James Bottomley
2020-11-24 23:19 ` Laszlo Ersek
2020-11-24 19:05 ` James Bottomley
2020-11-24 23:15 ` Laszlo Ersek
2020-11-20 18:45 ` [PATCH v2 4/6] OvmfPkg: create a SEV secret area in the AmdSev memfd James Bottomley
2020-11-23 22:28 ` Laszlo Ersek
2020-11-20 18:45 ` [PATCH v2 5/6] OvmfPkg/AmdSev: assign and protect the Sev Secret area James Bottomley
2020-11-23 22:38 ` Laszlo Ersek
2020-11-20 18:45 ` [PATCH v2 6/6] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table James Bottomley
2020-11-23 22:56 ` 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=a6a2821a-d4c5-bf84-a5fa-982295a5a41d@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