On Wed, 27 Jun 2007 15:11:49 -0700 Nicholas Miell <[EMAIL PROTECTED]> wrote:
> I don't think the security issues with this will ever make it
> worthwhile.
eh, security issues are a corner case.
The vast majority of Linux machines are used by a single user who has admin
access anyway. This
On Wed, 27 Jun 2007 15:11:49 -0700 Nicholas Miell [EMAIL PROTECTED] wrote:
I don't think the security issues with this will ever make it
worthwhile.
eh, security issues are a corner case.
The vast majority of Linux machines are used by a single user who has admin
access anyway. This includes
On Wed, 27 Jun 2007, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Nicholas Miell wrote:
>
> > 1) euid is not sufficient, you need to store away arbitrary LSM
> > information and call LSM hooks to decide security equivalence. The same
> > applies to VServer or whatever other container system you
On Wed, 27 Jun 2007, Nicholas Miell wrote:
> 1) euid is not sufficient, you need to store away arbitrary LSM
> information and call LSM hooks to decide security equivalence. The same
> applies to VServer or whatever other container system you use.
The EUID that is used now, can easily be any
On Wed, 2007-06-27 at 11:45 -0700, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Hugh Dickins wrote:
>
> > On Wed, 27 Jun 2007, Davide Libenzi wrote:
> > > On Wed, 27 Jun 2007, Hugh Dickins wrote:
> > >
> > > > In honesty, I should add that I dislike and distrust Davide's
> > > > MAP_NOZERO very
On Wed, 27 Jun 2007, Ulrich Drepper wrote:
> On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > The absolute virtual addresses are randomized, yes; but do a sequence
> > of mmaps and they come back adjacent to each other, and so mergable.
> > Or does your distro include a kernel patch to
On Wed, 27 Jun 2007, Rik van Riel wrote:
> Ulrich Drepper wrote:
> > On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > > Not so: if an mmap can be done by extending either adjacent vma (prot
> > > and flags and file and offset all match up), that's what's done and no
> > > separate vma is
Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged when mprotect
removes
On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
The absolute virtual addresses are randomized, yes; but do a sequence
of mmaps and they come back adjacent to each other, and so mergable.
Or does your distro include a kernel patch to randomize them relative
to each other?
Each individual
On Wed, 27 Jun 2007, Hugh Dickins wrote:
> On Wed, 27 Jun 2007, Davide Libenzi wrote:
> > On Wed, 27 Jun 2007, Hugh Dickins wrote:
> >
> > > In honesty, I should add that I dislike and distrust Davide's
> > > MAP_NOZERO very much indeed! Would much rather leave my cpus
> > > spending a little
On Wed, 27 Jun 2007, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Hugh Dickins wrote:
>
> > In honesty, I should add that I dislike and distrust Davide's
> > MAP_NOZERO very much indeed! Would much rather leave my cpus
> > spending a little time in clear_page(). A uid in struct page
> > (though
On Wed, 27 Jun 2007, Hugh Dickins wrote:
> In honesty, I should add that I dislike and distrust Davide's
> MAP_NOZERO very much indeed! Would much rather leave my cpus
> spending a little time in clear_page(). A uid in struct page
> (though I'm sure we could find somewhere to tuck it away) -
>
On Wed, 27 Jun 2007, Ulrich Drepper wrote:
> On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > Not so: if an mmap can be done by extending either adjacent vma (prot
> > and flags and file and offset all match up), that's what's done and no
> > separate vma is created. (And adjacent vmas get
On 6/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged when mprotect
removes the difference in
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
> On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > I acutally have the code for it, but I never posted it since it did not
> > receive a too warm review (and the only user was the fdmap thingy).
>
> Only user of sys_indirect? There will be
On Wed, 27 Jun 2007, Hugh Dickins wrote:
> On Tue, 26 Jun 2007, Ulrich Drepper wrote:
> > On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> >
> > > OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence
> > > brk2() would not be needed, no?
> >
> > No. mmap calls create
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
> On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence
> > brk2() would not be needed, no?
>
> No. mmap calls create individual VMAs which gets expensive. There
> are also
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence
brk2() would not be needed, no?
No. mmap calls create individual VMAs which gets expensive. There
are also some
On Wed, 27 Jun 2007, Hugh Dickins wrote:
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
OTOH glibc could implement __morecore using mmap(MAP_NOZERO), and hence
brk2() would not be needed, no?
No. mmap calls create individual VMAs
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
I acutally have the code for it, but I never posted it since it did not
receive a too warm review (and the only user was the fdmap thingy).
Only user of sys_indirect? There will be quite a few
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged when mprotect
removes the difference in
On Wed, 27 Jun 2007, Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged
On Wed, 27 Jun 2007, Hugh Dickins wrote:
In honesty, I should add that I dislike and distrust Davide's
MAP_NOZERO very much indeed! Would much rather leave my cpus
spending a little time in clear_page(). A uid in struct page
(though I'm sure we could find somewhere to tuck it away) -
the
On Wed, 27 Jun 2007, Davide Libenzi wrote:
On Wed, 27 Jun 2007, Hugh Dickins wrote:
In honesty, I should add that I dislike and distrust Davide's
MAP_NOZERO very much indeed! Would much rather leave my cpus
spending a little time in clear_page(). A uid in struct page
(though I'm sure
On Wed, 27 Jun 2007, Hugh Dickins wrote:
On Wed, 27 Jun 2007, Davide Libenzi wrote:
On Wed, 27 Jun 2007, Hugh Dickins wrote:
In honesty, I should add that I dislike and distrust Davide's
MAP_NOZERO very much indeed! Would much rather leave my cpus
spending a little time in
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
The absolute virtual addresses are randomized, yes; but do a sequence
of mmaps and they come back adjacent to each other, and so mergable.
Or does your distro include a kernel patch to randomize them relative
to each other?
Each individual mmap
Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And adjacent vmas get merged when mprotect
removes the
On Wed, 27 Jun 2007, Rik van Riel wrote:
Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Not so: if an mmap can be done by extending either adjacent vma (prot
and flags and file and offset all match up), that's what's done and no
separate vma is created. (And
On Wed, 27 Jun 2007, Ulrich Drepper wrote:
On 6/27/07, Hugh Dickins [EMAIL PROTECTED] wrote:
The absolute virtual addresses are randomized, yes; but do a sequence
of mmaps and they come back adjacent to each other, and so mergable.
Or does your distro include a kernel patch to randomize
On Wed, 2007-06-27 at 11:45 -0700, Davide Libenzi wrote:
On Wed, 27 Jun 2007, Hugh Dickins wrote:
On Wed, 27 Jun 2007, Davide Libenzi wrote:
On Wed, 27 Jun 2007, Hugh Dickins wrote:
In honesty, I should add that I dislike and distrust Davide's
MAP_NOZERO very much indeed!
On Wed, 27 Jun 2007, Nicholas Miell wrote:
1) euid is not sufficient, you need to store away arbitrary LSM
information and call LSM hooks to decide security equivalence. The same
applies to VServer or whatever other container system you use.
The EUID that is used now, can easily be any
On Wed, 27 Jun 2007, Davide Libenzi wrote:
On Wed, 27 Jun 2007, Nicholas Miell wrote:
1) euid is not sufficient, you need to store away arbitrary LSM
information and call LSM hooks to decide security equivalence. The same
applies to VServer or whatever other container system you use.
On 6/26/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
After going through the first malloc()/free() cycle, surely
the memory will no longer be zeroed on the second malloc() ?
If returned to the system, sure.
What makes the first brk malloc so special?
If the memory is zeroed it needs not be
On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
I acutally have the code for it, but I never posted it since it did not
receive a too warm review (and the only user was the fdmap thingy).
Only user of sys_indirect? There will be quite a few right away.
Every syscall that returns a file
Ulrich Drepper wrote:
On 6/26/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
Since programs can get back free()d memory after a malloc(),
with the old contents of the memory intact, surely your
MAP_NONZERO behavior could be the default for programs that
can get away with it?
Maybe we could use
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
> On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > The following patch implements the sys_brk2() syscall, that nothing is
> > other than a sys_brk() with an extra "flags" parameter.
>
> Shouldn't we wait for Linus' sys_indirect to arrive and
On 6/26/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra "flags" parameter.
Shouldn't we wait for Linus' sys_indirect to arrive and make this
another syscall which takes advantage of it?
-
On 6/26/07, Rik van Riel <[EMAIL PROTECTED]> wrote:
Since programs can get back free()d memory after a malloc(),
with the old contents of the memory intact, surely your
MAP_NONZERO behavior could be the default for programs that
can get away with it?
Maybe we could use some magic ELF header,
On Tue, 26 Jun 2007, Rik van Riel wrote:
> Davide Libenzi wrote:
> > The following patch implements the sys_brk2() syscall, that nothing is
> > other than a sys_brk() with an extra "flags" parameter. This can be used
> > to pass the new MAP_NOZERO bit, to ask the kernel to hand over non-zero
> >
Davide Libenzi wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra "flags" parameter. This can be used
to pass the new MAP_NOZERO bit, to ask the kernel to hand over non-zero
pages if possible.
Since programs can get back free()d
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra "flags" parameter. This can be used
to pass the new MAP_NOZERO bit, to ask the kernel to hand over non-zero
pages if possible.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra flags parameter. This can be used
to pass the new MAP_NOZERO bit, to ask the kernel to hand over non-zero
pages if possible.
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
Davide Libenzi wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra flags parameter. This can be used
to pass the new MAP_NOZERO bit, to ask the kernel to hand over non-zero
pages if possible.
Since programs can get back free()d
On Tue, 26 Jun 2007, Rik van Riel wrote:
Davide Libenzi wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra flags parameter. This can be used
to pass the new MAP_NOZERO bit, to ask the kernel to hand over non-zero
pages if
On 6/26/07, Rik van Riel [EMAIL PROTECTED] wrote:
Since programs can get back free()d memory after a malloc(),
with the old contents of the memory intact, surely your
MAP_NONZERO behavior could be the default for programs that
can get away with it?
Maybe we could use some magic ELF header,
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra flags parameter.
Shouldn't we wait for Linus' sys_indirect to arrive and make this
another syscall which takes advantage of it?
-
To
On Tue, 26 Jun 2007, Ulrich Drepper wrote:
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
The following patch implements the sys_brk2() syscall, that nothing is
other than a sys_brk() with an extra flags parameter.
Shouldn't we wait for Linus' sys_indirect to arrive and make this
Ulrich Drepper wrote:
On 6/26/07, Rik van Riel [EMAIL PROTECTED] wrote:
Since programs can get back free()d memory after a malloc(),
with the old contents of the memory intact, surely your
MAP_NONZERO behavior could be the default for programs that
can get away with it?
Maybe we could use some
On 6/26/07, Davide Libenzi [EMAIL PROTECTED] wrote:
I acutally have the code for it, but I never posted it since it did not
receive a too warm review (and the only user was the fdmap thingy).
Only user of sys_indirect? There will be quite a few right away.
Every syscall that returns a file
On 6/26/07, Rik van Riel [EMAIL PROTECTED] wrote:
After going through the first malloc()/free() cycle, surely
the memory will no longer be zeroed on the second malloc() ?
If returned to the system, sure.
What makes the first brk malloc so special?
If the memory is zeroed it needs not be
50 matches
Mail list logo
