[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxxxxxxxx>

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.