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: <20140305143800.GA29480@redhat.com>
Date:	Wed, 5 Mar 2014 15:38:00 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Khalid Aziz <khalid.aziz@...cle.com>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	peterz@...radead.org, akpm@...ux-foundation.org,
	andi.kleen@...el.com, rob@...dley.net, viro@...iv.linux.org.uk,
	venki@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] Pre-emption control for userspace

On 03/04, Khalid Aziz wrote:
>
> On 03/04/2014 12:03 PM, Oleg Nesterov wrote:
>>
>> 	1. mremap() can move this vma, so do_exit() can't trust ->uaddr
>>
>> 	2. Even worse, mremap() itself is not safe. It can do ->close()
>> 	   too and create the new vma with the same vm_ops. Another
>> 	   unmap from (say) exit_mm() won't be happy.
>
> I agree this looks like a potential spot for trouble. I was asking if
> removing sys_munmap() of uaddr from do_exit() solves both of the above
> problems?

How? Of course this won't solve the problems. And there are more problems.

> You have convinced me this sys_munmap() I added is unnecessary.

Cough ;) I didn't try to convince you that it should be removed. It is
necessary (but of course you should not use sys_munmap(), say vm_munmap
is better.

But you know, I think this all doesn't matter. Imho, this proc/mmap
interface is horrible. Perhaps something like tls area visible to kernel
make sense, but it should be more generic at least.

You added /proc/sched_preempt_delay to avoid the syscall. I think it
would be better to simply add vdso_sched_preempt_delay() instead.


But the main problem, of course, is that this feature is questionable.

Oleg.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ