lkml.org 
[lkml]   [2021]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v8 08/40] x86/sev: Check the vmpl level
From
Date
On 12/17/21 4:19 PM, Brijesh Singh wrote:
>
> On 12/16/21 5:39 PM, Mikolaj Lisik wrote:
>> On Thu, Dec 16, 2021 at 12:24 PM Venu Busireddy
>> <venu.busireddy@oracle.com> wrote:
>>> On 2021-12-10 09:43:00 -0600, Brijesh Singh wrote:
>>>> Virtual Machine Privilege Level (VMPL) feature in the SEV-SNP architecture
>>>> allows a guest VM to divide its address space into four levels. The level
>>>> can be used to provide the hardware isolated abstraction layers with a VM.
>>>> The VMPL0 is the highest privilege, and VMPL3 is the least privilege.
>>>> Certain operations must be done by the VMPL0 software, such as:
>>>>
>>>> * Validate or invalidate memory range (PVALIDATE instruction)
>>>> * Allocate VMSA page (RMPADJUST instruction when VMSA=1)
>>>>
>>>> The initial SEV-SNP support requires that the guest kernel is running on
>>>> VMPL0. Add a check to make sure that kernel is running at VMPL0 before
>>>> continuing the boot. There is no easy method to query the current VMPL
>>>> level, so use the RMPADJUST instruction to determine whether the guest is
>>>> running at the VMPL0.
>>>>
>>>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>>>> ---
>>>> arch/x86/boot/compressed/sev.c | 34 ++++++++++++++++++++++++++++---
>>>> arch/x86/include/asm/sev-common.h | 1 +
>>>> arch/x86/include/asm/sev.h | 16 +++++++++++++++
>>>> 3 files changed, 48 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
>>>> index a0708f359a46..9be369f72299 100644
>>>> --- a/arch/x86/boot/compressed/sev.c
>>>> +++ b/arch/x86/boot/compressed/sev.c
>>>> @@ -212,6 +212,31 @@ static inline u64 rd_sev_status_msr(void)
>>>> return ((high << 32) | low);
>>>> }
>>>>
>>>> +static void enforce_vmpl0(void)
>>>> +{
>>>> + u64 attrs;
>>>> + int err;
>>>> +
>>>> + /*
>>>> + * There is no straightforward way to query the current VMPL level. The
>>>> + * simplest method is to use the RMPADJUST instruction to change a page
>>>> + * permission to a VMPL level-1, and if the guest kernel is launched at
>>>> + * a level <= 1, then RMPADJUST instruction will return an error.
>>> Perhaps a nit. When you say "level <= 1", do you mean a level lower than or
>>> equal to 1 semantically, or numerically?
>
> Its numerically, please see the AMD APM vol 3.

Actually it is not numerically... if it was numerically, then 0 <= 1
would return an error, but VMPL0 is the highest permission level.

>
> Here is the snippet from the APM RMPAJUST.
>
> IF (TARGET_VMPL <= CURRENT_VMPL)  // Only permissions for numerically

Notice, that the target VMPL is checked against the current VMPL. So if
the target VMPL is numerically less than or equal to the current VMPL
(e.g. you are trying to modify permissions for VMPL1 when you are running
at VMPL2), that is a permission error. So similar to CPL, 0 is the highest
permission followed by 1 then 2 then 3.

Thanks,
Tom

>
>         EAX = FAIL_PERMISSION                // higher VMPL can be modified
>
>         EXIT
>
>
>> +1 to this. Additionally I found the "level-1" confusing which I
>> interpreted as "level minus one".
>>
>> Perhaps phrasing it as "level one", or "level=1" would be more explicit?
>>
> Sure, I will make it clear that its target vmpl level 1 and not (target
> level - 1).
>
> thanks
>
>

\
 
 \ /
  Last update: 2021-12-17 23:34    [W:0.317 / U:0.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site