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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15602C63793 for ; Thu, 22 Jul 2021 13:40:37 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id CC8126135B for ; Thu, 22 Jul 2021 13:40:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC8126135B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1ofhb2h+XXtqmf1hIa25CF0G1Kg4ejepn2CzRgcI620=; b=jrblg1FqTl0STK GZHWnkJPN4U31y3mPcJ5gfWEusMbdShvmAdMWyGejGXIRDG0Wte4yrPzkwHNMmtzZY31utCjxdLdm gUkF1W5bwEvZPqtSmcdqRGPr8mNoEwMQIVHbVAPks4u4alFVCvQPp6qyujlUdJ6nX6jjzGbf0dMg0 HKrGiORAwvlmTJ/zDDEmQA3QeNDAm0PncJNknd+wzQtUpydstWMfL/flCOAxSl31lWbelprP786n7 PHDa6TvjAzX9VmSkrF/olgSRLIyoh+LSYSqRvd4HA/lWlX/sITkJxH94gUzaWEFJVfPN6crgum66U T58vmXnQv0NrI/jEfadw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6Yu6-001hmZ-F3; Thu, 22 Jul 2021 13:38:23 +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 1m6YhY-001eRQ-EL for linux-arm-kernel@lists.infradead.org; Thu, 22 Jul 2021 13:25:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626960322; 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=JAnmeuIfQdncCUiW75D8IzEpkqgkah2ZNrMDpLBYjTo=; b=AXOqw1glkwFMlarx/y/J9F6hP3VVLWC9dMQMeWrob2o0sYPliCo/h3P+pdf8O9aoIsuycI oMEEAfFJ4R8rH/jKA47m6YcVDCGf5WQqQuJmCS/GEgrHpTv8Vm0X+E4PssC6XarfCkgTMA 9t+SDjOKBeE1Ce3PR+Kr50ivqxSRx1w= Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-504-ag0KdyYoOIWF17PspBWBHQ-1; Thu, 22 Jul 2021 09:25:19 -0400 X-MC-Unique: ag0KdyYoOIWF17PspBWBHQ-1 Received: by mail-io1-f71.google.com with SMTP id m14-20020a5d898e0000b02904f7957d92b5so3987707iol.21 for ; Thu, 22 Jul 2021 06:25:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JAnmeuIfQdncCUiW75D8IzEpkqgkah2ZNrMDpLBYjTo=; b=e3E1HgkS+71/PJaaq9mRvGcMxetQ+Rms32f7HX/Jdh6yFxMqaMVjIPHdJNeL3MkQfw onAfSoergUXdQNWHGh6hLy+qi5QrJDUXS+OMrtlrxsYYs9WDUegvAGiY9YDPj6eylwIp OQjGV2tj9oytnHe/psR7FAJilEUOYggfmjoUjO9gQCDcc1LOhAnlf0wUO+45Pc6LUtGK lCPstdI7ltCQLdEMMJTL6vnYwDw3w7IFuoh6R32eSQn4ZY+w7lQW/1j7Z3THKrFgZeqL gd2V0bCc496IKwxAl6yFWZgx0reAvPNL9TALaGZFigJ8rRHQHScsTBnmIjlAkr6HRhgi kTTA== X-Gm-Message-State: AOAM533YReFGVmdreVfBxLqhRONR8HXOE9VAGK9DQ7DWGaRcxgvfzldn 4GfG084dGSbytBjEhB3Zw5DiEL9R3ygBWQ9tf96B2ID/DLqM5TDFxMvAlZLIK/ymHI7J0OkUEqz vOzhVGh7aT4YAYw3YpDCaamYpZRhqJ5tZ0Ts= X-Received: by 2002:a6b:f101:: with SMTP id e1mr17328422iog.118.1626960318897; Thu, 22 Jul 2021 06:25:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzO7B6+/GK3ldKKhKw6OpJsBYn9h5NNBp2v0iNDfsc4BXVWjBxmWixYMqcWppyKDhuCURsoJA== X-Received: by 2002:a6b:f101:: with SMTP id e1mr17328405iog.118.1626960318688; Thu, 22 Jul 2021 06:25:18 -0700 (PDT) Received: from gator ([140.82.166.162]) by smtp.gmail.com with ESMTPSA id z6sm14874865ilz.54.2021.07.22.06.25.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jul 2021 06:25:18 -0700 (PDT) Date: Thu, 22 Jul 2021 15:25:15 +0200 From: Andrew Jones To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, Srivatsa Vaddagiri , Shanker R Donthineni , will@kernel.org Subject: Re: [PATCH 00/16] KVM: arm64: MMIO guard PV services Message-ID: <20210722132515.y66qi23r6ty3anax@gator> References: <20210715163159.1480168-1-maz@kernel.org> <20210721214243.dy6d644yznuopuqx@gator> <874kcm3byd.wl-maz@kernel.org> MIME-Version: 1.0 In-Reply-To: <874kcm3byd.wl-maz@kernel.org> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=drjones@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210722_062524_701981_46039A9F X-CRM114-Status: GOOD ( 29.88 ) 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 Thu, Jul 22, 2021 at 11:00:26AM +0100, Marc Zyngier wrote: > On Wed, 21 Jul 2021 22:42:43 +0100, > Andrew Jones wrote: > > > > On Thu, Jul 15, 2021 at 05:31:43PM +0100, Marc Zyngier wrote: > > > KVM/arm64 currently considers that any memory access outside of a > > > memslot is a MMIO access. This so far has served us very well, but > > > obviously relies on the guest trusting the host, and especially > > > userspace to do the right thing. > > > > > > As we keep on hacking away at pKVM, it becomes obvious that this trust > > > model is not really fit for a confidential computing environment, and > > > that the guest would require some guarantees that emulation only > > > occurs on portions of the address space that have clearly been > > > identified for this purpose. > > > > This trust model is hard for me to reason about. userspace is trusted to > > control the life cycle of the VM, to prepare the memslots for the VM, > > and [presumably] identify what MMIO ranges are valid, yet it's not > > trusted to handle invalid MMIO accesses. I'd like to learn more about > > this model and the userspace involved. > > Imagine the following scenario: > > On top of the normal memory described as memslots (which pKVM will > ensure that userspace cannot access), Ah, I didn't know that part. > a malicious userspace describes > to the guest another memory region in a firmware table and does not > back it with a memslot. > > The hypervisor cannot validate this firmware description (imagine > doing ACPI and DT parsing at EL2...), so the guest starts using this > "memory" for something, and data slowly trickles all the way to EL0. > Not what you wanted. Yes, I see that now, in light of the above. > > To ensure that this doesn't happen, we reverse the problem: userspace > (and ultimately the EL1 kernel) doesn't get involved on a translation > fault outside of a memslot *unless* the guest has explicitly asked for > that page to be handled as a MMIO. With that, we have a full > description of the IPA space contained in the S2 page tables: > > - memory described via a memslot, > - directly mapped device (GICv2, for exmaple), > - MMIO exposed for emulation > > and anything else is an invalid access that results in an abort. > > Does this make sense to you? Now I understand better, but if we're worried about malicious userspaces, then how do we protect the guest from "bad" MMIO devices that have been described to it? The guest can request access to those using this new mechanism. Thanks, drew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel