Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6865910pxv; Fri, 30 Jul 2021 04:31:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzH69Ubbryf9eyqRYwcewt7FKHvLE+8bwLc28e5AT+1KsOs/+Goio0vHiIT9f8TPFEoKOqy X-Received: by 2002:a17:907:75f3:: with SMTP id jz19mr2097675ejc.69.1627644707449; Fri, 30 Jul 2021 04:31:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627644707; cv=none; d=google.com; s=arc-20160816; b=vTEI8zfEI+idVd4P89Xw13BJaf3G/xxGmScRciAWXeEIYKokyK7HUmedxQ6w47eXz9 x8WC2S72Ia3Sutl8tVb6Az1VDRacWNvNKnIUgJqhgreeqQn13D9JKjZJsyh5P9W+BPx4 MsqZxwpVGiolaAG5gjD9K6nUikCtOukCWjfIEulsDhUDnDlhPItmsjMqmz/OVWkbEByK 89cbF6l3+6bXF9p53eyLBPZ+qUPxztAC2x/6pdFNU1pThCE7HlBstrxP0+ukOEp52fPd Hk0VLV07vFAqEjL7VJmOnrYWHNLDu90Ao7G92v21kGZE5mkvNw0cnF5qSx+r3XRg8fNj V0zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature:dkim-signature; bh=0i5/8P81wWKC2EpiUP3Ejs7q4Xz+ybvx8UrMU1RwVW8=; b=iHZ3w47bY+MlFP35xuvR50APYQwY5ea+IvXb/LFWfXabP7AW8ulZLPEi9uQN8uyJBU silQsYTTvrIxhgGWZOIJ3SFEDRS4FaypkbqJm0gPYgWnGkO4EGpxn35g/cBnX4v3ERVZ nmcs3jZI04Y+/mEKxP40To8orT067yShCVMDFi0voqonk9LfAYWiyxHaUIMA2MIdUow8 lm+M8ytGDhWkJpe7wLWW94VCQ0HR+AU7oPFtaGY/CxGdJWVwPEgdsshbJKAlWcDCi/jJ jVv0tn5NNkBnAM1e2bdWTq163xw5fZ5KFxV4WEMqoBMsOzr2XzrWptps+LzZWdupyY6a 7Zww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=1FG7Tknl; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=E6W9oaol; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i17si1415050edr.164.2021.07.30.04.31.11; Fri, 30 Jul 2021 04:31:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=1FG7Tknl; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=E6W9oaol; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238703AbhG3LbJ (ORCPT + 99 others); Fri, 30 Jul 2021 07:31:09 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:52158 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238678AbhG3LbJ (ORCPT ); Fri, 30 Jul 2021 07:31:09 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 771822232B; Fri, 30 Jul 2021 11:31:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1627644663; h=from:from:reply-to: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; bh=0i5/8P81wWKC2EpiUP3Ejs7q4Xz+ybvx8UrMU1RwVW8=; b=1FG7TknlogbuGPp4BV8k+OVpjRdWs6/5v+ZJjlXdVE5gwj2C9cp5faC+4VpbgtPWlat/MM VUKr1OKF/PgOmuuPuXlA+xJ+XkaUTE+bz1ATzIUWIUMAnD9WGrh2U042Dmaw5+f0pCwKgf 5KYrqgQDu9YkmB6KYmh/9daaOeAhNuQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1627644663; h=from:from:reply-to: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; bh=0i5/8P81wWKC2EpiUP3Ejs7q4Xz+ybvx8UrMU1RwVW8=; b=E6W9oaolIYJXsCXJWlD8cjTCtV5D8TbX4yudUeAx58zz5GaoZmkpGX2HAOjgxsWnoY19Lb QAATd1d6oY41C5AQ== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 0D9A7137C2; Fri, 30 Jul 2021 11:31:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id z+f8AffiA2FYRgAAGKfGzw (envelope-from ); Fri, 30 Jul 2021 11:31:03 +0000 Subject: Re: [PATCH Part2 RFC v4 07/40] x86/sev: Split the physmap when adding the page in RMP table To: Brijesh Singh , Sean Christopherson Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , tony.luck@intel.com, npmccallum@redhat.com, brijesh.ksingh@gmail.com References: <20210707183616.5620-1-brijesh.singh@amd.com> <20210707183616.5620-8-brijesh.singh@amd.com> <41f83ddf-a8a5-daf3-dc77-15fc164f77c6@amd.com> <8da808d6-162f-bbaf-fa15-683f8636694f@amd.com> From: Vlastimil Babka Message-ID: Date: Fri, 30 Jul 2021 13:31:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <8da808d6-162f-bbaf-fa15-683f8636694f@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On 7/15/21 9:38 PM, Brijesh Singh wrote: > > > On 7/15/21 1:39 PM, Sean Christopherson wrote: >> On Thu, Jul 15, 2021, Brijesh Singh wrote: >>> The memfd_secrets uses the set_direct_map_{invalid,default}_noflush() and it >>> is designed to remove/add the present bit in the direct map. We can't use >>> them, because in our case the page may get accessed by the KVM (e.g >>> kvm_guest_write, kvm_guest_map etc). >> >> But KVM should never access a guest private page, i.e. the direct map should >> always be restored to PRESENT before KVM attempts to access the page. >> > > Yes, KVM should *never* access the guest private pages. So, we could potentially > enhance the RMPUPDATE() to check for the assigned and act accordingly. I think I'm not the first one suggesting it, but IMHO the best solution would be to leave direct map alone (except maybe in some debugging/development mode where you could do the unmapping to catch unexpected host accesses), and once there's a situation with host accessing a shared page of the guest, it would temporarily kmap() it outside of the direct map. Shouldn't these situations be rare enough, and already recognizable due to the need to set up the page sharing in the first place, that this approach would be feasible? > Are you thinking something along the line of this: > > int rmpupdate(struct page *page, struct rmpupdate *val) > { >     ... >      >     /* >      * If page is getting assigned in the RMP entry then unmap >      * it from the direct map before its added in the RMP table. >      */ >     if (val.assigned) >         set_direct_map_invalid_noflush(page_to_virt(page), 1); > >     ... > >     /* >      * If the page is getting unassigned then restore the mapping >      * in the direct map after its removed from the RMP table. >      */ >     if (!val.assigned) >         set_direct_map_default_noflush(page_to_virt(page), 1); >      >     ... > } > > thanks