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 12DE6C43334 for ; Wed, 20 Jul 2022 16:23:03 +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:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U4kTzSUcDelySTmbVqfFmr9OGC5KOYEMLdFe9GuAf6E=; b=RLnunroMrj2Tp/ BGSnjf/s9ouzpZDkV5HRZ1p56omgjei7gR88xHjHIFLL65o9P05FzrldSnQgiSuDf35nL8mFlU4sp 8GVma2pcWbb0RR5RqE9likuvzc8BrwggXvK6vOip6EakSJy71Tr79yejF30UsoTPzd/o4UHg1h9iA G1vx0zwW9JeTuZxz7RukbAey8ai+QBUqNmujNt/eKLlaZxKrXnwjjUE7aATAd3A+yvS9DOzFomAiR rSnb5bRr4WEdcfItK1Kt5v2r2uE5PFi2xnVJq2vCnyiW62diMS3kTUvPqgcLqX/EVjZtlXK13TC/t Uwca2yFfBDZq8qTRLslQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oECSb-0085LG-Ff; Wed, 20 Jul 2022 16:22:05 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oECSX-0085GV-U8 for linux-arm-kernel@lists.infradead.org; Wed, 20 Jul 2022 16:22:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658334117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RNk6IAipo4mh8LBH8MtO8K18i9SdfeqIGL3OSdVhBzg=; b=Z0F5A2QUIyC/nscInPadiTOCfmMGeSNls8Eu/QdtSADbqfONgcWiDk15MJ+64LgD1rOvjI FqdZa9lUo5kv3wmXmk7ZoR3xrumOcx0d/Ht7A7cV0NzqfnOPGKt9PaND38jvSNkaR4cWAZ TT6JOLh3OombROVEfNHAQUsEOKSC2KM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-120-RHYrurhEO5S1XqoXofI7Cw-1; Wed, 20 Jul 2022 12:21:49 -0400 X-MC-Unique: RHYrurhEO5S1XqoXofI7Cw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1877A8037AF; Wed, 20 Jul 2022 16:21:49 +0000 (UTC) Received: from localhost (unknown [10.39.193.129]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2D4E2026614; Wed, 20 Jul 2022 16:21:48 +0000 (UTC) From: Cornelia Huck To: Peter Collingbourne 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 Subject: Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs In-Reply-To: Organization: Red Hat GmbH References: <20220708212106.325260-1-pcc@google.com> <877d49p36n.fsf@redhat.com> User-Agent: Notmuch/0.36 (https://notmuchmail.org) Date: Wed, 20 Jul 2022 18:21:47 +0200 Message-ID: <87k087oiuc.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220720_092202_071436_F28BC567 X-CRM114-Status: GOOD ( 30.81 ) 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, Peter Collingbourne wrote: > 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. Ok, that makes sense. > > 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. Nod. I'm mostly interested because I wanted to figure out how this feature might interact with enabling MTE for QEMU+KVM. I'll keep it in mind. Thanks! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel