From mboxrd@z Thu Jan 1 00:00:00 1970 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 83A0AC433EF for ; Wed, 20 Jul 2022 01:08:14 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=b7Ap+0amk/UepFF7xQAnC99GMHL3RXDOw9uEhQ7DckQ=; b=bRWvrU1xplLou1 mlEGjP0gk4Nrnen/IPROScnAV00HC0Bkv8qMddbRrAIhnlwMCYR6BOMXs+ESwfk5tUZ8PY9fyUS+/ biN42Ao21xrjZRoMnTSHozBjPzsNChQR5VWdGBnCK+ZPuzCTiDis/qZ24YhW/8nZBAotvAkQb9MaG divbNW5TMk4JwO4osvqIt9e+Q8qmsTpaq8ucB56v/EkMjNmNjKErvekXz9p6bZeqUp2gOXsTaUNvz JoWrD//xI5omAAggGeUzXM6TyivO8XMpW8tdtupYlIRzB7sEasVr6zxgZt0wMqhi5s6Iv2RODsbCx 2tLU+N/XQnlMEsydFYgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDyBK-00FL3z-LK; Wed, 20 Jul 2022 01:07:18 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDyBF-00FKxC-4L for linux-arm-kernel@lists.infradead.org; Wed, 20 Jul 2022 01:07:14 +0000 Received: by mail-wr1-x436.google.com with SMTP id z13so4424420wro.13 for ; Tue, 19 Jul 2022 18:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RnduJRWap81e4hsQGNaqE2KBoYp4jqdU1O2gWYXksrg=; b=V3L6saNcxDkw3rVUZoKMT+z27A12bbuMUQUtYUo52WpG05ad/Q3Lae9kO9Ssfq5E+o YzXt4abwxGv+dwxD19q182Tuv+jEQ90ytCYm2jfFd5xxWwmkZBRohif67QZtCceM83oi NUU4ZOjD12l69pg3MEeq0C/RyCjh9aJsInnixGl/o8nH/XrKnDYI86aiat2qCbQxSf38 THILLSqte2NlbrOatnLA0liVuydqbpDMtkQWGZdtcz8RmPPLV7Aq4cNotneTAkvZev6r y2dWrfTCTjX2uGv83f5rxxPvXeio8xcWjnvuLCng4BNiGhbO0l7uJp80yX01OHGv+h/M nrqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RnduJRWap81e4hsQGNaqE2KBoYp4jqdU1O2gWYXksrg=; b=jyxc5TLXqhHGVbiPbEKP4A27nnOvZN3q1gkenChNQf1EJxPHWxQug5R7n1fc3AsiKC EdDI1XSsju3YKR+a7iwyccaADF/NlTvr7yusu0ScQxEoM7VY62wLqqSvR6gUSXpXDw2G X6pMmGxaPgVCIj+mdrA/r7KWdp/vt9+Vz9BMgkkVLAdBbUJhbuMaA8vHCWGPrfAlantA L6EAsJfNOJzLT1aMEhvjdjmdWvrqWj1T/FwVRccBRx5Rft7XIaY9MVO8aKaVz7IAoRtU XI+oKGa/XYFlQ/ahl0kiCacpObCzWldTFWtKs5TupW/khG9OJxftlOgcdChRr+lz+eht lcsQ== X-Gm-Message-State: AJIora8aeqUorA0vAQInNNLk4zzqj9SHq7w8yco4AlXSgHVkFpZDsH99 E2h9b4Rg6PRyl5pY6VXeKOuCHEeOcmDhXcvaF1f28Q== X-Google-Smtp-Source: AGRyM1tjfS0I06AEG0F/LzOUouITmNkWGASNHqEfxR822WYDad6jgo6sBqyj7LcYSIIG+kLVswqWoffKMtf3O1YoCYM= X-Received: by 2002:a05:6000:81d:b0:21d:a495:6e3 with SMTP id bt29-20020a056000081d00b0021da49506e3mr28760355wrb.502.1658279227451; Tue, 19 Jul 2022 18:07:07 -0700 (PDT) MIME-Version: 1.0 References: <20220708212106.325260-1-pcc@google.com> <877d49p36n.fsf@redhat.com> In-Reply-To: <877d49p36n.fsf@redhat.com> From: Peter Collingbourne Date: Tue, 19 Jul 2022 18:06:55 -0700 Message-ID: Subject: Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs To: Cornelia Huck Cc: kvmarm@lists.cs.columbia.edu, Marc Zyngier , kvm@vger.kernel.org, Andy Lutomirski , Linux ARM , Michael Roth , Catalin Marinas , Chao Peng , Will Deacon , Evgenii Stepanov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220719_180713_195939_33DB7A66 X-CRM114-Status: GOOD ( 28.56 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jul 19, 2022 at 7:50 AM Cornelia Huck wrote: > > On Fri, Jul 08 2022, Peter Collingbourne wrote: > > > Hi, > > > > This patch series contains a proposed extension to pKVM that allows MTE > > to be exposed to the protected guests. It is based on the base pKVM > > series previously sent to the list [1] and later rebased to 5.19-rc3 > > and uploaded to [2]. > > > > This series takes precautions against host compromise of the guests > > via direct access to their tag storage, by preventing the host from > > accessing the tag storage via stage 2 page tables. The device tree > > must describe the physical memory address of the tag storage, if any, > > and the memory nodes must declare that the tag storage location is > > described. Otherwise, the MTE feature is disabled in protected guests. > > > > Now that we can easily do so, we also prevent the host from accessing > > any unmapped reserved-memory regions without a driver, as the host > > has no business accessing that memory. > > > > A proposed extension to the devicetree specification is available at > > [3], a patched version of QEMU that produces the required device tree > > nodes is available at [4] and a patched version of the crosvm hypervisor > > that enables MTE is available at [5]. > > I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU > patch adds mte-alloc properties to regions that are exposed as a > separate address space (which will not work with KVM). Is the magic in > that new shared section? Hi Cornelia, The intent is that the mte-alloc property may be set on memory whose allocation tag storage is not directly accessible via physical memory, since in this case there is no need for the hypervisor to do anything to protect allocation tag storage before exposing MTE to guests. In the case of QEMU + KVM, I would expect the emulated system to not expose the allocation tag storage directly, in which case it would be able to set mte-alloc on all memory nodes without further action, exactly as my patch implements for TCG. With the interface as proposed, QEMU would need to reject the mte-shared-alloc option when KVM is enabled, as there is currently no mechanism for KVM-accelerated virtualized tag storage. Note that these properties are only relevant for guest kernels running under an emulated EL2 in which pKVM could conceivably run, which means that the host would need to implement FEAT_NV2. As far as I know there is currently no support for NV2 neither in QEMU TCG nor in the Linux kernel, and I'm unaware of any available hardware that supports both NV2 and MTE, so it'll be a while before any of this becomes relevant. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel