On Wed, 4 Jul 2007, Andy Isaacson wrote:
> On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote:
> > You could easily replace the cookie with a pointer to a free
> > page pool.
>
> It just occurred to me that something like this is *required* to get the
> performance benefit from
On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote:
> You could easily replace the cookie with a pointer to a free
> page pool.
It just occurred to me that something like this is *required* to get the
performance benefit from MAP_NOZERO on a busy system. With Davide's
current proposal,
On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote:
You could easily replace the cookie with a pointer to a free
page pool.
It just occurred to me that something like this is *required* to get the
performance benefit from MAP_NOZERO on a busy system. With Davide's
current proposal,
On Wed, 4 Jul 2007, Andy Isaacson wrote:
On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote:
You could easily replace the cookie with a pointer to a free
page pool.
It just occurred to me that something like this is *required* to get the
performance benefit from MAP_NOZERO on a
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 <[EMAIL PROTECTED]> wrote:
> > > > That should not happen. The default SELinux configuration
> > > > in Fedora (and Debian?) runs a few daemons in
Davide Libenzi wrote:
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
On 7/2/07, Rik van Riel <[EMAIL PROTECTED]> 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
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
> On 7/2/07, Rik van Riel <[EMAIL PROTECTED]> 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,
On Mon, 2 Jul 2007, Andy Isaacson wrote:
> On Sat, Jun 30, 2007 at 12:03:07PM -0700, Davide Libenzi wrote:
> > I think the focus should be to find a case where under the currently
> > implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security
> > WRT no MAP_NOZERO. I have not
On 7/2/07, Rik van Riel <[EMAIL PROTECTED]> 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
Andy Isaacson wrote:
On Sat, Jun 30, 2007 at 08:21:52PM -0400, Kyle Moffett wrote:
That's why you'd need to call an LSM hook to get a unique identifier,
as the LSM would actually need to allocate identifiers for
equivalence classes. Secondly, processes may change labels as they
run, so
On Sat, Jun 30, 2007 at 08:21:52PM -0400, Kyle Moffett wrote:
> That's why you'd need to call an LSM hook to get a unique identifier,
> as the LSM would actually need to allocate identifiers for
> equivalence classes. Secondly, processes may change labels as they
> run, so you couldn't just
On Sat, Jun 30, 2007 at 12:03:07PM -0700, Davide Libenzi wrote:
> I think the focus should be to find a case where under the currently
> implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security
> WRT no MAP_NOZERO. I have not been able to find one yet, although Andy
> found
On Sat, Jun 30, 2007 at 12:03:07PM -0700, Davide Libenzi wrote:
I think the focus should be to find a case where under the currently
implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security
WRT no MAP_NOZERO. I have not been able to find one yet, although Andy
found a
On Sat, Jun 30, 2007 at 08:21:52PM -0400, Kyle Moffett wrote:
That's why you'd need to call an LSM hook to get a unique identifier,
as the LSM would actually need to allocate identifiers for
equivalence classes. Secondly, processes may change labels as they
run, so you couldn't just
Andy Isaacson wrote:
On Sat, Jun 30, 2007 at 08:21:52PM -0400, Kyle Moffett wrote:
That's why you'd need to call an LSM hook to get a unique identifier,
as the LSM would actually need to allocate identifiers for
equivalence classes. Secondly, processes may change labels as they
run, so
On 7/2/07, Rik van Riel [EMAIL PROTECTED] 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
On Mon, 2 Jul 2007, Andy Isaacson wrote:
On Sat, Jun 30, 2007 at 12:03:07PM -0700, Davide Libenzi wrote:
I think the focus should be to find a case where under the currently
implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security
WRT no MAP_NOZERO. I have not been
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
On 7/2/07, Rik van Riel [EMAIL PROTECTED] 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
Davide Libenzi wrote:
On Mon, 2 Jul 2007, Ulrich Drepper wrote:
On 7/2/07, Rik van Riel [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
That should not happen. The default SELinux configuration
in Fedora (and Debian?) runs a few daemons in their own
On Sat, 30 Jun 2007, Kyle Moffett wrote:
> On Jun 30, 2007, at 19:57:18, Davide Libenzi wrote:
> > On Sat, 30 Jun 2007, Kyle Moffett wrote:
> > > Very simple case: SELinux is turned on, an s9 (IE: TOP_SECRET) process
> > > calls free(), and an s3 (IE: UNCLASSIFIED) process calls malloc(),
On Jun 30, 2007, at 19:57:18, Davide Libenzi wrote:
On Sat, 30 Jun 2007, Kyle Moffett wrote:
Very simple case: SELinux is turned on, an s9 (IE: TOP_SECRET)
process calls free(), and an s3 (IE: UNCLASSIFIED) process calls
malloc(), getting the data from the TOP_SECRET process.
Note that
On Sat, 30 Jun 2007, Kyle Moffett wrote:
> On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
> > Hmm, why would you need MAP_REUSABLE? If a page is visible at any time for a
> > given UID, and you have a login under such UID, you can fetch the content of
> > the page at any time (ie,
On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
Hmm, why would you need MAP_REUSABLE? If a page is visible at any
time for a given UID, and you have a login under such UID, you can
fetch the content of the page at any time (ie, ptrace_attach,
gdb, ...).
Not under SELinux or other
On Fri, 29 Jun 2007, Kyle Moffett wrote:
> Well I would be very interested in actually being able to use this feature
> under SELinux, I think that just the underlying "can-I-use-this-page" logic
> needs modification. Maybe "MAP_REUSABLE"? That would both imply that we can
> accept reused (IE:
On Fri, 29 Jun 2007, Kyle Moffett wrote:
Well I would be very interested in actually being able to use this feature
under SELinux, I think that just the underlying can-I-use-this-page logic
needs modification. Maybe MAP_REUSABLE? That would both imply that we can
accept reused (IE:
On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
Hmm, why would you need MAP_REUSABLE? If a page is visible at any
time for a given UID, and you have a login under such UID, you can
fetch the content of the page at any time (ie, ptrace_attach,
gdb, ...).
Not under SELinux or other
On Sat, 30 Jun 2007, Kyle Moffett wrote:
On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
Hmm, why would you need MAP_REUSABLE? If a page is visible at any time for a
given UID, and you have a login under such UID, you can fetch the content of
the page at any time (ie, ptrace_attach,
On Jun 30, 2007, at 19:57:18, Davide Libenzi wrote:
On Sat, 30 Jun 2007, Kyle Moffett wrote:
Very simple case: SELinux is turned on, an s9 (IE: TOP_SECRET)
process calls free(), and an s3 (IE: UNCLASSIFIED) process calls
malloc(), getting the data from the TOP_SECRET process.
Note that
On Sat, 30 Jun 2007, Kyle Moffett wrote:
On Jun 30, 2007, at 19:57:18, Davide Libenzi wrote:
On Sat, 30 Jun 2007, Kyle Moffett wrote:
Very simple case: SELinux is turned on, an s9 (IE: TOP_SECRET) process
calls free(), and an s3 (IE: UNCLASSIFIED) process calls malloc(), getting
the
On Jun 29, 2007, at 16:12:58, Davide Libenzi wrote:
On Fri, 29 Jun 2007, Andy Isaacson wrote:
I still think that using uid in mm_struct is wrong, and some kind
of abstraction is required. I called this "free pool" in
<[EMAIL PROTECTED]>, but I think that name is
misleading -- I am not
On Fri, 29 Jun 2007, Andy Isaacson wrote:
> On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
> > On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> > >So I implemented a rather quick hack that introduces a new mmap()
> > >flag MAP_NOZERO (only valid for anonymous mappings) and
On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
> On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> >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
On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
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
On Fri, 29 Jun 2007, Andy Isaacson wrote:
On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
So I implemented a rather quick hack that introduces a new mmap()
flag MAP_NOZERO (only valid for anonymous mappings) and the vma
On Jun 29, 2007, at 16:12:58, Davide Libenzi wrote:
On Fri, 29 Jun 2007, Andy Isaacson wrote:
I still think that using uid in mm_struct is wrong, and some kind
of abstraction is required. I called this free pool in
[EMAIL PROTECTED], but I think that name is
misleading -- I am not
On Thu, 28 Jun 2007, Kyle Moffett wrote:
> 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
On 6/28/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
That wants MAP_PRIVATE so that the kernel can also decide to not
swap these pages out to an unencrypted swap area.
That's not what MAP_PRIVATE means. MAP_PRIVATE is the opposite of
MAP_SHARED. It's meaningless for anonymous memory (which is
Kyle Moffett wrote:
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
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
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
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
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
Kyle Moffett wrote:
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
On 6/28/07, Rik van Riel [EMAIL PROTECTED] wrote:
That wants MAP_PRIVATE so that the kernel can also decide to not
swap these pages out to an unencrypted swap area.
That's not what MAP_PRIVATE means. MAP_PRIVATE is the opposite of
MAP_SHARED. It's meaningless for anonymous memory (which is
On Thu, 28 Jun 2007, Kyle Moffett wrote:
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
46 matches
Mail list logo
