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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Sep 2015 18:00:27 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Julien Grall <julien.grall@...rix.com>
Cc:	xen-devel@...ts.xenproject.org,
	linux-arm-kernel@...ts.infradead.org, ian.campbell@...rix.com,
	stefano.stabellini@...citrix.com, linux-kernel@...r.kernel.org,
	Riku Voipio <riku.voipio@...aro.org>
Subject: Re: [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@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/