| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <3c10189e-4a04-4b67-9cdf-37e24e3086a5@linux.microsoft.com>
Date: Mon, 5 Aug 2024 14:55:38 -0700
From: Roman Kisel <romank@...ux.microsoft.com>
To: Michael Kelley <mhklinux@...look.com>, "arnd@...db.de" <arnd@...db.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"decui@...rosoft.com" <decui@...rosoft.com>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"hpa@...or.com" <hpa@...or.com>, "kw@...ux.com" <kw@...ux.com>,
"kys@...rosoft.com" <kys@...rosoft.com>, "lenb@...nel.org"
<lenb@...nel.org>, "lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>, "rafael@...nel.org"
<rafael@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"wei.liu@...nel.org" <wei.liu@...nel.org>, "will@...nel.org"
<will@...nel.org>, "linux-acpi@...r.kernel.org"
<linux-acpi@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Cc: "apais@...rosoft.com" <apais@...rosoft.com>,
"benhill@...rosoft.com" <benhill@...rosoft.com>,
"ssengar@...rosoft.com" <ssengar@...rosoft.com>,
"sunilmut@...rosoft.com" <sunilmut@...rosoft.com>,
"vdso@...bites.dev" <vdso@...bites.dev>
Subject: Re: [PATCH v3 3/7] Drivers: hv: Provide arch-neutral implementation
of get_vtl()
On 8/5/2024 1:13 PM, Michael Kelley wrote:
> From: Roman Kisel <romank@...ux.microsoft.com> Sent: Monday, August 5, 2024 9:20 AM
>>
>> On 8/4/2024 8:02 PM, Michael Kelley wrote:
>>> From: Roman Kisel <romank@...ux.microsoft.com> Sent: Friday, July 26, 2024 3:59
>> PM
>>>>
>>>> To run in the VTL mode, Hyper-V drivers have to know what
>>>> VTL the system boots in, and the arm64/hyperv code does not
>>>> have the means to compute that.
>>>>
>>>> Refactor the code to hoist the function that detects VTL,
>>>> make it arch-neutral to be able to employ it to get the VTL
>>>> on arm64. Fix the hypercall output address in `get_vtl(void)`
>>>> not to overlap with the hypercall input area to adhere to
>>>> the Hyper-V TLFS.
>>>>
>>>> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
>>>> ---
>>>> arch/x86/hyperv/hv_init.c | 34 ---------------------
>>>> arch/x86/include/asm/hyperv-tlfs.h | 7 -----
>>>> drivers/hv/hv_common.c | 47 ++++++++++++++++++++++++++++--
>>>> include/asm-generic/hyperv-tlfs.h | 7 +++++
>>>> include/asm-generic/mshyperv.h | 6 ++++
>>>> 5 files changed, 58 insertions(+), 43 deletions(-)
>>>>
>>>> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
>>>> index 17a71e92a343..c350fa05ee59 100644
>>>> --- a/arch/x86/hyperv/hv_init.c
>>>> +++ b/arch/x86/hyperv/hv_init.c
>>>> @@ -413,40 +413,6 @@ static void __init hv_get_partition_id(void)
>>>> local_irq_restore(flags);
>>>> }
>>>>
>>>> -#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>>>> -static u8 __init get_vtl(void)
>>>> -{
>>>> - u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS;
>>>> - struct hv_get_vp_registers_input *input;
>>>> - struct hv_get_vp_registers_output *output;
>>>> - unsigned long flags;
>>>> - u64 ret;
>>>> -
>>>> - local_irq_save(flags);
>>>> - input = *this_cpu_ptr(hyperv_pcpu_input_arg);
>>>> - output = (struct hv_get_vp_registers_output *)input;
>>>> -
>>>> - memset(input, 0, struct_size(input, element, 1));
>>>> - input->header.partitionid = HV_PARTITION_ID_SELF;
>>>> - input->header.vpindex = HV_VP_INDEX_SELF;
>>>> - input->header.inputvtl = 0;
>>>> - input->element[0].name0 = HV_X64_REGISTER_VSM_VP_STATUS;
>>>> -
>>>> - ret = hv_do_hypercall(control, input, output);
>>>> - if (hv_result_success(ret)) {
>>>> - ret = output->as64.low & HV_X64_VTL_MASK;
>>>> - } else {
>>>> - pr_err("Failed to get VTL(error: %lld) exiting...\n", ret);
>>>> - BUG();
>>>> - }
>>>> -
>>>> - local_irq_restore(flags);
>>>> - return ret;
>>>> -}
>>>> -#else
>>>> -static inline u8 get_vtl(void) { return 0; }
>>>> -#endif
>>>> -
>>>> /*
>>>> * This function is to be invoked early in the boot sequence after the
>>>> * hypervisor has been detected.
>>>> diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h
>>>> index 3787d26810c1..9ee68eb8e6ff 100644
>>>> --- a/arch/x86/include/asm/hyperv-tlfs.h
>>>> +++ b/arch/x86/include/asm/hyperv-tlfs.h
>>>> @@ -309,13 +309,6 @@ enum hv_isolation_type {
>>>> #define HV_MSR_STIMER0_CONFIG (HV_X64_MSR_STIMER0_CONFIG)
>>>> #define HV_MSR_STIMER0_COUNT (HV_X64_MSR_STIMER0_COUNT)
>>>>
>>>> -/*
>>>> - * Registers are only accessible via HVCALL_GET_VP_REGISTERS hvcall and
>>>> - * there is not associated MSR address.
>>>> - */
>>>> -#define HV_X64_REGISTER_VSM_VP_STATUS 0x000D0003
>>>> -#define HV_X64_VTL_MASK GENMASK(3, 0)
>>>> -
>>>> /* Hyper-V memory host visibility */
>>>> enum hv_mem_host_visibility {
>>>> VMBUS_PAGE_NOT_VISIBLE = 0,
>>>> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
>>>> index 9c452bfbd571..7d6c1523b0b5 100644
>>>> --- a/drivers/hv/hv_common.c
>>>> +++ b/drivers/hv/hv_common.c
>>>> @@ -339,8 +339,8 @@ int __init hv_common_init(void)
>>>> hyperv_pcpu_input_arg = alloc_percpu(void *);
>>>> BUG_ON(!hyperv_pcpu_input_arg);
>>>>
>>>> - /* Allocate the per-CPU state for output arg for root */
>>>> - if (hv_root_partition) {
>>>> + /* Allocate the per-CPU state for output arg for root or a VTL */
>>>> + if (hv_root_partition || IS_ENABLED(CONFIG_HYPERV_VTL_MODE)) {
>>>> hyperv_pcpu_output_arg = alloc_percpu(void *);
>>>> BUG_ON(!hyperv_pcpu_output_arg);
>>>> }
>>>> @@ -656,3 +656,46 @@ u64 __weak hv_tdx_hypercall(u64 control, u64 param1, u64 param2)
>>>> return HV_STATUS_INVALID_PARAMETER;
>>>> }
>>>> EXPORT_SYMBOL_GPL(hv_tdx_hypercall);
>>>> +
>>>> +#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>>>> +u8 __init get_vtl(void)
>>>> +{
>>>> + u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS;
>>>> + struct hv_get_vp_registers_input *input;
>>>> + struct hv_get_vp_registers_output *output;
>>>> + unsigned long flags;
>>>> + u64 ret;
>>>> +
>>>> + local_irq_save(flags);
>>>> + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
>>>> + output = *this_cpu_ptr(hyperv_pcpu_output_arg);
>>>
>>> Rather than use the hyperv_pcpu_output_arg here, it's OK to
>>> use a different area of the hyperv_pcpu_input_arg page. For
>>> example,
>>>
>>> output = (void *)input + HV_HYP_PAGE_SIZE/2;
>>>
>>> The TLFS does not require that the input and output be in
>>> separate pages.
>>>
>>> While using the hyperv_pcpu_output_arg is conceptually a
>>> bit cleaner, doing so requires allocating a 4K page per CPU that
>>> is not otherwise used. The VTL 2 code wants to be frugal with
>>> memory, and this seems like a good step in that direction. :-)
>>>
>> I agree on the both counts: the code looks conceptually cleaner now and
>> VTL2 wants to be frugal with memory, esp that the output hypercall page
>> is per-CPU so we have O(n) as the CPU count increases. Still, the output
>> page will be needed for VTL2 (say to get/set registers just as done
>> here). That said, with this patch we can achieve both the conceptual
>> cleanliness and being ready to grow more on the primitives being built
>> out in the VTL support patches.
>>
>
> Could you elaborate further on why the output page is needed for
> VTL2? The get/set register hypercalls can operate with just the input
> page (again, splitting it into two halves for input and output args) as
> long as the number of registers acted on by a single hypercall isn't
> more than a few dozen.
>
> If you really *do* need the output page in VTL2 for other reasons
> that I'm not aware of, then my suggestion isn't relevant and there's
> no memory to be saved.
VTL2 might potentially use any hypercalls being in some sense an exclave
of the hypervisor living inside the guest quite similarly to the
VBS/VTL1/SecureKernel.
The tradeoff here would be to save a page per processor at the cost of
specializing the hypercall issuing code that would use a part of the
input page to save memory (quite likely limiting which hypercalls can be
used), or use the common implementation at the cost of spending one more
page per processor. Less code means less maintenance usually so seems
beneficial to choose the latter option although at the cost of using
more memory.
>
> Michael
--
Thank you,
Roman
Powered by blists - more mailing lists