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 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 840EEC6377B for ; Wed, 21 Jul 2021 21:44:21 +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 4AD8B61264 for ; Wed, 21 Jul 2021 21:44:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4AD8B61264 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=7nt0qY5w4yjbwYT+b/iTiYZtG/z6gEH0nQn4exrbaTI=; b=ek+Yp20RqBCB67 3SfuR1uazDactr7Lgy8rU3pjbpwBcWk6xT3i9mZCY3L60BVXuFdcUSSYXCMIiYULv+XtR2oZ/Ztpe iMTRq4bdlsymstQPQTnRSYc3vWYrwO+RZ8utI4NX/ug6skMb8ixXq0nBR1Z9HmuVaZ/FkBURIHw9x jS9NGkBHZUl6gLqWAQ1EnkGTNZCdtVWZojkim2JYkc3no2fywuvHTB0nOuy7MYUX5I/6JOTvfcRyi 6FWFR69OWgLaZT7h8tWTLpgNXUVKBr42bDA3ZXAlY5a7hcRNzOReUBzGgiHRXh2XR/47KgRqwObOL uaBfbZjJal5YAWjy59Kg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6JzV-00HKl5-Hm; Wed, 21 Jul 2021 21:42:57 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6JzR-00HKk8-Qi for linux-arm-kernel@lists.infradead.org; Wed, 21 Jul 2021 21:42:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626903771; 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=EgnuYo/9YupwfYuRzS/3EAJrECOCz9JZzyHEzGBP/Do=; b=TxxI57Nws2QRCbKFHsuHKV1jv/NciveIegf3zyft8W3FR4mKCjUgNWOmqMTy/ZG4K7c90l pgO/YARcd3/ygbi7qFUFNZTsAWhsrt9ndpLhzoRZ+yQJFFf+Plf2w/E/2ivteGHiB7tqCw jxypONSq+vBOMQ1zwoV92yNjP8pZyUI= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-507-8tl3g47lMpS-hDeV7wd1oA-1; Wed, 21 Jul 2021 17:42:47 -0400 X-MC-Unique: 8tl3g47lMpS-hDeV7wd1oA-1 Received: by mail-il1-f200.google.com with SMTP id h11-20020a056e021b8bb029020d99b97ad3so2337378ili.4 for ; Wed, 21 Jul 2021 14:42:47 -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=EgnuYo/9YupwfYuRzS/3EAJrECOCz9JZzyHEzGBP/Do=; b=HCycIjwnj0HTEJe72CeLRrk/FlMUII0l+vk6QekweIG1b+4vDA/FmvfSfrEev85EZ0 X2TZ3CF9DAqdsUphlhcY+sE+1gbMT4w65P6SbdU01frOIkL9/JR6vt2RuAYuX3Ih4uZu DnGlrffZuzZ5AAO+7/DjpydxVT0mNtr/jGqAky1oV6aiTI5hf4rvLaPF14Y7G0mZQtXw JnHdsVUnXw0mNOKO/2lWUXIFMAqwm6cd1dhUt5wBUILMah/gk+RIPuPEs8W/PX2xNdLS /9LwVj9riEa944EIUny4Xkfj2i8LNYLT5NDGZ2SPFJNYyaSiXcBHCqftP+A83KU83O2Z yHvw== X-Gm-Message-State: AOAM530ksxvy7QluBpaOts9HG88vtLJ7cYs9PoJXcM/VKHOABekGKO9h aPwwXBp0fjakqEaPNbT23gZOK7TaYO4GKYpan6GhZWI6wzvn9m+QKqolXABeHkR9fAGBPCmXJBA 1hv2Lom3hyl0+3/zU3cEnJrB4CGOxRTjhtE0= X-Received: by 2002:a92:cb06:: with SMTP id s6mr26042741ilo.87.1626903767248; Wed, 21 Jul 2021 14:42:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7rBCtquDD6lbxgOm4tFTVO+wR+CyYZ/EAkJBC/eHDwdFdEua1cvqGXWw7KmnzajQrtWPbOw== X-Received: by 2002:a92:cb06:: with SMTP id s6mr26042710ilo.87.1626903766552; Wed, 21 Jul 2021 14:42:46 -0700 (PDT) Received: from gator ([140.82.166.162]) by smtp.gmail.com with ESMTPSA id h13sm12599982ila.44.2021.07.21.14.42.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jul 2021 14:42:45 -0700 (PDT) Date: Wed, 21 Jul 2021 23:42:43 +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: <20210721214243.dy6d644yznuopuqx@gator> References: <20210715163159.1480168-1-maz@kernel.org> MIME-Version: 1.0 In-Reply-To: <20210715163159.1480168-1-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-20210721_144253_996314_3CB7828E X-CRM114-Status: GOOD ( 25.37 ) 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 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. > > This series aims at providing the two sides of the above coin: > > - a set of PV services (collectively called 'MMIO guard' -- better > name required!) where the guest can flag portion of its address > space that it considers as MMIO, with map/unmap semantics. Any > attempt to access a MMIO range outside of these regions will result > in an external abort being injected. > > - a set of hooks into the ioremap code allowing a Linux guest to tell > KVM about things it want to consider as MMIO. I definitely hate this > part of the series, as it feels clumsy and brittle. > > For now, the enrolment in this scheme is controlled by a guest kernel > command-line parameters, but it is expected that KVM will enforce this > for protected VMs. > > Note that this crucially misses a save/restore interface for non > protected VMs, and I currently don't have a good solution for > that. Ideas welcome. > > I also plan to use this series as a base for some other purposes, > namely to trick the guest in telling us how it maps things like > prefetchable BARs (see the discussion at [1]). That part is not > implemented yet, but there is already some provision to pass the MAIR > index across. > > Patches on top of 5.14-rc1, branch pushed at the usual location. > > [1] 20210429162906.32742-1-sdonthineni@nvidia.com The fun never stops. Thanks, drew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel