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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 28 Jun 2007 22:57:00 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rik van Riel <riel@...hat.com>,
	Andy Isaacson <adi@...apodia.org>
Subject: Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> I was using oprofile to sample some userspace code I am working on,  
> and I was continuosly noticing  clear_page  in the top three  
> entries of the oprofile logs.
>
> Also, a simple kernel build, in my Dual Opteron with 8GB of RAM,  
> shows  clear_page  as the first kernel entry, second only to the  
> userspace the  cc1  and  as. Most of the userspace code uses malloc 
> () (and anonymous  mappings) in such a way that the memory returned  
> via kernel->glibc is immediately written soon after. The POSIX  
> malloc() definition itself also, does not require the returned  
> memory to be zeroed (as calloc() does).
>
> So I implemented a rather quick hack that introduces a new mmap()  
> flag MAP_NOZERO (only valid for anonymous mappings) and the  vma   
> counter-part VM_NOZERO. Also, a new sys_brk2() has been introduced  
> to accept a new flags  parameter. A brief description of the  
> patches follows in the next emails.

Hmm, sounds like this would also need a "MAP_NOREUSE" flag of some  
kind for security sensitive applications.  Basically, I wouldn't want  
my ssh-agent pages holding private SSH keys to be reused by my web  
browser which then gets exploited :-D.  It would also be a massive  
information leak under SELinux.  To fix it properly according to the  
SELinux model you would need to tag each page with a label  
immediately after it's freed and then do an access-vector-check  
against the old page and the new process before allowing reuse.  On  
the other hand, that would probably be at least as expensive as  
zeroing the page.

Cheers,
Kyle Moffett



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