On 12.05.21 10:50, 'Joerg Roedel' wrote:> On Wed, May 12, 2021 at 10:16:12AM +0200, Juergen Gross wrote: >> You want something like xen_safe_[read|write]_ulong(). > > From a first glance I can't see it, what is the difference between the > xen_safe_*_ulong() functions and __get_user()/__put_user()? The only > difference I can see is that __get/__put_user() support different access > sizes, but neither of those disables page-faults by itself, for example. > > Couldn't these xen-specific functions not also be replaces by > __get_user()/__put_user()?No, those were used before, but commit 9da3f2b7405440 broke Xen's use case. That is why I did commit 1457d8cf7664f. Juergen -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB0DE9DD628BF132F.asc Type: application/pgp-keys Size: 3091 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20210512/730858b1/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20210512/730858b1/attachment.sig>
From: Juergen Gross> Sent: 12 May 2021 09:58 > > On 12.05.21 10:50, 'Joerg Roedel' wrote: > > On Wed, May 12, 2021 at 10:16:12AM +0200, Juergen Gross wrote: > >> You want something like xen_safe_[read|write]_ulong(). > > > > From a first glance I can't see it, what is the difference between the > > xen_safe_*_ulong() functions and __get_user()/__put_user()? The only > > difference I can see is that __get/__put_user() support different access > > sizes, but neither of those disables page-faults by itself, for example. > > > > Couldn't these xen-specific functions not also be replaces by > > __get_user()/__put_user()? > > No, those were used before, but commit 9da3f2b7405440 broke Xen's use > case. That is why I did commit 1457d8cf7664f.I've just looked at 9da3f2b7405440. It doesn't look right to me - wrong return value for a lot of cases. OTOH it isn't in my newest tree at all. If bogus_uaccess() is now elsewhere I can't see how (without changes) it would allow through these faults. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
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