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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FAADC7618E for ; Mon, 24 Apr 2023 13:48:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B83966B007B; Mon, 24 Apr 2023 09:48:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B33BD6B007D; Mon, 24 Apr 2023 09:48:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FBA26B007E; Mon, 24 Apr 2023 09:48:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 90C976B007B for ; Mon, 24 Apr 2023 09:48:29 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 62AEFAC604 for ; Mon, 24 Apr 2023 13:48:29 +0000 (UTC) X-FDA: 80716414338.08.4ED918B Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf20.hostedemail.com (Postfix) with ESMTP id F11291C0017 for ; Mon, 24 Apr 2023 13:48:24 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mpOXynhl; spf=pass (imf20.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682344107; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VjD0/W6bpStly7qGmOiG+LBZGTGYGwKdNVzP3Gqoe30=; b=0FsWf/HXdtK5Xzd3GFSvIP51rTFPK19ZOyx+TF1uk0navl4NGPnSjAwg4YDqQPI6Bz1+uG 8r39qWYtB00i0Zyd2Zhfcjs6ZDmPkD6v9MEK33eeaJtScFDkblyT3Lh1U8I4P+H/fdlbNL ++iOl/BPqKe1f4IRfIMyZU98xxZVNf0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mpOXynhl; spf=pass (imf20.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682344107; a=rsa-sha256; cv=none; b=rn0GbBJ/raxDTLNGHReNyDZ99XGhHz6i2YfR1+Jj4eL0HSlrkNxNVTY+pNbCcb4J6BzUMn 6icjquwcS4f0b6kCR92XdG+arkDcYHexqUNs7jc9vlP9cngO0k65dEPLrC3X6tXAyXuHyD eTqXSpwsEwRbqw7W9LMMEiQyUjAodbo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1682344106; x=1713880106; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oPqlnm5FAEkzjCzsM5wwOi+X/O97WzQZ5VPCNK7UoWo=; b=mpOXynhlTlGCANnqjsucagPHTSocZFf30oVpX57nxznFs7BZIoVe+C41 xG7NFoTuvrK20XJ4hMbO0RS7ERU6PO3pjHjW2rRTL0ZjhBs7p4WYi1MTR jD9NMWS14eTaLBhjycKrNuhgpqIaaIr819HOWkOFGRmKDWY2TxfVdIRXU HN0TjHqIXdlHeEGV2iXBOpfEG9LS+VflZb7skU8TNCf6rRp+7GO4sj0la IgzY6AVtZLcRbwcqthHyFsqc1qhoSrDh4ZjpfvI09rXc6MvunPTHgoUse i1dRmm3IxGmxpdWXY1w4lQXg6cztuP+TFSaGn0ZexnZx5xDUaJRzSmcsP g==; X-IronPort-AV: E=McAfee;i="6600,9927,10690"; a="346479860" X-IronPort-AV: E=Sophos;i="5.99,222,1677571200"; d="scan'208";a="346479860" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2023 06:48:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10690"; a="693087845" X-IronPort-AV: E=Sophos;i="5.99,222,1677571200"; d="scan'208";a="693087845" Received: from mkavai-mobl2.amr.corp.intel.com (HELO [10.212.196.194]) ([10.212.196.194]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2023 06:48:09 -0700 Message-ID: <81c476f4-ef62-e4a6-0033-8a46a15379fd@intel.com> Date: Mon, 24 Apr 2023 06:48:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [RFC 45/48] RISC-V: ioremap: Implement for arch specific ioremap hooks Content-Language: en-US To: Atish Kumar Patra Cc: linux-kernel@vger.kernel.org, Rajnesh Kanwal , Alexandre Ghiti , Andrew Jones , Andrew Morton , Anup Patel , Atish Patra , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Suzuki K Poulose , Will Deacon , Marc Zyngier , Sean Christopherson , linux-coco@lists.linux.dev, Dylan Reid , abrestic@rivosinc.com, Samuel Ortiz , Christoph Hellwig , Conor Dooley , Greg Kroah-Hartman , Guo Ren , Heiko Stuebner , Jiri Slaby , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Mayuresh Chitale , Palmer Dabbelt , Paolo Bonzini , Paul Walmsley , Uladzislau Rezki References: <20230419221716.3603068-1-atishp@rivosinc.com> <20230419221716.3603068-46-atishp@rivosinc.com> <69ba1760-a079-fd8f-b079-fcb01e3eedec@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F11291C0017 X-Stat-Signature: erehyfywy7hn8e6op9oijuagb4kix6n1 X-Rspam-User: X-HE-Tag: 1682344104-498457 X-HE-Meta: U2FsdGVkX1/KSk/kgQt+4+8IJCyrNpUjXl9v+ao8FKhfnPtk6bozvyWVBO9jEcXhDv/grops+M1BqlpkRvHZ9jxG731UHvPl7MwfRgVzxpg+bI8amfWlFhV5fJzBAgh0l9WlHULKAN59Mu1dZr+qz1R+pXh1eaQM8MVbl3Fpe3B1rs2UpDknUetFtDKx3vhw+JuV83Os4THQiCa4t3ilXvwQF3XApaofHwMC8+tKbf4TtJJHp7mVhx6diPA6zaUDWNYzkxadwuuX91+UtX83beUnpC6Wooxg1glNsFk0pfPy197Jgb83LKKHucf7vXth1gVo3H6uG581z/fgEaalDnj4KeRRZXH6l6w2RPgAPNf4f4qgFGNQmV61gV3oFPaWMuSQPqOLnUT6n2uWnauX49NAK+7agEoP0qce/XTsb9qC7hwUpO98KTAEOSZ8Xx5CSil7cXxjgr9mRF6q1v5yAQrK3pq1GCWuKlUVk7GjpgE3CAg9/aRDmV/8iK+Zq8frTzRYzCs4AiO3x2Qy+eTrwSwRRotdu9lb7vUlxKHI7+WE7Ab+m/i/PH1SIG/ZxPqFJSpKC2Bx0FnmGlBbVfQwikuZ94u3P1/hZQcaiHHlk8yiiljUJ+mgqZiy14Wj/cO48o3eMNK0LvaOq4c1s8BPCweuEaKAM4Ry6BNUgxiQ5ifwk8exATLuEB0lYjhp31Q5Lp+e1/Cy7hbh2yxPwJKzqlwJ7VNOFeYfqp9fAwoFaTeelirWPy9MC2eAX4e6pw218jRla8UjFPr9MqVtDqxv8eevth8ceBjxtZjzIewW+jAqPkYHKlgMOxX4tBGodQJAf1B/hLAXZSFiksEfrjioFtR/FYmLpbZuU5rCjOoqkFN/s0gCB+0IlCCB5z98FDYAAJZ1g2z/wofTzuGVOHxEwywQY2wrkNAeH/SZ9Gl10tFS61Xi/O4WKMfOFcSJh1kHYYkCU1Lj6WUX//uCpGp 3nz+Gvlg u7kU+d3ysrcztHwGr1Vd2JUMDjClSJLm+gXt9IvndEEmtCqpYb/aPVK4EuTmo2JRHEQCK0ue6TS0n3gLQUg9+j2utUR0Tu0a7oK6f8nBiH7fTz1saghyzpSE2yxdrHUX64qAYAZRqYNwXsl6PJtNoT5O9fFYHiqc17ppI9tWtUp3gOAzuyqZzzOET/K11u5ii6Gzy43mSBqK5YoF5oAALzOl2avWnYFb32M2/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4/21/23 12:24, Atish Kumar Patra wrote: > On Fri, Apr 21, 2023 at 3:46 AM Dave Hansen wrote:>> This callback appears to say to the host: >> >> Hey, I (the guest) am treating this guest physical area as MMIO. >> >> But the host and guest have to agree _somewhere_ what the MMIO is used >> for, not just that it is being used as MMIO. > > Yes. The TSM (TEE Security Manager) which is equivalent to TDX also > needs to be aware of the MMIO regions so that it can forward the > faults accordingly. Most of the MMIO is emulated in the host > (userspace or kernel emulation if present). The host is outside the > trust boundary of the guest. Thus, guest needs to make sure the host > only emulates the designated MMIO region. Otherwise, it opens an > attack surface from a malicious host. How does this mechanism stop the host from emulating something outside the designated region? On TDX, for instance, the guest page table have a shared/private bit. Private pages get TDX protections to (among other things) keep the page contents confidential from the host. Shared pages can be used for MMIO and don't have those protections. If the host goes and tries to flip a page from private->shared, TDX protections will kick in and prevent it. None of this requires the guest to tell the host where it expects MMIO to be located. > All other confidential computing solutions also depend on guest > initiated MMIO as well. AFAIK, the TDX & SEV relies on #VE like > exceptions to invoke that while this patch is similar to what pkvm > does. This approach lets the enlightened guest control which MMIO > regions it wants the host to emulate. I'm not _quite_ sure what "guest initiated" means. But SEV and TDX don't require an ioremap hook like this. So, even if they *are* "guest initiated", the question still remains how they work without this patch, or what they are missing without it. > It can be a subset of the region's host provided the layout. The > guest device filtering solution is based on this idea as well [1]. > > [1] https://lore.kernel.org/all/20210930010511.3387967-1-sathyanarayanan.kuppuswamy@linux.intel.com/ I don't really see the connection. Even if that series was going forward (I'm not sure it is) there is no ioremap hook there. There's also no guest->host communication in that series. The guest doesn't _tell_ the host where the MMIO is, it just declines to run code for devices that it didn't expect to see. I'm still rather confused here.