From: Kyle Moffett <mrmacman_g4@mac.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>, Andy Isaacson <adi@hexapodia.org>
Subject: Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness
Date: Thu, 28 Jun 2007 22:57:00 -0400 [thread overview]
Message-ID: <EC4CE052-5514-465E-92D2-9D50DA970DDC@mac.com> (raw)
In-Reply-To: <send-serie.davidel@xmailserver.org.5792.1183056564.0>
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
next prev parent reply other threads:[~2007-06-29 2:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-28 18:49 [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness Davide Libenzi
2007-06-29 2:57 ` Kyle Moffett [this message]
2007-06-29 3:04 ` Rik van Riel
2007-06-29 5:09 ` Ulrich Drepper
2007-06-29 5:20 ` Davide Libenzi
2007-06-29 19:39 ` Andy Isaacson
2007-06-29 20:12 ` Davide Libenzi
2007-06-29 23:48 ` Kyle Moffett
2007-06-30 19:03 ` Davide Libenzi
2007-06-30 23:46 ` Kyle Moffett
2007-06-30 23:57 ` Davide Libenzi
2007-07-01 0:21 ` Kyle Moffett
2007-07-01 4:25 ` Davide Libenzi
2007-07-02 19:00 ` Andy Isaacson
2007-07-02 19:03 ` Rik van Riel
2007-07-02 19:06 ` Ulrich Drepper
2007-07-02 22:46 ` Davide Libenzi
2007-07-02 22:55 ` Rik van Riel
2007-07-02 23:46 ` Davide Libenzi
2007-07-04 21:53 ` Andy Isaacson
2007-07-04 23:42 ` Davide Libenzi
2007-07-02 18:38 ` Andy Isaacson
2007-07-02 22:38 ` Davide Libenzi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EC4CE052-5514-465E-92D2-9D50DA970DDC@mac.com \
--to=mrmacman_g4@mac.com \
--cc=adi@hexapodia.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox