linux-kernel - Re: [RFC PATCH 29/32] KVM: arm64: Pass hypercalls to userspace

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86wn4vynyr.wl-maz@kernel.org>
Date:   Mon, 06 Feb 2023 12:31:40 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     James Morse <james.morse@....com>, linux-pm@...r.kernel.org,
        loongarch@...ts.linux.dev, kvmarm@...ts.linux.dev,
        kvm@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-ia64@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Huacai Chen <chenhuacai@...nel.org>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Len Brown <lenb@...nel.org>,
        Rafael Wysocki <rafael@...nel.org>,
        WANG Xuerui <kernel@...0n.name>,
        Salil Mehta <salil.mehta@...wei.com>,
        Russell King <linux@...linux.org.uk>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>
Subject: Re: [RFC PATCH 29/32] KVM: arm64: Pass hypercalls to userspace

On Mon, 06 Feb 2023 10:10:41 +0000,
Suzuki K Poulose <suzuki.poulose@....com> wrote:
> 
> Hi,
> 
> A few cents from the Realm support point of view.
> 
> On 05/02/2023 10:12, Marc Zyngier wrote:
> > On Fri, 03 Feb 2023 13:50:40 +0000,
> > James Morse <james.morse@....com> wrote:
> >> 
> >> From: Jean-Philippe Brucker <jean-philippe@...aro.org>
> >> 
> >> When capability KVM_CAP_ARM_HVC_TO_USER is available, userspace can
> >> request to handle all hypercalls that aren't handled by KVM. With the
> >> help of another capability, this will allow userspace to handle PSCI
> >> calls.
> >> 
> >> Suggested-by: James Morse <james.morse@....com>
> >> Signed-off-by: Jean-Philippe Brucker <jean-philippe@...aro.org>
> >> Signed-off-by: James Morse <james.morse@....com>
> >> 
> >> ---
> >> 
> > 
> > On top of Oliver's ask not to make this a blanket "steal everything",
> > but instead to have an actual request for ranges of forwarded
> > hypercalls:
> > 
> >> Notes on this implementation:
> >> 
> >> * A similar mechanism was proposed for SDEI some time ago [1]. This RFC
> >>    generalizes the idea to all hypercalls, since that was suggested on
> >>    the list [2, 3].
> >> 
> >> * We're reusing kvm_run.hypercall. I copied x0-x5 into
> >>    kvm_run.hypercall.args[] to help userspace but I'm tempted to remove
> >>    this, because:
> >>    - Most user handlers will need to write results back into the
> >>      registers (x0-x3 for SMCCC), so if we keep this shortcut we should
> >>      go all the way and read them back on return to kernel.
> >>    - QEMU doesn't care about this shortcut, it pulls all vcpu regs before
> >>      handling the call.
> 
> This may not be always possible, e.g., for Realms. GET_ONE_REG is
> not supported. So using an explicit passing down of the args is
> preferrable.

What is the blocker for CCA to use GET_ONE_REG? The value obviously
exists and is made available to the host. pKVM is perfectly able to
use GET_ONE_REG and gets a bunch of zeroes for things that the
hypervisor has decided to hide from the host.

Of course, it requires that the hypervisor (the RMM in your case)
knows about the semantics of the hypercall, but that's obviously
already a requirement (or you wouldn't be able to use PSCI at all).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.