some possible fixes in the OE web pages

some possible fixes in the OE web pages

[Robert P. J. Day]

  getting into ubuntu for the first time and working my way thru the
OE web pages, setting it up under ubuntu 10.04 so a few observations
-- do with them what you will

* on http://wiki.openembedded.net/index.php/OEandYourDistro#Ubuntu,
there's a reference to configuring for qemu-arm:

  echo 128 > /proc/sys/vm/mmap_min_addr

from memory, i always simply set that to zero on fedora.  is there
something magic about the value 128?  at the moment, it's at the
default value of 65536 on this ubuntu system.

* there's also (under debian, so might hold true under ubuntu as well)
a requirement to install "xmlto".  however, if you do a regular
install, you drag in a *massive* amount of tex-related packages.
instead, one can theoretically use "fop" for PDF generation, and omit
all that tex stuff.  is it feasible to use fop instead and

  $ apt-get install --no-install-recommends xmlto

  i think there was something else but it escapes me at the moment.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: some possible fixes in the OE web pages

[Roman I Khimov]

[-- Attachment #1: Type: Text/Plain, Size: 662 bytes --]

В сообщении от Четверг 13 мая 2010 01:30:53 автор Robert P. J. Day написал:
> * on http://wiki.openembedded.net/index.php/OEandYourDistro#Ubuntu,
> there's a reference to configuring for qemu-arm:
> 
>   echo 128 > /proc/sys/vm/mmap_min_addr
> 
> from memory, i always simply set that to zero on fedora.  is there
> something magic about the value 128?  at the moment, it's at the
> default value of 65536 on this ubuntu system.

With current qemu in OE mmap_min_addr tricks are not needed at all.

-- 
 http://roman.khimov.ru
mailto: roman@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: some possible fixes in the OE web pages

[Martin Jansa]

On Thu, May 13, 2010 at 09:53:54AM +0400, Roman I Khimov wrote:
> В сообщении от Четверг 13 мая 2010 01:30:53 автор Robert P. J. Day написал:
> > * on http://wiki.openembedded.net/index.php/OEandYourDistro#Ubuntu,
> > there's a reference to configuring for qemu-arm:
> > 
> >   echo 128 > /proc/sys/vm/mmap_min_addr
> > 
> > from memory, i always simply set that to zero on fedora.  is there
> > something magic about the value 128?  at the moment, it's at the
> > default value of 65536 on this ubuntu system.
> 
> With current qemu in OE mmap_min_addr tricks are not needed at all.

Hi,

On some systems (I have report from fedora and kubuntu) it still needs 0
in mmap_min_addr :/.

Investigating why, but it's slow because it doesn't fail on my box.

My guess is that this chunk from
http://git.qemu.org/qemu.git/tree/linux-user/main.c
cannot work on systems where normal user is not allowed to read 
/proc/sys/vm/mmap_min_addr and mmap_min_addr is not initialized with
sane value.

    /*
     * Read in mmap_min_addr kernel parameter.  This value is used
     * When loading the ELF image to determine whether guest_base
     * is needed.  It is also used in mmap_find_vma.
     */
    {
        FILE *fp;

        if ((fp = fopen("/proc/sys/vm/mmap_min_addr", "r")) != NULL) {
            unsigned long tmp;
            if (fscanf(fp, "%lu", &tmp) == 1) {
                mmap_min_addr = tmp;
                qemu_log("host mmap_min_addr=0x%lx\n", mmap_min_addr);
            }
            fclose(fp);
        }
    }

But here (gentoo) it works ok with 4096 in mmap_min_addr and qemu-native
from OE as well as app-emulation/qemu-kvm-0.12.3* from gentoo.

BTW: 0.12.4 is out, but in changelog I don't see anything I must have.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: some possible fixes in the OE web pages

[Roman I Khimov]

В сообщении от Четверг 13 мая 2010 10:40:37 автор Martin Jansa написал:
> On Thu, May 13, 2010 at 09:53:54AM +0400, Roman I Khimov wrote:
> > В сообщении от Четверг 13 мая 2010 01:30:53 автор Robert P. J. Day 
написал:
> > > * on http://wiki.openembedded.net/index.php/OEandYourDistro#Ubuntu,
> > > there's a reference to configuring for qemu-arm:
> > >
> > >   echo 128 > /proc/sys/vm/mmap_min_addr
> > >
> > > from memory, i always simply set that to zero on fedora.  is there
> > > something magic about the value 128?  at the moment, it's at the
> > > default value of 65536 on this ubuntu system.
> >
> > With current qemu in OE mmap_min_addr tricks are not needed at all.
> 
> On some systems (I have report from fedora and kubuntu) it still needs 0
> in mmap_min_addr :/.
> 
> Investigating why, but it's slow because it doesn't fail on my box.
> 
> My guess is that this chunk from
> http://git.qemu.org/qemu.git/tree/linux-user/main.c
> cannot work on systems where normal user is not allowed to read
> /proc/sys/vm/mmap_min_addr and mmap_min_addr is not initialized with
> sane value.

Just checked with Ubuntu and Fedora, it really isn't possible to read 
/proc/sys/vm/mmap_min_addr as regular user, although it has 644 permissions on 
it. "Security"? Damn.

[after 15 minutes]

OK, actually there is a useful entry on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568844

The real solution is in the kernel, it should be fixed for latest Ubuntu and 
hopefully Fedora will catch up on this issue too.

http://git.kernel.org/?p=linux/kernel/git/jmorris/security-
testing-2.6.git;a=commitdiff;h=822cceec7248013821d655545ea45d1c6a9d15b3

Interesting that openSUSE with 2.6.31 kernel doesn't have such problems... And 
our main build machine with Debian stable + 2.6.30 kernel works fine too. 
Probably this check got introduced in 2.6.32.

Well, as the problem is in the kernel really, I think everyone having this 
problem should push distro maintainers to update kernels with the tiny fix 
mentioned above. But as a workaround, yep, "0" setting might work (beware that 
it might also not work as in here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/423513
).

Re: some possible fixes in the OE web pages

[Martin Jansa]

On Thu, May 13, 2010 at 12:23:22PM +0400, Roman I Khimov wrote:
> В сообщении от Четверг 13 мая 2010 10:40:37 автор Martin Jansa написал:
> > On Thu, May 13, 2010 at 09:53:54AM +0400, Roman I Khimov wrote:
> > > В сообщении от Четверг 13 мая 2010 01:30:53 автор Robert P. J. Day 
> написал:
> > > > * on http://wiki.openembedded.net/index.php/OEandYourDistro#Ubuntu,
> > > > there's a reference to configuring for qemu-arm:
> > > >
> > > >   echo 128 > /proc/sys/vm/mmap_min_addr
> > > >
> > > > from memory, i always simply set that to zero on fedora.  is there
> > > > something magic about the value 128?  at the moment, it's at the
> > > > default value of 65536 on this ubuntu system.
> > >
> > > With current qemu in OE mmap_min_addr tricks are not needed at all.
> > 
> > On some systems (I have report from fedora and kubuntu) it still needs 0
> > in mmap_min_addr :/.
> > 
> > Investigating why, but it's slow because it doesn't fail on my box.
> > 
> > My guess is that this chunk from
> > http://git.qemu.org/qemu.git/tree/linux-user/main.c
> > cannot work on systems where normal user is not allowed to read
> > /proc/sys/vm/mmap_min_addr and mmap_min_addr is not initialized with
> > sane value.
> 
> Just checked with Ubuntu and Fedora, it really isn't possible to read 
> /proc/sys/vm/mmap_min_addr as regular user, although it has 644 permissions on 
> it. "Security"? Damn.
> 
> [after 15 minutes]
> 
> OK, actually there is a useful entry on Launchpad:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568844
> 
> The real solution is in the kernel, it should be fixed for latest Ubuntu and 
> hopefully Fedora will catch up on this issue too.
> 
> http://git.kernel.org/?p=linux/kernel/git/jmorris/security-
> testing-2.6.git;a=commitdiff;h=822cceec7248013821d655545ea45d1c6a9d15b3
> 
> Interesting that openSUSE with 2.6.31 kernel doesn't have such problems... And 
> our main build machine with Debian stable + 2.6.30 kernel works fine too. 
> Probably this check got introduced in 2.6.32.

Hi,

tt was introduced somewhere in 2.6.33-rc[12]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0e1a6ef2dea88101b056b6d9984f3325c5efced3
see my commit:
http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1b426b8382d2a7864b63051b0707e577f2c0ce69

but really strange thing is:
bitbake@jama ~/build.dev.shr.gta $ cat /proc/sys/vm/mmap_min_addr
cat: /proc/sys/vm/mmap_min_addr: Operation not permitted
root@jama series # cat /proc/sys/vm/mmap_min_addr
4096
Linux jama 2.6.34-rc7-JaMa-00056-gcea0d76 #7 SMP PREEMPT

and qemu-native/kqemu still works (probably simple cat is not good
test, maybe qemu-arm gets higher capabilities before trying to read it
and it's enough on my box and not enough somewhere else).

> Well, as the problem is in the kernel really, I think everyone having this 
> problem should push distro maintainers to update kernels with the tiny fix 
> mentioned above. But as a workaround, yep, "0" setting might work (beware that 
> it might also not work as in here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/423513
> ).

Another not tested workaround:

as qemu can work with (hopefully any) non-zero mmap_min_addr, maybe add
patch to linux-user/main.c that if it cannot read
/proc/sys/vm/mmap_min_addr then assume 65536 (ubuntu default)?

Regards,

> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: some possible fixes in the OE web pages

[Roman I Khimov]

В сообщении от Четверг 13 мая 2010 12:46:33 автор Martin Jansa написал:
> On Thu, May 13, 2010 at 12:23:22PM +0400, Roman I Khimov wrote:
> > Well, as the problem is in the kernel really, I think everyone having
> > this problem should push distro maintainers to update kernels with the
> > tiny fix mentioned above. But as a workaround, yep, "0" setting might
> > work (beware that it might also not work as in here:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/423513
> > ).
> 
> Another not tested workaround:
> 
> as qemu can work with (hopefully any) non-zero mmap_min_addr, maybe add
> patch to linux-user/main.c that if it cannot read
> /proc/sys/vm/mmap_min_addr then assume 65536 (ubuntu default)?

Fedora has the same default, so this should work.

Re: some possible fixes in the OE web pages

[Martin Jansa]

On Thu, May 13, 2010 at 12:59:13PM +0400, Roman I Khimov wrote:
> В сообщении от Четверг 13 мая 2010 12:46:33 автор Martin Jansa написал:
> > On Thu, May 13, 2010 at 12:23:22PM +0400, Roman I Khimov wrote:
> > > Well, as the problem is in the kernel really, I think everyone having
> > > this problem should push distro maintainers to update kernels with the
> > > tiny fix mentioned above. But as a workaround, yep, "0" setting might
> > > work (beware that it might also not work as in here:
> > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/423513
> > > ).
> > 
> > Another not tested workaround:
> > 
> > as qemu can work with (hopefully any) non-zero mmap_min_addr, maybe add
> > patch to linux-user/main.c that if it cannot read
> > /proc/sys/vm/mmap_min_addr then assume 65536 (ubuntu default)?
> 
> Fedora has the same default, so this should work.

Can we compare this simple test between working and non-working systems?

This is from working gentoo 2.6.34-rc7:

bitbake@jama ~/mmap-test $ wget http://build.shr-project.org/tests/jama/mmap-test.c
bitbake@jama ~/mmap-test $ gcc mmap-test.c -o mmap-test
bitbake@jama ~/mmap-test $ ./mmap-test
cannot read value from /proc/sys/vm/mmap_min_addr
bitbake@jama ~/mmap-test $ strace ./mmap-test
execve("./mmap-test", ["./mmap-test"], [/* 26 vars */]) = 0
brk(0)                                  = 0xded000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647150000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22777, ...}) = 0
mmap(NULL, 22777, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f764714a000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\354\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1424560, ...}) = 0
mmap(NULL, 3533704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7646bd5000
mprotect(0x7f7646d2a000, 2097152, PROT_NONE) = 0
mmap(0x7f7646f2a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155000) = 0x7f7646f2a000
mmap(0x7f7646f2f000, 19336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7646f2f000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647149000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647148000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647147000
arch_prctl(ARCH_SET_FS, 0x7f7647148700) = 0
mprotect(0x7f7646f2a000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ)     = 0
mprotect(0x7f7647151000, 4096, PROT_READ) = 0
munmap(0x7f764714a000, 22777)           = 0
brk(0)                                  = 0xded000
brk(0xe0e000)                           = 0xe0e000
open("/proc/sys/vm/mmap_min_addr", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f764714f000
read(3, 0x7f764714f000, 1024)           = -1 EPERM (Operation not permitted)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 16), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f764714e000
write(1, "cannot read value from /proc/sys"..., 50cannot read value from /proc/sys/vm/mmap_min_addr
) = 50
close(3)                                = 0
munmap(0x7f764714f000, 4096)            = 0
exit_group(0)                           = ?

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

QEMU mmap_min_addr issue Was: some possible fixes in the OE web pages

[Martin Jansa]

On Thu, May 13, 2010 at 11:23:20AM +0200, Martin Jansa wrote:
> On Thu, May 13, 2010 at 12:59:13PM +0400, Roman I Khimov wrote:
> > В сообщении от Четверг 13 мая 2010 12:46:33 автор Martin Jansa написал:
> > > On Thu, May 13, 2010 at 12:23:22PM +0400, Roman I Khimov wrote:
> > > > Well, as the problem is in the kernel really, I think everyone having
> > > > this problem should push distro maintainers to update kernels with the
> > > > tiny fix mentioned above. But as a workaround, yep, "0" setting might
> > > > work (beware that it might also not work as in here:
> > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/423513
> > > > ).
> > > 
> > > Another not tested workaround:
> > > 
> > > as qemu can work with (hopefully any) non-zero mmap_min_addr, maybe add
> > > patch to linux-user/main.c that if it cannot read
> > > /proc/sys/vm/mmap_min_addr then assume 65536 (ubuntu default)?
> > 
> > Fedora has the same default, so this should work.
> 
> Can we compare this simple test between working and non-working systems?
> 
> This is from working gentoo 2.6.34-rc7:
> 
> bitbake@jama ~/mmap-test $ wget http://build.shr-project.org/tests/jama/mmap-test.c
> bitbake@jama ~/mmap-test $ gcc mmap-test.c -o mmap-test
> bitbake@jama ~/mmap-test $ ./mmap-test
> cannot read value from /proc/sys/vm/mmap_min_addr
> bitbake@jama ~/mmap-test $ strace ./mmap-test
> execve("./mmap-test", ["./mmap-test"], [/* 26 vars */]) = 0
> brk(0)                                  = 0xded000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647150000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=22777, ...}) = 0
> mmap(NULL, 22777, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f764714a000
> close(3)                                = 0
> open("/lib/libc.so.6", O_RDONLY)        = 3
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\354\1\0\0\0\0\0"..., 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1424560, ...}) = 0
> mmap(NULL, 3533704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7646bd5000
> mprotect(0x7f7646d2a000, 2097152, PROT_NONE) = 0
> mmap(0x7f7646f2a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155000) = 0x7f7646f2a000
> mmap(0x7f7646f2f000, 19336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7646f2f000
> close(3)                                = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647149000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647148000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647147000
> arch_prctl(ARCH_SET_FS, 0x7f7647148700) = 0
> mprotect(0x7f7646f2a000, 16384, PROT_READ) = 0
> mprotect(0x600000, 4096, PROT_READ)     = 0
> mprotect(0x7f7647151000, 4096, PROT_READ) = 0
> munmap(0x7f764714a000, 22777)           = 0
> brk(0)                                  = 0xded000
> brk(0xe0e000)                           = 0xe0e000
> open("/proc/sys/vm/mmap_min_addr", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f764714f000
> read(3, 0x7f764714f000, 1024)           = -1 EPERM (Operation not permitted)
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 16), ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f764714e000
> write(1, "cannot read value from /proc/sys"..., 50cannot read value from /proc/sys/vm/mmap_min_addr
> ) = 50
> close(3)                                = 0
> munmap(0x7f764714f000, 4096)            = 0
> exit_group(0)                           = ?
> 
> Regards,

Another interesting test:
prepare rootfs of some image you have
I used: bitbake -c build -b ../dev/recipes/images/shr-image.bb

bitbake@jama ~/tmpdir-dev-shr/rootfs/shr-image $ qemu-arm -s 1048576 -r 2.6.24 -cpu arm926 -d exec  -L . bin/busybox >/dev/null
bitbake@jama ~/tmpdir-dev-shr/rootfs/shr-image $ cat /tmp/qemu.log
guest_base  0x0
start    end      size     prot
00008000-00070000 00068000 r-x
00070000-00071000 00001000 rw-
00071000-00073000 00002000 rwx
40000000-40100000 00100000 rw-
40100000-40101000 00001000 ---
40101000-4011c000 0001b000 r-x
4011c000-40123000 00007000 ---
40123000-40125000 00002000 rw-
40125000-42101000 01fdc000 ---
60000000-6223d000 0223d000 ---
63624000-6399e000 0037a000 ---
start_brk   0x00072b44
end_code    0x0006f6f4
start_code  0x00008000
start_data  0x00070000
end_data    0x00070824
start_stack 0x400ff268
brk         0x00072b44
entry       0x401017a0

and the same under root
jama shr-image # cat /tmp/qemu.log
host mmap_min_addr=0x1000
guest_base  0x0
start    end      size     prot
00008000-00070000 00068000 r-x
00070000-00071000 00001000 rw-
00071000-00073000 00002000 rwx
40000000-40100000 00100000 rw-
40100000-40101000 00001000 ---
40101000-4011c000 0001b000 r-x
4011c000-40123000 00007000 ---
40123000-40125000 00002000 rw-
40125000-42101000 01fdc000 ---
60000000-6223d000 0223d000 ---
630da000-63488000 003ae000 ---
start_brk   0x00072b44
end_code    0x0006f6f4
start_code  0x00008000
start_data  0x00070000
end_data    0x00070824
start_stack 0x400fef48
brk         0x00072b44
entry       0x401017a0

so here it also doesn't respect mmap_min_addr=0x1000 when using qemu-arm
under bitbake user.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: QEMU mmap_min_addr issue Was: some possible fixes in the OE web pages

[Martin Jansa]

On Thu, May 13, 2010 at 11:38:14AM +0200, Martin Jansa wrote:
> > Can we compare this simple test between working and non-working systems?

You can ignore both tests.. the difference is value of mmap_min_addr
4096 work OK
65536 fails for me too

I'll patch qemu-native to assume 65536 when it cannot read
mmap_min_addr.

Cheers,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: some possible fixes in the OE web pages

[Robert P. J. Day]

On Thu, 13 May 2010, Roman I Khimov wrote:

... mmap_min_addr stuff snipped ...

> The real solution is in the kernel, it should be fixed for latest
> Ubuntu and hopefully Fedora will catch up on this issue too.
>
> http://git.kernel.org/?p=linux/kernel/git/jmorris/security-
> testing-2.6.git;a=commitdiff;h=822cceec7248013821d655545ea45d1c6a9d15b3
>
> Interesting that openSUSE with 2.6.31 kernel doesn't have such
> problems... And our main build machine with Debian stable + 2.6.30
> kernel works fine too. Probably this check got introduced in 2.6.32.

  not sure which kernel *version* it showed up in, but it appears to
be a result of this commit from nov of last year (which you can see
ended up being unnecessarily restrictive -- d'oh!):

commit 0e1a6ef2dea88101b056b6d9984f3325c5efced3
Author: Kees Cook <kees.cook@canonical.com>
Date:   Sun Nov 8 09:37:00 2009 -0800

    sysctl: require CAP_SYS_RAWIO to set mmap_min_addr

    Currently the mmap_min_addr value can only be bypassed during mmap when
    the task has CAP_SYS_RAWIO.  However, the mmap_min_addr sysctl value itself
    can be adjusted to 0 if euid == 0, allowing a bypass without CAP_SYS_RAWIO.
    This patch adds a check for the capability before allowing mmap_min_addr to
    be changed.

    Signed-off-by: Kees Cook <kees.cook@canonical.com>
    Acked-by: Serge Hallyn <serue@us.ibm.com>
    Signed-off-by: James Morris <jmorris@namei.org>

diff --git a/security/min_addr.c b/security/min_addr.c
index c844eed..fc43c9d 100644
--- a/security/min_addr.c
+++ b/security/min_addr.c
@@ -33,6 +33,9 @@ int mmap_min_addr_handler(struct ctl_table *table,
int write,
 {
        int ret;

+       if (!capable(CAP_SYS_RAWIO))
+               return -EPERM;
+
        ret = proc_doulongvec_minmax(table, write, buffer, lenp, ppos);

        update_mmap_min_addr();


whereupon the security-related fix is, as was mentioned previously,
submitted here:

http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=commitdiff;h=822cceec7248013821d655545ea45d1c6a9d15b3


rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: some possible fixes in the OE web pages

[Martin Jansa]

On Thu, May 13, 2010 at 08:20:46AM -0400, Robert P. J. Day wrote:
> On Thu, 13 May 2010, Roman I Khimov wrote:
> 
> ... mmap_min_addr stuff snipped ...
> 
> > The real solution is in the kernel, it should be fixed for latest
> > Ubuntu and hopefully Fedora will catch up on this issue too.
> >
> > http://git.kernel.org/?p=linux/kernel/git/jmorris/security-
> > testing-2.6.git;a=commitdiff;h=822cceec7248013821d655545ea45d1c6a9d15b3
> >
> > Interesting that openSUSE with 2.6.31 kernel doesn't have such
> > problems... And our main build machine with Debian stable + 2.6.30
> > kernel works fine too. Probably this check got introduced in 2.6.32.
> 
>   not sure which kernel *version* it showed up in, but it appears to
> be a result of this commit from nov of last year (which you can see
> ended up being unnecessarily restrictive -- d'oh!):
> 
> commit 0e1a6ef2dea88101b056b6d9984f3325c5efced3
> Author: Kees Cook <kees.cook@canonical.com>
> Date:   Sun Nov 8 09:37:00 2009 -0800
> 
>     sysctl: require CAP_SYS_RAWIO to set mmap_min_addr

... repeated stuff snipped ...

You should finish reading the thread again :).

Yes, that's the same commit as 
http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1b426b8382d2a7864b63051b0707e577f2c0ce69
says.

Workaround to qemu-native already pushed. So now it should work on every
system with with readable /proc/sys/vm/mmap_min_addr or
/proc/sys/vm/mmap_min_addr <= 65536.

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: some possible fixes in the OE web pages

[Robert P. J. Day]

On Thu, 13 May 2010, Martin Jansa wrote:

> ... repeated stuff snipped ...
>
> You should finish reading the thread again :).

  you guys are just posting faster than i can read.  sorry.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: some possible fixes in the OE web pages

[Robert P. J. Day]

On Thu, 13 May 2010, Martin Jansa wrote:

... my initially innocuous observation snipped ...

> On some systems (I have report from fedora and kubuntu) it still
> needs 0 in mmap_min_addr :/.
>
> Investigating why, but it's slow because it doesn't fail on my box.
>
> My guess is that this chunk from
> http://git.qemu.org/qemu.git/tree/linux-user/main.c cannot work on
> systems where normal user is not allowed to read
> /proc/sys/vm/mmap_min_addr and mmap_min_addr is not initialized with
> sane value.
>
>     /*
>      * Read in mmap_min_addr kernel parameter.  This value is used
>      * When loading the ELF image to determine whether guest_base
>      * is needed.  It is also used in mmap_find_vma.
>      */
>     {
>         FILE *fp;
>
>         if ((fp = fopen("/proc/sys/vm/mmap_min_addr", "r")) != NULL) {
>             unsigned long tmp;
>             if (fscanf(fp, "%lu", &tmp) == 1) {
>                 mmap_min_addr = tmp;
>                 qemu_log("host mmap_min_addr=0x%lx\n", mmap_min_addr);
>             }
>             fclose(fp);
>         }
>     }
>

  i'm confused ... unless my memory is failing, i've always been able
to at least *read* that file as a normal user since it was
world-readable, but this baffles me:

$ ls -l /proc/sys/vm/mmap_min_addr
-rw-r--r-- 1 root root 0 2010-05-12 20:42 /proc/sys/vm/mmap_min_addr
$ cat $_
cat: /proc/sys/vm/mmap_min_addr: Operation not permitted
$

  what am i misunderstanding?  the file perms state world-readable so
i'm assuming something in the actual kernel code is checking the
caller ID and rejecting the read request?

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: some possible fixes in the OE web pages

[Robert P. J. Day]

On Thu, 13 May 2010, Robert P. J. Day wrote:

>   i'm confused ... unless my memory is failing, i've always been able
> to at least *read* that file as a normal user since it was
> world-readable, ...

  never mind, i should have kept reading email.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

Re: some possible fixes in the OE web pages

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1250 bytes --]

On Thu, 13 May 2010, Roman I Khimov wrote:

> В сообщении от Четверг 13 мая 2010 01:30:53 автор Robert P. J. Day написал:
> > * on http://wiki.openembedded.net/index.php/OEandYourDistro#Ubuntu,
> > there's a reference to configuring for qemu-arm:
> >
> >   echo 128 > /proc/sys/vm/mmap_min_addr
> >
> > from memory, i always simply set that to zero on fedora.  is there
> > something magic about the value 128?  at the moment, it's at the
> > default value of 65536 on this ubuntu system.
>
> With current qemu in OE mmap_min_addr tricks are not needed at all.

  really?  that's probably worth mentioning, then, both at the above
link at the OE wiki, and i saw a similar page over at the angstrom
wiki but can't recall where the page was.  dang.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================