FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 06-02-2008, 12:09 PM
Colin Watson
 
Default valgrind partially broken by current hardy-proposed kernel?

Hi,

I'm getting this rather strange effect with the -17.31 kernel:

<cjwatson@sarantium ~/src/debian/openssh/trunk/openssh>$ valgrind build-deb/ssh-add -l
valgrind: mmap(0x0, 90112) failed in UME with error 13 (Permission denied).

strace shows:

execve("/usr/bin/valgrind", ["valgrind", "build-deb/ssh-add", "-l"], [/* 65 vars */]) = 0
brk(0) = 0x805e000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f9f000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=86287, ...}) = 0
mmap2(NULL, 86287, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f89000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "177ELF111331260e1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0
mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e3a000
mmap2(0xb7f83000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7f83000
mmap2(0xb7f86000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f86000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e39000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e396b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f83000, 4096, PROT_READ) = 0
munmap(0xb7f89000, 86287) = 0
getpid() = 13468
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
geteuid32() = 1000
brk(0) = 0x805e000
brk(0x807f000) = 0x807f000
getppid() = 13467
stat64("/home/cjwatson/src/debian/openssh/trunk/openssh", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
open("/usr/bin/valgrind", O_RDONLY) = 3
fcntl64(3, F_DUPFD, 10) = 10
close(3) = 0
fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x8055a30, ~[RTMIN RT_1], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0
read(10, "#!/bin/sh -e
#
# Valgrind wrappe"..., 8192) = 711
stat64("/usr/lib/debug", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
execve("/usr/bin/valgrind.bin", ["/usr/bin/valgrind.bin", "build-deb/ssh-add", "-l"], [/* 69 vars */]) = 0
brk(0) = 0x804d000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fa0000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/i686/sse2/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/i686/sse2/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/i686/sse2", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/i686/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/i686", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/sse2/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/sse2/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/sse2", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/tls", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/i686/sse2/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/i686/sse2/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/i686/sse2", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/i686/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/i686/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/i686", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/sse2/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/sse2/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/sse2", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/cmov/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug/cmov", 0xbfdb1160) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/debug", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=86287, ...}) = 0
mmap2(NULL, 86287, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f8a000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "177ELF111331260e1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0
mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e3b000
mmap2(0xb7f84000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7f84000
mmap2(0xb7f87000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f87000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e3a000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a8c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f84000, 4096, PROT_READ) = 0
munmap(0xb7f8a000, 86287) = 0
open("build-deb/ssh-add", O_RDONLY) = 3
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0xb7f9f000
close(3) = 0
munmap(0xb7f9f000, 4096) = 0
readlink("/proc/self/exe", "/usr/bin/valgrind.bin", 4096) = 21
brk(0) = 0x804d000
brk(0x806e000) = 0x806e000
execve("/usr/lib/valgrind/x86-linux/memcheck", ["/usr/bin/valgrind.bin", "build-deb/ssh-add", "-l"], [/* 70 vars */]) = 0
open("/proc/self/maps", O_RDONLY) = 3
read(3, "38000000-38177000 r-xp 00000000 "..., 100000) = 341
read(3, "", 99659) = 0
close(3) = 0
mmap2(0x61f86000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61f86000
getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_DATA, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
getcwd("/home/cjwatson/src/debian/openssh/trunk/openssh", 4095) = 48
open("/home/cjwatson/.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("build-deb/ssh-add", O_RDONLY) = 3
stat64("build-deb/ssh-add", {st_mode=S_IFREG|0755, st_size=324982, ...}) = 0
geteuid32() = 1000
fstat64(3, {st_mode=S_IFREG|0755, st_size=324982, ...}) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, "177ELF1113312601"..., 4096) = 4096
lseek(3, 0, SEEK_SET) = 0
read(3, "177ELF1113312601"..., 52) = 52
lseek(3, 52, SEEK_SET) = 52
read(3, "6004004004115"..., 256) = 256
lseek(3, 308, SEEK_SET) = 308
read(3, "/lib/ld-linux.so.2", 19) = 19
open("/lib/ld-linux.so.2", O_RDONLY) = 4
lseek(4, 0, SEEK_SET) = 0
read(4, "177ELF1113312010"..., 52) = 52
lseek(4, 52, SEEK_SET) = 52
read(4, "1P2301P23015"..., 192) = 192
mmap2(NULL, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied)
write(2, "valgrind: mmap(0x0, 90112) faile"..., 76valgrind: mmap(0x0, 90112) failed in UME with error 13 (Permission denied).
) = 76
exit_group(1) = ?
Process 13468 detached

My best guess is that this is due to this commit:

commit 893f802872c3e3c6e4bb40c3be4845784b81b934
Author: Kees Cook <kees.cook@canonical.com>
Date: Tue Apr 8 13:51:05 2008 -0700

UBUNTU: AppArmor: implement mmap_min_addr check as done in mainline.
OriginalAuthor: John Johansen <jjohansen@suse.de>

Implement the missing mmap_min_addr check in AppArmor mmap wrapper.

Signed-off-by: John Johansen <jjohansen@suse.de>
Signed-off-by: Kees Cook <kees.cook@canonical.com>

Any idea what's going on here? Is this a valgrind bug or an apparmor
bug? Note that it doesn't seem to happen with things like 'valgrind ls'.

Thanks,

--
Colin Watson [cjwatson@ubuntu.com]

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-02-2008, 04:56 PM
Kees Cook
 
Default valgrind partially broken by current hardy-proposed kernel?

Hi Colin,

On Mon, Jun 02, 2008 at 01:09:44PM +0100, Colin Watson wrote:
> I'm getting this rather strange effect with the -17.31 kernel:
>
> <cjwatson@sarantium ~/src/debian/openssh/trunk/openssh>$ valgrind build-deb/ssh-add -l
> valgrind: mmap(0x0, 90112) failed in UME with error 13 (Permission denied).
>
> [snip]
> My best guess is that this is due to this commit:
>
> commit 893f802872c3e3c6e4bb40c3be4845784b81b934
> Author: Kees Cook <kees.cook@canonical.com>
> Date: Tue Apr 8 13:51:05 2008 -0700
>
> UBUNTU: AppArmor: implement mmap_min_addr check as done in mainline.
> OriginalAuthor: John Johansen <jjohansen@suse.de>
>
> Implement the missing mmap_min_addr check in AppArmor mmap wrapper.
>
> Signed-off-by: John Johansen <jjohansen@suse.de>
> Signed-off-by: Kees Cook <kees.cook@canonical.com>
>
> Any idea what's going on here? Is this a valgrind bug or an apparmor
> bug? Note that it doesn't seem to happen with things like 'valgrind ls'.

That change was made for the release kernel, so you should see it with
-16 too. Blocking NULL is a feature.

Why is ssh-add trying to allocate memory at 0x0?

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-02-2008, 08:34 PM
Colin Watson
 
Default valgrind partially broken by current hardy-proposed kernel?

On Mon, Jun 02, 2008 at 09:56:13AM -0700, Kees Cook wrote:
> That change was made for the release kernel, so you should see it with
> -16 too. Blocking NULL is a feature.
>
> Why is ssh-add trying to allocate memory at 0x0?

It's not. If anything in userspace is doing that it's valgrind (or
possibly ld-linux itself, but it doesn't show up in an strace of ssh-add
alone).

--
Colin Watson [cjwatson@ubuntu.com]

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-02-2008, 10:00 PM
Ben Collins
 
Default valgrind partially broken by current hardy-proposed kernel?

On Mon, 2008-06-02 at 09:56 -0700, Kees Cook wrote:
> Hi Colin,
>
> On Mon, Jun 02, 2008 at 01:09:44PM +0100, Colin Watson wrote:
> > I'm getting this rather strange effect with the -17.31 kernel:
> >
> > <cjwatson@sarantium ~/src/debian/openssh/trunk/openssh>$ valgrind build-deb/ssh-add -l
> > valgrind: mmap(0x0, 90112) failed in UME with error 13 (Permission denied).
> >
> > [snip]
> > My best guess is that this is due to this commit:
> >
> > commit 893f802872c3e3c6e4bb40c3be4845784b81b934
> > Author: Kees Cook <kees.cook@canonical.com>
> > Date: Tue Apr 8 13:51:05 2008 -0700
> >
> > UBUNTU: AppArmor: implement mmap_min_addr check as done in mainline.
> > OriginalAuthor: John Johansen <jjohansen@suse.de>
> >
> > Implement the missing mmap_min_addr check in AppArmor mmap wrapper.
> >
> > Signed-off-by: John Johansen <jjohansen@suse.de>
> > Signed-off-by: Kees Cook <kees.cook@canonical.com>
> >
> > Any idea what's going on here? Is this a valgrind bug or an apparmor
> > bug? Note that it doesn't seem to happen with things like 'valgrind ls'.
>
> That change was made for the release kernel, so you should see it with
> -16 too. Blocking NULL is a feature.
>
> Why is ssh-add trying to allocate memory at 0x0?

>From what I can tell, mmap'ing to 0x0(NULL) is perfectly legitimate.
>From mmap(2):

....
If start is NULL, then the kernel chooses the address at which
to create the mapping; this is the most portable method of
creating a new mapping. If start is not NULL, then the kernel
takes it as a hint about where to place the mapping; on Linux,
the mapping will be created at the next higher page boundary.
The address of the new mapping is returned as the result of the
call.
....

Being that it is the most portable method, it should probably not fail
by default Perhaps the check should be for values > 0x0, but less
than some (dangerous?) lower boundary.

> -Kees
>
> --
> Kees Cook
> Ubuntu Security Team
>


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-02-2008, 10:01 PM
Kees Cook
 
Default valgrind partially broken by current hardy-proposed kernel?

On Mon, Jun 02, 2008 at 09:34:51PM +0100, Colin Watson wrote:
> On Mon, Jun 02, 2008 at 09:56:13AM -0700, Kees Cook wrote:
> > That change was made for the release kernel, so you should see it with
> > -16 too. Blocking NULL is a feature.

Just so we're working on a single variable, does -16 show the behavior?

> > Why is ssh-add trying to allocate memory at 0x0?
>
> It's not. If anything in userspace is doing that it's valgrind (or
> possibly ld-linux itself, but it doesn't show up in an strace of ssh-add
> alone).

How very strange. You can easily disable it -- it's just a sysctl
setting:

# protect bottom 64k of memory from mmap to prevent NULL-dereference
# attacks against potential future kernel security vulnerabilities.
# (Added in kernel 2.6.23.)
vm.mmap_min_addr = 65536

Just set that to 0 and you should have it back.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-02-2008, 10:05 PM
Colin Watson
 
Default valgrind partially broken by current hardy-proposed kernel?

On Mon, Jun 02, 2008 at 06:00:21PM -0400, Ben Collins wrote:
> On Mon, 2008-06-02 at 09:56 -0700, Kees Cook wrote:
> > That change was made for the release kernel, so you should see it with
> > -16 too. Blocking NULL is a feature.
> >
> > Why is ssh-add trying to allocate memory at 0x0?
>
> >From what I can tell, mmap'ing to 0x0(NULL) is perfectly legitimate.
> >From mmap(2):
>
> ....
> If start is NULL, then the kernel chooses the address at which
> to create the mapping; this is the most portable method of
> creating a new mapping. If start is not NULL, then the kernel
> takes it as a hint about where to place the mapping; on Linux,
> the mapping will be created at the next higher page boundary.
> The address of the new mapping is returned as the result of the
> call.
> ....

That doesn't apply if you use MAP_FIXED, though, does it?

> Being that it is the most portable method, it should probably not fail
> by default Perhaps the check should be for values > 0x0, but less
> than some (dangerous?) lower boundary.

I glanced through the code and it looks like the address assignment for
non-MAP_FIXED is done before this check.

Cheers,

--
Colin Watson [cjwatson@ubuntu.com]

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-02-2008, 10:07 PM
Kees Cook
 
Default valgrind partially broken by current hardy-proposed kernel?

On Mon, Jun 02, 2008 at 06:00:21PM -0400, Ben Collins wrote:
> On Mon, 2008-06-02 at 09:56 -0700, Kees Cook wrote:
> > On Mon, Jun 02, 2008 at 01:09:44PM +0100, Colin Watson wrote:
> > mmap2(NULL, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied)
> >
> > That change was made for the release kernel, so you should see it with
> > -16 too. Blocking NULL is a feature.
> >
> > Why is ssh-add trying to allocate memory at 0x0?
>
> >From what I can tell, mmap'ing to 0x0(NULL) is perfectly legitimate.
> >From mmap(2):
>
> ....
> If start is NULL, then the kernel chooses the address at which
> to create the mapping; this is the most portable method of
> creating a new mapping. If start is not NULL, then the kernel
> takes it as a hint about where to place the mapping; on Linux,
> the mapping will be created at the next higher page boundary.
> The address of the new mapping is returned as the result of the
> call.
> ....
>
> Being that it is the most portable method, it should probably not fail
> by default Perhaps the check should be for values > 0x0, but less
> than some (dangerous?) lower boundary.

True, but the mmap_min_addr setting only affects MAP_FIXED, in which
you really want address 0. (And yes, that's valid, but not common.)
The common use-case of use NULL to just get an arbitrary mapping is done
without MAP_FIXED.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-04-2008, 12:30 PM
Matthew Garrett
 
Default valgrind partially broken by current hardy-proposed kernel?

On Mon, Jun 02, 2008 at 03:07:10PM -0700, Kees Cook wrote:

> True, but the mmap_min_addr setting only affects MAP_FIXED, in which
> you really want address 0. (And yes, that's valid, but not common.)
> The common use-case of use NULL to just get an arbitrary mapping is done
> without MAP_FIXED.

vbetool needs to map address 0 with MAP_FIXED in order to get the IDT.
--
Matthew Garrett | mjg59@srcf.ucam.org

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-04-2008, 03:12 PM
Kees Cook
 
Default valgrind partially broken by current hardy-proposed kernel?

Hi,

On Wed, Jun 04, 2008 at 01:30:55PM +0100, Matthew Garrett wrote:
> On Mon, Jun 02, 2008 at 03:07:10PM -0700, Kees Cook wrote:
>
> > True, but the mmap_min_addr setting only affects MAP_FIXED, in which
> > you really want address 0. (And yes, that's valid, but not common.)
> > The common use-case of use NULL to just get an arbitrary mapping is done
> > without MAP_FIXED.
>
> vbetool needs to map address 0 with MAP_FIXED in order to get the IDT.

Yes, but it (and usplash) run as root, which is exempt from this check.
(Wine and dosemu use this area as well, and for those use cases, people
have been advised to change the limit back to 0. For the default use-cases,
there is no problem.)

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-04-2008, 03:33 PM
Ben Collins
 
Default valgrind partially broken by current hardy-proposed kernel?

On Wed, 2008-06-04 at 08:12 -0700, Kees Cook wrote:
> Hi,
>
> On Wed, Jun 04, 2008 at 01:30:55PM +0100, Matthew Garrett wrote:
> > On Mon, Jun 02, 2008 at 03:07:10PM -0700, Kees Cook wrote:
> >
> > > True, but the mmap_min_addr setting only affects MAP_FIXED, in which
> > > you really want address 0. (And yes, that's valid, but not common.)
> > > The common use-case of use NULL to just get an arbitrary mapping is done
> > > without MAP_FIXED.
> >
> > vbetool needs to map address 0 with MAP_FIXED in order to get the IDT.
>
> Yes, but it (and usplash) run as root, which is exempt from this check.
> (Wine and dosemu use this area as well, and for those use cases, people
> have been advised to change the limit back to 0. For the default use-cases,
> there is no problem.)

So what danger is imposed by the non-root use case being able to mmap
below 64k?


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 11:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org