From patchwork Sat Feb 11 01:37:53 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oliver Upton X-Patchwork-Id: 13136685 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8B18AC636D7 for ; Sat, 11 Feb 2023 01:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=X/sGTtlz37hft/NU0vovPK17igPKeilgO4Rscfr7nPI=; b=MQUSUr0quURB/V JlqPl802C+xLjxoYtVRwfzneb3aSJzgnmsE/wBPJnfdh3vWz0O0x+MJseuTqqpCMf+TzD4t5MuHy6 Lz34NjtOm5mAznArdUKurdYa0h+lmQz6CvOovcW7lHzEsinq5t0eBFWq5BZym4gjBBCaD5lIwYmJj OGMzGGLJhYFT3OkykoEEjU1G09PnK+f6mSICvd+gtQ7iVELWUq+K0ut0YkQTVmXr1q2HHdmOHY73p O0tf3196hrI3BfouHr11myz4MImciuug2hlfioPFe6zklxEfKGpMC7y2IxIDQOg+qtew1VFlFEpIj vFKoEPN2q7XgB8bMJZaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQeqH-008ExG-7k; Sat, 11 Feb 2023 01:38:17 +0000 Received: from out-43.mta1.migadu.com ([95.215.58.43]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQeqD-008EwL-R9 for linux-arm-kernel@lists.infradead.org; Sat, 11 Feb 2023 01:38:15 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1676079490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=CMpXcUxTJHME2L8ab5mbFCTDbU8oDNM5KqKoXrCQa4Q=; b=msWQK+owJSCbSpuZ4H6t5EN3riogirr0cEDp0WE2ZxZCc5w9qJUYj0sbkLj2GKC38vkMC4 fd/8J1hYaG/zN4ZrqVcoH11aaQkmKnCygnSMGxl5Lxvfuz1SK0UDmI4ylFhfO5M4FpluDV b6yMRsGnO5Qraixg+/V91GvP4lTQjyA= From: Oliver Upton To: Marc Zyngier Cc: James Morse , Suzuki K Poulose , kvmarm@lists.linux.dev, Akihiko Odaki , Zenghui Yu , Raghavendra Rao Ananta , linux-arm-kernel@lists.infradead.org, Salil Mehta , Oliver Upton Subject: [RFC PATCH v2 0/6] KVM: arm64: Userspace SMCCC call filtering Date: Sat, 11 Feb 2023 01:37:53 +0000 Message-Id: <20230211013759.3556016-1-oliver.upton@linux.dev> MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230210_173814_312967_8627E1CE X-CRM114-Status: GOOD ( 14.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The Arm SMCCC is rather prescriptive in regards to the allocation of SMCCC function ID ranges. Many of the hypercall ranges have an associated specification from Arm (FF-A, PSCI, SDEI, etc.) with some room for vendor-specific implementations. The ever-expanding SMCCC surface leaves a lot of work within KVM for providing new features. Furthermore, KVM implements its own vendor-specific ABI, with little room for other implementations (like Hyper-V, for example). Not only that, it would appear that vCPU hotplug [1] has a legitimate use case for something like this, sending PSCI calls to userspace (where they should have gone in the first place). => We have these new hypercall bitmap registers, why not use that? The hypercall bitmap registers aren't necessarily aimed at the same problem. The bitmap registers allow a VMM to preserve the ABI the guest gets from KVM by default when migrating between hosts. By default KVM exposes the entire feature set to the guest, whereas user SMCCC calls need explicit opt-in from userspace. Applies to 6.2-rc3. TODO: - Reject the ranges of hypercalls we don't want userspace to handle. Spectre crud mainly, any others? I plan on using the invariant of the maple tree to reject filters that intersect with a reserved range. - Should exits for SMC calls have the PC pre-incremented to align with HVC? Go read the comment in handle_smc() if you aren't following. I think the answer is 'yes', but opinions welcome as always :) - This series unifies the SMCCC space for HVCs and SMCs but this requires a lot more thought. Otherwise, we can add support for two separate namespaces. - Testing! I only got as far as compiling this on my machine. At minimum a decent selftest is requried considering the UAPI here is rather involved. RFC v1 -> v2: - Use a range-based interface instead of filtering entire services - Stop using the braindead term of 'trapping' in relation to userspace. Oliver Upton (6): KVM: arm64: Add a helper to check if a VM has ran once KVM: arm64: Add vm fd device attribute accessors KVM: arm64: Refactor hvc filtering to support different actions KVM: arm64: Use a maple tree to represent the SMCCC filter KVM: arm64: Add support for KVM_EXIT_HYPERCALL KVM: arm64: Indroduce support for userspace SMCCC filtering Documentation/virt/kvm/api.rst | 24 +++- Documentation/virt/kvm/devices/vm.rst | 67 ++++++++++ arch/arm64/include/asm/kvm_host.h | 8 +- arch/arm64/include/uapi/asm/kvm.h | 31 +++++ arch/arm64/kvm/arm.c | 35 +++++ arch/arm64/kvm/handle_exit.c | 12 +- arch/arm64/kvm/hypercalls.c | 176 +++++++++++++++++++++++++- arch/arm64/kvm/pmu-emul.c | 4 +- include/kvm/arm_hypercalls.h | 5 + include/uapi/linux/kvm.h | 2 +- 10 files changed, 350 insertions(+), 14 deletions(-) base-commit: b7bfaa761d760e72a969d116517eaa12e404c262