linux-kernel - Re: arc_usr_cmpxchg and preemption

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]

Message-ID: <1521059931.11552.51.camel@synopsys.com>
Date:   Wed, 14 Mar 2018 20:38:53 +0000
From:   Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To:     "Vineet.Gupta1@...opsys.com" <Vineet.Gupta1@...opsys.com>,
        "peterz@...radead.org" <peterz@...radead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>
Subject: Re: arc_usr_cmpxchg and preemption

Hi Peter, Vineet,

On Wed, 2018-03-14 at 18:53 +0100, Peter Zijlstra wrote:
> On Wed, Mar 14, 2018 at 09:58:19AM -0700, Vineet Gupta wrote:
> 
> > Well it is broken wrt the semantics the syscall is supposed to provide.
> > Preemption disabling is what prevents a concurrent thread from coming in and
> > modifying the same location (Imagine a variable which is being cmpxchg
> > concurrently by 2 threads).
> > 
> > One approach is to do it the MIPS way, emulate the llsc flag - set it under
> > preemption disabled section and clear it in switch_to
> 
> *shudder*... just catch the -EFAULT, force the write fault and retry.
> 
> Something like:
> 
> int sys_cmpxchg(u32 __user *user_ptr, u32 old, u32 new)
> {
> 	u32 val;
> 	int ret;
> 
> again:
> 	ret = 0;
> 
> 	preempt_disable();
> 	val = get_user(user_ptr);
> 	if (val == old)
> 		ret = put_user(new, user_ptr);
> 	preempt_enable();
> 
> 	if (ret == -EFAULT) {
> 		struct page *page;
> 		ret = get_user_pages_fast((unsigned long)user_ptr, 1, 1, &page);
> 		if (ret < 0)
> 			return ret;
> 		put_page(page);
> 		goto again;

I guess this jump we need to do only once, right?
If for whatever reason get_user_pages_fast() fails we return immediately
and if it succeeds there's no reason for put_user() to not succeed as
required page is supposed to be prepared for write.

Otherwise if something goes way too bad we may end-up in an infinite loop
which we'd better prevent.

> 	}
> 
> 	return ret;
> }

@Vineet, are you OK with proposed implementation?

-Alexey