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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham 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 45A28C47082 for ; Wed, 26 May 2021 19:47:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DDA1360FE8 for ; Wed, 26 May 2021 19:46:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDA1360FE8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 733FC6B0036; Wed, 26 May 2021 15:46:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70AC56B006E; Wed, 26 May 2021 15:46:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 584388D0001; Wed, 26 May 2021 15:46:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id 1D5E96B0036 for ; Wed, 26 May 2021 15:46:59 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A862FB9E9 for ; Wed, 26 May 2021 19:46:58 +0000 (UTC) X-FDA: 78184415316.25.A8E8328 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf08.hostedemail.com (Postfix) with ESMTP id 543CB8019121 for ; Wed, 26 May 2021 19:46:51 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id m190so1849364pga.2 for ; Wed, 26 May 2021 12:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hEQ3MdXmpdNmcX6sa1MKz2lUFHPHmPostz9Pp0Yt+54=; b=b1ledajAYuzSP2VsYjLXXA+yLdhz9jMTPLKR8jN1BmCm06HetxB4+K+9y1UkLgPGJU 8FJJevRA+tNRkxZEmKTbGAEI201rzRZoz5+VL7ftvW0M84XkhdamXP09FeQBf0gDMQGU 0k9I1ORp07R5N8pLA1QDajOqd6fOK0a7s0zKXZ7MRZknul8dbZAVK3KNwxMHmNCQfBLY jJ3jy8WK2GAgyehfuQVJdPflw5Uv2kQBba7LRL5vNSkwHjO/TeZhiuXKJEuo7EZFqXnP 6CqLhRB4GytEUeiguuk8nexR6qzpY5MWCLAB7GLELwSWrKeTRKKlEoIKE4X5J/7EgIkv hv3A== 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=hEQ3MdXmpdNmcX6sa1MKz2lUFHPHmPostz9Pp0Yt+54=; b=OGrIfvnwGuH8xBJfp7eT6ehwfEGi36K9stxQ8JMXy9jRMoBYmopQ4/R+h2Lm2MbJxg Y33CV5SMVcpjrf2QYdPlCcma3InSOTjHWXEEDtNeffDcd/ABGz44SGVJwPONsOdRVrtv rKvlXVThspU25wsuKvcavnGO0t87woEA5DZHd6aR89/aTWBZTt7LYoazKA4jxsfIbSYA +63TnTkMVnSPKSz7+BhJCICmXYoCzktG+TTlag/DTA33laagCHbtCyX3H8KHhTpwT6ir im30KgKMF1mDfBlKCmdwSEUOKbbZ9cJ2sFXiPfW8WHpddH2gyrHUWHxftyXQAO5FMZdV tTYA== X-Gm-Message-State: AOAM530u4tteifRaFkMa9VnJ9L89B+KU5ZkmKVg6ZKDk3NmJRyWjEWac DXy5LAFyHPudY0u/aknTfI8q9g== X-Google-Smtp-Source: ABdhPJwBXUXILPsFBDFo9CFR/JDpKVm78Qh7x+mpCE2hRYo8JoIxtQJXcXaDoL8EHmqAouWcIEOiWQ== X-Received: by 2002:a62:cec9:0:b029:2e3:9125:c280 with SMTP id y192-20020a62cec90000b02902e39125c280mr65079pfg.11.1622058417033; Wed, 26 May 2021 12:46:57 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id f9sm46220pfc.42.2021.05.26.12.46.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 May 2021 12:46:56 -0700 (PDT) Date: Wed, 26 May 2021 19:46:52 +0000 From: Sean Christopherson To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Jim Mattson , David Rientjes , "Edgecombe, Rick P" , "Kleen, Andi" , "Yamahata, Isaku" , Erdem Aktas , Steve Rutherford , Peter Gonda , David Hildenbrand , Chao Peng , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFCv2 13/13] KVM: unmap guest memory using poisoned pages Message-ID: References: <20210419142602.khjbzktk5tk5l6lk@box.shutemov.name> <20210419164027.dqiptkebhdt5cfmy@box.shutemov.name> <20210419185354.v3rgandtrel7bzjj@box> <20210419225755.nsrtjfvfcqscyb6m@box.shutemov.name> <20210521123148.a3t4uh4iezm6ax47@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210521123148.a3t4uh4iezm6ax47@box> X-Rspamd-Queue-Id: 543CB8019121 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=b1ledajA; spf=pass (imf08.hostedemail.com: domain of seanjc@google.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Stat-Signature: u4hunapc1ikqomuk5uknjjas6y9y5t7o X-HE-Tag: 1622058411-59835 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 Fri, May 21, 2021, Kirill A. Shutemov wrote: > Hi Sean, > > The core patch of the approach we've discussed before is below. It > introduce a new page type with the required semantics. > > The full patchset can be found here: > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git kvm-unmapped-guest-only > > but only the patch below is relevant for TDX. QEMU patch is attached. Can you post the whole series? The KVM behavior and usage of FOLL_GUEST is very relevant to TDX. > CONFIG_HAVE_KVM_PROTECTED_MEMORY has to be changed to what is appropriate > for TDX and FOLL_GUEST has to be used in hva_to_pfn_slow() when running > TDX guest. This behavior in particular is relevant; KVM should provide FOLL_GUEST iff the access is private or the VM type doesn't differentiate between private and shared. > When page get inserted into private sept we must make sure it is > PageGuest() or SIGBUS otherwise. More KVM feedback :-) Ideally, KVM will synchronously exit to userspace with detailed information on the bad behavior, not do SIGBUS. Hopefully that infrastructure will be in place sooner than later. https://lkml.kernel.org/r/YKxJLcg/WomPE422@google.com > Inserting PageGuest() into shared is fine, but the page will not be accessible > from userspace. Even if it can be functionally fine, I don't think we want to allow KVM to map PageGuest() as shared memory. The only reason to map memory shared is to share it with something, e.g. the host, that doesn't have access to private memory, so I can't envision a use case. On the KVM side, it's trivially easy to omit FOLL_GUEST for shared memory, while always passing FOLL_GUEST would require manually zapping. Manual zapping isn't a big deal, but I do think it can be avoided if userspace must either remap the hva or define a new KVM memslot (new gpa->hva), both of which will automatically zap any existing translations. Aha, thought of a concrete problem. If KVM maps PageGuest() into shared memory, then KVM must ensure that the page is not mapped private via a different hva/gpa, and is not mapped _any_ other guest because the TDX-Module's 1:1 PFN:TD+GPA enforcement only applies to private memory. The explicit "VM_WRITE | VM_SHARED" requirement below makes me think this wouldn't be prevented. Oh, and the other nicety is that I think it would avoid having to explicitly handle PageGuest() memory that is being accessed from kernel/KVM, i.e. if all memory exposed to KVM must be !PageGuest(), then it is also eligible for copy_{to,from}_user(). > Any feedback is welcome. > > -------------------------------8<------------------------------------------- > > From: "Kirill A. Shutemov" > Date: Fri, 16 Apr 2021 01:30:48 +0300 > Subject: [PATCH] mm: Introduce guest-only pages > > PageGuest() pages are only allowed to be used as guest memory. Userspace > is not allowed read from or write to such pages. > > On page fault, PageGuest() pages produce PROT_NONE page table entries. > Read or write there will trigger SIGBUS. Access to such pages via > syscall leads to -EIO. > > The new mprotect(2) flag PROT_GUEST translates to VM_GUEST. Any page > fault to VM_GUEST VMA produces PageGuest() page. > > Only shared tmpfs/shmem mappings are supported. Is limiting this to tmpfs/shmem only for the PoC/RFC, or is it also expected to be the long-term behavior? > GUP normally fails on such pages. KVM will use the new FOLL_GUEST flag > to access them.