[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Julien Grall]

When Xen is copying data to/from the guest it will check if the kernel
has the right to do the access. If not, the hypercall will return an
error.

After the commit a5e090acbf545c0a3b04080f8a488b17ec41fe02 "ARM:
software-based privileged-no-access support", the kernel can't access
any longer the user space by default. This will result to fail on every
hypercall made by the userspace (i.e via privcmd).

We have to enable the userspace access and then restore the correct
permission every time the privcmd is used to made an hypercall.

I didn't find generic helpers to do a these operations, so the change
is only arm32 specific.

Reported-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Julien Grall <julien.grall@citrix.com>

---
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>

    Changes in v2:
        - Directly enable/disable the user space access in assembly
        - Typoes

    ARM64 doesn't seem to have priviledge no-access support yet so there
    is nothing to do for now.

    I haven't look x86 at all.
---
 arch/arm/xen/hypercall.S | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index f00e080..10fd99c 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -98,8 +98,23 @@ ENTRY(privcmd_call)
 	mov r1, r2
 	mov r2, r3
 	ldr r3, [sp, #8]
+	/*
+	 * Privcmd calls are issued by the userspace. We need to allow the
+	 * kernel to access the userspace memory before issuing the hypercall.
+	 */
+	uaccess_enable r4
+
+	/* r4 is loaded now as we use it as scratch register before */
 	ldr r4, [sp, #4]
 	__HVC(XEN_IMM)
+
+	/*
+	 * Disable userspace access from kernel. This is fine to do it
+	 * unconditionally as no set_fs(KERNEL_DS)/set_fs(get_ds()) is
+	 * called before.
+	 */
+	uaccess_disable r4
+
 	ldm sp!, {r4}
 	ret lr
 ENDPROC(privcmd_call);
-- 
2.1.4

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Russell King - ARM Linux]

On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
> +	/*
> +	 * Privcmd calls are issued by the userspace. We need to allow the
> +	 * kernel to access the userspace memory before issuing the hypercall.
> +	 */
> +	uaccess_enable r4
> +
> +	/* r4 is loaded now as we use it as scratch register before */
>  	ldr r4, [sp, #4]

As I mentioned in one of my previous mails, "ip" should be safe to use
here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
you could do:

	ldr r4, [sp, #4]
+	uaccess_enable ip

which fractionally tightens the window.

However, there's nothing actually wrong with your version - there's no
way we could've got this far with sp pointing at userspace.

I'm happy with either version, so:

Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

How do you want to handle the patch?  I already have some other uaccess
fixes queued up to send to Linus before the merge window closes.

>  	__HVC(XEN_IMM)
> +
> +	/*
> +	 * Disable userspace access from kernel. This is fine to do it
> +	 * unconditionally as no set_fs(KERNEL_DS)/set_fs(get_ds()) is
> +	 * called before.
> +	 */
> +	uaccess_disable r4
> +
>  	ldm sp!, {r4}
>  	ret lr
>  ENDPROC(privcmd_call);
> -- 
> 2.1.4
> 

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Julien Grall]

On 11/09/15 18:00, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>> +	/*
>> +	 * Privcmd calls are issued by the userspace. We need to allow the
>> +	 * kernel to access the userspace memory before issuing the hypercall.
>> +	 */
>> +	uaccess_enable r4
>> +
>> +	/* r4 is loaded now as we use it as scratch register before */
>>  	ldr r4, [sp, #4]
> 
> As I mentioned in one of my previous mails, "ip" should be safe to use
> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
> you could do:
> 
> 	ldr r4, [sp, #4]
> +	uaccess_enable ip

The register ip (aka r12) is used to store the hypercall number.
The easiest one, without much changes, was r4.

> which fractionally tightens the window.
> 
> However, there's nothing actually wrong with your version - there's no
> way we could've got this far with sp pointing at userspace.
> 
> I'm happy with either version, so:
> 
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Thank you!

> 
> How do you want to handle the patch?  I already have some other uaccess
> fixes queued up to send to Linus before the merge window closes.

I was thinking to ask Stefano to carry it in Xen tree. But I don't mind
if it goes with your tree.

Regards,

-- 
Julien Grall

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Julien Grall]

On 11/09/15 18:00, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>> +	/*
>> +	 * Privcmd calls are issued by the userspace. We need to allow the
>> +	 * kernel to access the userspace memory before issuing the hypercall.
>> +	 */
>> +	uaccess_enable r4
>> +
>> +	/* r4 is loaded now as we use it as scratch register before */
>>  	ldr r4, [sp, #4]
> 
> As I mentioned in one of my previous mails, "ip" should be safe to use
> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
> you could do:
> 
> 	ldr r4, [sp, #4]
> +	uaccess_enable ip

The register ip (aka r12) is used to store the hypercall number. So we
can't reuse it as scratch register.

The easiest one is r4.

> 
> which fractionally tightens the window.
> 
> However, there's nothing actually wrong with your version - there's no
> way we could've got this far with sp pointing at userspace.
> 
> I'm happy with either version, so:
> 
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> How do you want to handle the patch?  I already have some other uaccess
> fixes queued up to send to Linus before the merge window closes.
> 
>>  	__HVC(XEN_IMM)
>> +
>> +	/*
>> +	 * Disable userspace access from kernel. This is fine to do it
>> +	 * unconditionally as no set_fs(KERNEL_DS)/set_fs(get_ds()) is
>> +	 * called before.
>> +	 */
>> +	uaccess_disable r4
>> +
>>  	ldm sp!, {r4}
>>  	ret lr
>>  ENDPROC(privcmd_call);
>> -- 
>> 2.1.4
>>
> 


-- 
Julien Grall

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Julien Grall]

On 11/09/15 18:32, Julien Grall wrote:
> On 11/09/15 18:00, Russell King - ARM Linux wrote:
>> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>>> +	/*
>>> +	 * Privcmd calls are issued by the userspace. We need to allow the
>>> +	 * kernel to access the userspace memory before issuing the hypercall.
>>> +	 */
>>> +	uaccess_enable r4
>>> +
>>> +	/* r4 is loaded now as we use it as scratch register before */
>>>  	ldr r4, [sp, #4]
>>
>> As I mentioned in one of my previous mails, "ip" should be safe to use
>> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
>> you could do:
>>
>> 	ldr r4, [sp, #4]
>> +	uaccess_enable ip
> 
> The register ip (aka r12) is used to store the hypercall number. So we
> can't reuse it as scratch register.
> 
> The easiest one is r4.
> 
>>
>> which fractionally tightens the window.
>>
>> However, there's nothing actually wrong with your version - there's no
>> way we could've got this far with sp pointing at userspace.
>>
>> I'm happy with either version, so:
>>
>> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> How do you want to handle the patch?  I already have some other uaccess
>> fixes queued up to send to Linus before the merge window closes.

Forgot to answer to this bits. I was thinking to ask Stefano carrying
the patch in xentip. Although it won't go until rc1.

I don't mind if it's going earlier in Linux/master.

Regards,

-- 
Julien Grall

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Russell King - ARM Linux]

On Fri, Sep 11, 2015 at 06:36:05PM +0100, Julien Grall wrote:
> On 11/09/15 18:32, Julien Grall wrote:
> > On 11/09/15 18:00, Russell King - ARM Linux wrote:
> >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
> >>> +	/*
> >>> +	 * Privcmd calls are issued by the userspace. We need to allow the
> >>> +	 * kernel to access the userspace memory before issuing the hypercall.
> >>> +	 */
> >>> +	uaccess_enable r4
> >>> +
> >>> +	/* r4 is loaded now as we use it as scratch register before */
> >>>  	ldr r4, [sp, #4]
> >>
> >> As I mentioned in one of my previous mails, "ip" should be safe to use
> >> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
> >> you could do:
> >>
> >> 	ldr r4, [sp, #4]
> >> +	uaccess_enable ip
> > 
> > The register ip (aka r12) is used to store the hypercall number. So we
> > can't reuse it as scratch register.
> > 
> > The easiest one is r4.
> > 
> >>
> >> which fractionally tightens the window.
> >>
> >> However, there's nothing actually wrong with your version - there's no
> >> way we could've got this far with sp pointing at userspace.
> >>
> >> I'm happy with either version, so:
> >>
> >> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> How do you want to handle the patch?  I already have some other uaccess
> >> fixes queued up to send to Linus before the merge window closes.
> 
> Forgot to answer to this bits. I was thinking to ask Stefano carrying
> the patch in xentip. Although it won't go until rc1.
> 
> I don't mind if it's going earlier in Linux/master.

Thanks, I've applied your patch as-is now.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Stefano Stabellini]

On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 06:36:05PM +0100, Julien Grall wrote:
> > On 11/09/15 18:32, Julien Grall wrote:
> > > On 11/09/15 18:00, Russell King - ARM Linux wrote:
> > >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
> > >>> +	/*
> > >>> +	 * Privcmd calls are issued by the userspace. We need to allow the
> > >>> +	 * kernel to access the userspace memory before issuing the hypercall.
> > >>> +	 */
> > >>> +	uaccess_enable r4
> > >>> +
> > >>> +	/* r4 is loaded now as we use it as scratch register before */
> > >>>  	ldr r4, [sp, #4]
> > >>
> > >> As I mentioned in one of my previous mails, "ip" should be safe to use
> > >> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
> > >> you could do:
> > >>
> > >> 	ldr r4, [sp, #4]
> > >> +	uaccess_enable ip
> > > 
> > > The register ip (aka r12) is used to store the hypercall number. So we
> > > can't reuse it as scratch register.
> > > 
> > > The easiest one is r4.
> > > 
> > >>
> > >> which fractionally tightens the window.
> > >>
> > >> However, there's nothing actually wrong with your version - there's no
> > >> way we could've got this far with sp pointing at userspace.
> > >>
> > >> I'm happy with either version, so:
> > >>
> > >> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > >>
> > >> How do you want to handle the patch?  I already have some other uaccess
> > >> fixes queued up to send to Linus before the merge window closes.
> > 
> > Forgot to answer to this bits. I was thinking to ask Stefano carrying
> > the patch in xentip. Although it won't go until rc1.
> > 
> > I don't mind if it's going earlier in Linux/master.
> 
> Thanks, I've applied your patch as-is now.

That's fine by me, the patch looks good.

Thanks,

Stefano

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Russell King - ARM Linux]

On Fri, Sep 11, 2015 at 06:56:50PM +0100, Stefano Stabellini wrote:
> On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > On Fri, Sep 11, 2015 at 06:36:05PM +0100, Julien Grall wrote:
> > > On 11/09/15 18:32, Julien Grall wrote:
> > > > On 11/09/15 18:00, Russell King - ARM Linux wrote:
> > > >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
> > > >>> +	/*
> > > >>> +	 * Privcmd calls are issued by the userspace. We need to allow the
> > > >>> +	 * kernel to access the userspace memory before issuing the hypercall.
> > > >>> +	 */
> > > >>> +	uaccess_enable r4
> > > >>> +
> > > >>> +	/* r4 is loaded now as we use it as scratch register before */
> > > >>>  	ldr r4, [sp, #4]
> > > >>
> > > >> As I mentioned in one of my previous mails, "ip" should be safe to use
> > > >> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
> > > >> you could do:
> > > >>
> > > >> 	ldr r4, [sp, #4]
> > > >> +	uaccess_enable ip
> > > > 
> > > > The register ip (aka r12) is used to store the hypercall number. So we
> > > > can't reuse it as scratch register.
> > > > 
> > > > The easiest one is r4.
> > > > 
> > > >>
> > > >> which fractionally tightens the window.
> > > >>
> > > >> However, there's nothing actually wrong with your version - there's no
> > > >> way we could've got this far with sp pointing at userspace.
> > > >>
> > > >> I'm happy with either version, so:
> > > >>
> > > >> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > > >>
> > > >> How do you want to handle the patch?  I already have some other uaccess
> > > >> fixes queued up to send to Linus before the merge window closes.
> > > 
> > > Forgot to answer to this bits. I was thinking to ask Stefano carrying
> > > the patch in xentip. Although it won't go until rc1.
> > > 
> > > I don't mind if it's going earlier in Linux/master.
> > 
> > Thanks, I've applied your patch as-is now.
> 
> That's fine by me, the patch looks good.

If you'd like your ack on it, please send one, I can still do that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Stefano Stabellini]

On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 06:56:50PM +0100, Stefano Stabellini wrote:
> > On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > > On Fri, Sep 11, 2015 at 06:36:05PM +0100, Julien Grall wrote:
> > > > On 11/09/15 18:32, Julien Grall wrote:
> > > > > On 11/09/15 18:00, Russell King - ARM Linux wrote:
> > > > >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
> > > > >>> +	/*
> > > > >>> +	 * Privcmd calls are issued by the userspace. We need to allow the
> > > > >>> +	 * kernel to access the userspace memory before issuing the hypercall.
> > > > >>> +	 */
> > > > >>> +	uaccess_enable r4
> > > > >>> +
> > > > >>> +	/* r4 is loaded now as we use it as scratch register before */
> > > > >>>  	ldr r4, [sp, #4]
> > > > >>
> > > > >> As I mentioned in one of my previous mails, "ip" should be safe to use
> > > > >> here - it's a caller-corrupted register, just like r0-r3 and lr.  So,
> > > > >> you could do:
> > > > >>
> > > > >> 	ldr r4, [sp, #4]
> > > > >> +	uaccess_enable ip
> > > > > 
> > > > > The register ip (aka r12) is used to store the hypercall number. So we
> > > > > can't reuse it as scratch register.
> > > > > 
> > > > > The easiest one is r4.
> > > > > 
> > > > >>
> > > > >> which fractionally tightens the window.
> > > > >>
> > > > >> However, there's nothing actually wrong with your version - there's no
> > > > >> way we could've got this far with sp pointing at userspace.
> > > > >>
> > > > >> I'm happy with either version, so:
> > > > >>
> > > > >> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > > > >>
> > > > >> How do you want to handle the patch?  I already have some other uaccess
> > > > >> fixes queued up to send to Linus before the merge window closes.
> > > > 
> > > > Forgot to answer to this bits. I was thinking to ask Stefano carrying
> > > > the patch in xentip. Although it won't go until rc1.
> > > > 
> > > > I don't mind if it's going earlier in Linux/master.
> > > 
> > > Thanks, I've applied your patch as-is now.
> > 
> > That's fine by me, the patch looks good.
> 
> If you'd like your ack on it, please send one, I can still do that.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Russell King - ARM Linux]

On Mon, Sep 14, 2015 at 10:36:55AM +0100, Stefano Stabellini wrote:
> On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > If you'd like your ack on it, please send one, I can still do that.
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Sorry, that's a bit too late - I sent Linus the pull request on Saturday,
but it missed the -rc1 release... still waiting for Linus to pull it.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Stefano Stabellini]

On Mon, 14 Sep 2015, Russell King - ARM Linux wrote:
> On Mon, Sep 14, 2015 at 10:36:55AM +0100, Stefano Stabellini wrote:
> > On Fri, 11 Sep 2015, Russell King - ARM Linux wrote:
> > > If you'd like your ack on it, please send one, I can still do that.
> > 
> > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Sorry, that's a bit too late - I sent Linus the pull request on Saturday,
> but it missed the -rc1 release... still waiting for Linus to pull it.

No worries, thanks for letting me know.