[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YJugs0CdiNo0/Gbd@suse.de>
Date: Wed, 12 May 2021 11:32:35 +0200
From: Joerg Roedel <jroedel@...e.de>
To: Juergen Gross <jgross@...e.com>
Cc: 'Joerg Roedel' <joro@...tes.org>,
David Laight <David.Laight@...lab.com>,
"x86@...nel.org" <x86@...nel.org>,
Hyunwook Baek <baekhw@...gle.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"hpa@...or.com" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Slaby <jslaby@...e.cz>,
Dan Williams <dan.j.williams@...el.com>,
Tom Lendacky <thomas.lendacky@....com>,
Kees Cook <keescook@...omium.org>,
David Rientjes <rientjes@...gle.com>,
Cfir Cohen <cfir@...gle.com>,
Erdem Aktas <erdemaktas@...gle.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mike Stunes <mstunes@...are.com>,
Sean Christopherson <seanjc@...gle.com>,
Martin Radev <martin.b.radev@...il.com>,
Arvind Sankar <nivedita@...m.mit.edu>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH 3/6] x86/sev-es: Use __put_user()/__get_user
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
Powered by blists - more mailing lists