Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4302812pxj; Wed, 12 May 2021 02:34:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuG/c+FgRgqv6ogbo/PYsTAz1iHgf3HWZ58f+oieF5hxtUO/mssfDo7wt4JzTFzbluTNzH X-Received: by 2002:a50:f40c:: with SMTP id r12mr44257077edm.162.1620812041488; Wed, 12 May 2021 02:34:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620812041; cv=none; d=google.com; s=arc-20160816; b=AUOetc4kmq6welWpnFH/09RoCIPQtIzqJdQKWeQp6/oo/0pTIqOsPs9TWPxmDl09CE BVkFDSHhY6j34yddG/aFCgsIvtvWgzjlPHwTl7lsjguY6dq++Dq2XshiYEW0kRK3BDLL gD4uTo43MnoI77+i3rqPQhsLKMeHMjhOYMX3wtRnurST1QYM2v2DYrZ1eUbmzaPLTsmh XGwDZc//GEyzUx45N0VUyMVhoX65eeP5Nw/2TrT4nbI+KtJiMG8bru7XhVqnZDO1iN1C uxI38hqELJO/eFeBSslAFefoRppS4PtXlj4XB3nB/1q/jOaugPdJaxBKNwYQK6f7qJqt N5Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=ktjn8syuWdOKT2hTuwbdK2bHXe78Y4rkUeVg5QMgiUU=; b=bfDBxp7NUQlgjCQc31jbaL0LRA9BwCZByMrNeqLrsS0eu72WWrfj092Kh58WotgGT8 W5o8gZz+nPULtGPIL9hMGouyFbtFbaH/TO1Q/RQ27FocyXAFJQam7NjcfmsG9rrv0dsd TYtaSwM7ZMDmxTqRXEIyque04IswNwV3CqGDYP8eQA+GcMoy0O37ALuz1D9WcaXGAU1K rlHAf/AWRxaGC/QrhZpamaihWzJOVIjsCxX29fDOZtGU7aHhO6qECsWo1Si0HkC5Fdqq oB4Y4P90v2uLlNFZ2XGwjWWlz2tY3JzgNy6kbG1eVyws2uRqj+oSCICn3Z+grmTxBNBK 314g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 n2si27313224ejl.283.2021.05.12.02.33.37; Wed, 12 May 2021 02:34:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230157AbhELJdr (ORCPT + 99 others); Wed, 12 May 2021 05:33:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:55614 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230019AbhELJdr (ORCPT ); Wed, 12 May 2021 05:33:47 -0400 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92244e37-4443-98bd-24aa-bf59548aab47@suse.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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