linux-kernel - Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP

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: <Pine.LNX.4.64.0707021619590.14774@alien.or.mcafeemobile.com>
Date:	Mon, 2 Jul 2007 16:46:52 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Rik van Riel <riel@...hat.com>
cc:	Ulrich Drepper <drepper@...il.com>,
	Andy Isaacson <adi@...apodia.org>,
	Kyle Moffett <mrmacman_g4@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer
 madness

On Mon, 2 Jul 2007, Rik van Riel wrote:

> Davide Libenzi wrote:
> > On Mon, 2 Jul 2007, Ulrich Drepper wrote:
> > 
> > > On 7/2/07, Rik van Riel <riel@...hat.com> wrote:
> > > > That should not happen.  The default SELinux configuration
> > > > in Fedora (and Debian?) runs a few daemons in their own
> > > > restricted modes and has most of the system running in
> > > > unconfined_t, including the majority of user programs.
> > > This is the state as of F7.  This will change hopefully soon.
> > > Programs like firefox run by normal users must be confined, to. Any
> > > tests using security must be fast, it's not something which is done
> > > only for a few apps.
> > 
> > The strong requirement would be that the cookie is not a bit longer than
> > sizeof(unsigned long).
> 
> You could easily replace the cookie with a pointer to a free
> page pool.

You talked about this pool even before, but honestly I don't see how it 
can help.
Pools requires management (mainly flush under pressure), and it wouldn't 
really do any benefit. Don't we already have enough pools in the 
allocation path?
The pool has to be UID (or cookie/whatever) based [1], so on top of the 
pool lookup/management code, you'll have another lock to be taken (the 
pool one). So using the UID (cookie) is simpler, faster and requires no 
extra code.
A simple numeric cookie virtually creates "pools" w/out requiring extra 
code. Yes, having really separate pool helps the recycle efficency, but 
I'm not sure that's worth the extra code.

[1] An mm_struct based pool would be clearly useless

- Davide

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