linux-kernel - Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT

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: <20081008091112.GK7971@one.firstfloor.org>
Date:	Wed, 8 Oct 2008 11:11:12 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andi Kleen <andi@...stfloor.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Ingo Molnar <mingo@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Hugh Dickins <hugh@...itas.com>,
	Ulrich Drepper <drepper@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH, v3] shmat: introduce flag SHM_MAP_NOT_FIXED

On Wed, Oct 08, 2008 at 09:58:51AM +0100, Alan Cox wrote:
> > > 	shmat giving an address
> > > 	if error
> > > 		shmat giving no address
> > > 
> > > from user space.
> > 
> > No you can't here because shmat() starts searching from the wrong
> > start address.
> 
> If you are only hinting a desired address then that by the very meaning
> of the word "hint" means you will accept a different one.

The point is to be able to let the search start below the range
the kernel would normally start. It doesn't say that it has
to be at address X.

Yes hint is a little misleading, search hint is better.

> 
> > The only way would be to search manually in /proc/self/maps
> > and handle the races, but I hope you're not advocating that.
> 
> Gak, mmap a range to find a space and then shmat over the top of that.

That is racy when multi threaded because shmat() doesn't replace, so you 
would need to munmap() inbetween and someone else could steal the area
then. Yes you could stick a loop around it. It could livelock.
No, it's not a good interface I would advocate.

BTW the only alternative I would possiblye consider for the qemu case is to
force compat_shmat() to always allocate in 4GB (right now it relies
on the personality) and then let 64bit qemu use the int 0x80 entry point
for that.  But it's more hackish than the imho cleaner and more 
general flag.

-Andi

-- 
ak@...ux.intel.com
--
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/