From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFD1571 for ; Wed, 12 May 2021 09:32:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 35D6CAF75; Wed, 12 May 2021 09:32:38 +0000 (UTC) Date: Wed, 12 May 2021 11:32:35 +0200 From: Joerg Roedel To: Juergen Gross Cc: 'Joerg Roedel' , David Laight , "x86@kernel.org" , Hyunwook Baek , "stable@vger.kernel.org" , "hpa@zytor.com" , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Kees Cook , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , Arvind Sankar , "linux-coco@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" Subject: Re: [PATCH 3/6] x86/sev-es: Use __put_user()/__get_user Message-ID: References: <20210512075445.18935-1-joro@8bytes.org> <20210512075445.18935-4-joro@8bytes.org> <0496626f018d4d27a8034a4822170222@AcuMS.aculab.com> <92244e37-4443-98bd-24aa-bf59548aab47@suse.com> X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92244e37-4443-98bd-24aa-bf59548aab47@suse.com> On Wed, May 12, 2021 at 10:58:20AM +0200, Juergen Gross wrote: > No, those were used before, but commit 9da3f2b7405440 broke Xen's use > case. That is why I did commit 1457d8cf7664f. I see, thanks for the heads-up. So here this is not a big issue, because when an access to kernel space faults under SEV-ES, its a kernel bug anyway. The issue is that it is not reported correctly. I think I need to re-work the helper and use probe_kernel_read/write() when the address is in kernel space. This distinction is already made when fetching instruction bytes in the #VC handler, but I thought I could get around it for data accesses. Having the distinction between user and kernel memory accesses explicitly in the code seems to be the most robust solution. Regards, Joerg