[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 04/17] x86/PV: harden guest memory accesses against speculative abuse
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 11 Feb 2021 09:11:57 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ojR4zD6caGLc48AS2kVww9sTzC7GHI0szU8/ekSZn2A=; b=ccAiU1uX6zdeADLOIpJLeyjVjdR2338Pv9bwxN+UwzI709hUkSSvjqJ6/vjNuotnQ6mpoXimmBHu7RyeAUcdX6U/bUIlpVyid/U++SDcGu5faAXR6vINnmjp/A5HOJA9RHlV9OAyGOqAfw2Gh0w2Oyk3pVCVFHoUxQOBvmRgzTKO9ckp4VQYRGTJxHriZAhY/Hs7AHsW9IuZCKvv6/StqPtGXoW7QDSv7kV515JOEoO8GGv712oRNG/i9sxIKKJFtAOpqMZKIhFtloPE2bM8UUUM3Qn/pz1p0KodksP/RFtj6QJC+RuAzvLJoU91KGs1TzvXsMIqs7zqL56ItsGuRg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UgvqKG5du2WYh0m77pL+u8C1Z2gmdEZ0CjMLl3FT2X0tUqDPeTMkNbc6g8IY7Tekd9yRvPH3HbULycyWQJfWHfYMsSFTsOCH4NzBtcXv5+bJpwETQwdkhwT3UrX4qKxGPgD6q4W3dRL9U+K9FN2JFlnppAXAkZ5Mb5elpjAGKuTyQYjeWuEbEHTEO4Mgdn4EEpTrSqRWTakDVGYqAy2vNR8dUmVpKCcVbreNawFavTkHsPGhsW1T4VeTIa3TTo/LSMLFrwkUCKcgtmJ1+2aN+tWnrEyh4NKt1fvcOM99/YvyA0GEQ9GsKUxlLV0u1rHh2KGqdV0ujug3Jjfd14BXsg==
- Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Tim Deegan <tim@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
- Delivery-date: Thu, 11 Feb 2021 08:12:37 +0000
- Ironport-sdr: 3UxdGt+y4JLdadUcNkU0CGFwvJbRq+Ip3M016hc/n1yN/6xuFqiqLJX8feCTEbBguwkj9rIJjX KHzfvmV67XpTXBKTQhsSV30UbCrjeJNEm9nyirdd1/BaIIUKZf+6J257nbLv4uWUqcGuahPPR6 YXSn2QSnqtqx+ieg4SUrWdjhsqn9kryYWm8yXp0xH+GGTF85P1Ak3gdhJJ/WfMAQdVqj46edqI K3woKKwq/FM+9Yuz2EiYIVe6HKFGFJpg+9o38pOue4Z7TN+VKKI4kRnQV0rxfGgHXo78iMjCtH SVE=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Feb 10, 2021 at 05:55:52PM +0100, Jan Beulich wrote:
> On 09.02.2021 17:26, Roger Pau Monné wrote:
> > On Thu, Jan 14, 2021 at 04:04:57PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/usercopy.c
> >> +++ b/xen/arch/x86/usercopy.c
> >> @@ -10,12 +10,19 @@
> >> #include <xen/sched.h>
> >> #include <asm/uaccess.h>
> >>
> >> -unsigned __copy_to_user_ll(void __user *to, const void *from, unsigned n)
> >> +#ifndef GUARD
> >> +# define GUARD UA_KEEP
> >> +#endif
> >> +
> >> +unsigned int copy_to_guest_ll(void __user *to, const void *from, unsigned
> >> int n)
> >> {
> >> unsigned dummy;
> >>
> >> stac();
> >> asm volatile (
> >> + GUARD(
> >> + " guest_access_mask_ptr %[to], %q[scratch1], %q[scratch2]\n"
> >
> > Don't you need to also take 'n' into account here to assert that the
> > address doesn't end in hypervisor address space? Or that's fine as
> > speculation wouldn't go that far?
>
> Like elsewhere this leverages that the hypervisor VA range starts
> immediately after the non-canonical hole. I'm unaware of
> speculation being able to cross over that hole.
>
> > I also wonder why this needs to be done in assembly, could you check
> > the address(es) using C?
>
> For this to be efficient (in avoiding speculation) the insn
> sequence would better not have any conditional jumps. I don't
> think the compiler can be told so.
Why not use evaluate_nospec to check the address like we do in other
places?
Thanks, Roger.
|
