Debian kernel change may break applications

News and discussion about development of the Debian OS itself

Debian kernel change may break applications

Postby shadowking » 2009-10-24 07:18

http://wiki.debian.org/mmap_min_addr

The next or latest kernel upgrade for the STABLE branch is affected. I'm not happy with this. Many people using the stable branch do so to have a stable-core OS. They should do these changes to the unstable/testing branch and for the squeeze release. Stable should only have bugfix, non-regression changes and hopefully some updated user-apps - THE BASE SYSTEM SHOULD NOT BE SCREWED WITH !

-Leave the base system alone (kernel, core libraries ABI, etc) . Do security, bugfixes, Update some common *non-system apps [desktop stuff like FF/IW, gimp etc]

Now i have to compile a kernel.org kernel like 2.6.27 again to get away from this crap. or i'm thinking a different distro, OS ??? It sucks.

Is this change in the kernel compile or just a parameter /etc/sysctl ??? .
Last edited by shadowking on 2009-10-24 07:46, edited 1 time in total.
shadowking
 
Posts: 496
Joined: 2009-05-06 11:34

Re: Debian kernel change may break applications

Postby sinical » 2009-10-24 07:42

First you say you should only have bugfix then you say level base system alone.. you can't have it both ways.

Anyway, you aren't forced to do the upgrade, pin the current kernel back if its that big a deal.
Every cloud has a silver lining, except for the mushroom shaped ones, which have a lining of Strontium 90.
---------------------------------------------
umop apisdn
User avatar
sinical
 
Posts: 1022
Joined: 2007-03-25 11:52

Re: Debian kernel change may break applications

Postby shadowking » 2009-10-24 07:52

Yes non-invasive bugfixes. If it breaks applications like Wine 16-bit there is no way it should be applied to the stable branch and BTW i gather this is a distro change and not upstream default?. I run a custom debian 2.6.26 and i only recompile for serious security issue - I don't want to know anything else otherwise why not run a rolling release ? what's the point of stable ?
shadowking
 
Posts: 496
Joined: 2009-05-06 11:34

Re: Debian kernel change may break applications

Postby bugsbunny » 2009-10-24 07:59

If you actually read the page you see that it has nothing to do with a new kernel and is simply a sysctl setting, which you can easily change. For most people the new setting appears as if it will work just fine, giving an increased level of security (which is why the change is being implemented). The applications that they mention that they know are effected:
dosemu

dosemu must run with vm.mmap_min_addr set to 0, or be executed as root. The maintainers are investigating ways of dealing with this issue in packaging, see: 505247
wine

Only Win16 binaries require the ability to mmap low addresses, Win32 binaries do not. It is recommended that you test your application with the increase mmap_min_addr setting. If the application starts up without issue, then you should not need to remove the mmap_min_addr restriction.
qemu

qemu, as shipped in Debian 5.0, requires low virtual memory mmaps. mmap_min_addr must be set to 0 to run qemu as a non-root user. This limitation has been removed upstream, so qemu should work with an increase mmap_min_addr starting with Debian squeeze.


They specifically tell you in the article how to revert if necessary
User avatar
bugsbunny
 
Posts: 5355
Joined: 2008-07-06 17:04

Re: Debian kernel change may break applications

Postby bugsbunny » 2009-10-24 08:00

And how many wine 16 bit apps are out there? Not many (relatively speaking). They're almost all 32 bit.
User avatar
bugsbunny
 
Posts: 5355
Joined: 2008-07-06 17:04

Re: Debian kernel change may break applications

Postby shadowking » 2009-10-24 08:07

bugsbunny wrote:And how many wine 16 bit apps are out there? Not many (relatively speaking). They're almost all 32 bit.



That's not the point. It is unacceptable in principle.
shadowking
 
Posts: 496
Joined: 2009-05-06 11:34

Re: Debian kernel change may break applications

Postby bugsbunny » 2009-10-24 08:08

If you really need 16 bit apps in wine then create a file /etc/sysctl.d/wine.sysctl.conf that contains the following
Code: Select all
# Wine needs to access the bottom 64k of memory in order to launch
# 16 bit programs.
vm.mmap_min_addr = 0

Problem solved.
User avatar
bugsbunny
 
Posts: 5355
Joined: 2008-07-06 17:04

Re: Debian kernel change may break applications

Postby shadowking » 2009-10-24 08:14

Yes. Well half-solved. The proper way to do it is:

1 - Debian should refrain from this tweak.
2 - A fallback should be provided - not in instruction but as an extra .conf file that maintains backwards compatibility like you posted. Then the user can decide to discard the fallback layer.
shadowking
 
Posts: 496
Joined: 2009-05-06 11:34

Re: Debian kernel change may break applications

Postby bugsbunny » 2009-10-24 08:26

shadowking wrote:Yes. Well half-solved. The proper way to do it is:

1 - Debian should refrain from this tweak.
2 - A fallback should be provided - not in instruction but as an extra .conf file that maintains backwards compatibility like you posted. Then the user can decide to discard the fallback layer.


It's a security enhancement that deals with a legitimate security concern. And you don't know how they'll deal with it during the actual upgrade. My guess is that they'll include a news item that will pop up and tel the user what's going on.

They most definitely should include this "tweak" - security trumps, especially in a situation that has minimal impact upon the majority of the user base. And it should be on by default. Perhaps the dosemu package should include a file to override this, since it's definitely affected. Same with qemu in lenny. Wine I'd leave as is. But as a default? Turn it on.
User avatar
bugsbunny
 
Posts: 5355
Joined: 2008-07-06 17:04


Re: Debian kernel change may break applications

Postby shadowking » 2009-10-24 08:39

So many security holes in the kernel - like every few weeks. For a server would OpenBSD/FreeBSD be a better option ?

Looks better to me:

http://www.freebsd.org/security/advisories.html
http://www.openbsd.org/security.html
shadowking
 
Posts: 496
Joined: 2009-05-06 11:34

Re: Debian kernel change may break applications

Postby Tadeas » 2009-10-24 14:02

shadowking wrote:So many security holes in the kernel - like every few weeks. For a server would OpenBSD/FreeBSD be a better option ?

Looks better to me:

http://www.freebsd.org/security/advisories.html
http://www.openbsd.org/security.html

So use OpenBSD/FreeBSD if it's better for your purposes. What's the problem?
Or use Windows, or some different distro if you don't like Debian policies.
Because let’s face it, the unfortunate aspect of software development is that it involves humans. Mewling, disorganized, miserably analog humans. Sometimes they smell bad.
User avatar
Tadeas
 
Posts: 1017
Joined: 2008-09-22 09:11
Location: Prague

Re: Debian kernel change may break applications

Postby Tixy » 2009-10-24 16:07

shadowking wrote:So many security holes in the kernel - like every few weeks. For a server would OpenBSD/FreeBSD be a better option ?

A future option you probably already know about: Debian are adding the FreeBSD kernel in Squeeze.
Tixy
 
Posts: 96
Joined: 2009-08-12 17:00

Re: Debian kernel change may break applications

Postby Jackiebrown » 2009-10-25 05:47

shadowking wrote:Yes. Well half-solved. The proper way to do it is:

1 - Debian should refrain from this tweak.
2 - A fallback should be provided - not in instruction but as an extra .conf file that maintains backwards compatibility like you posted. Then the user can decide to discard the fallback layer.

I disagree with 1 but adding a debconf question would be nice.

In any case, if the file is in /etc you won't you be prompted that the maintainer conf is different then the local one?
User avatar
Jackiebrown
 
Posts: 1276
Joined: 2007-01-02 04:46
Location: San Antonio, TX

Re: Debian kernel change may break applications

Postby bugsbunny » 2009-10-25 11:16

Jackiebrown wrote:
shadowking wrote:Yes. Well half-solved. The proper way to do it is:

1 - Debian should refrain from this tweak.
2 - A fallback should be provided - not in instruction but as an extra .conf file that maintains backwards compatibility like you posted. Then the user can decide to discard the fallback layer.

I disagree with 1 but adding a debconf question would be nice.

In any case, if the file is in /etc you won't you be prompted that the maintainer conf is different then the local one?


In this case I don't think so, since I think (I'd have to double-check) that the default can be specified in the config used for kernel compilation. Which actually leads to another point - if you're self-compiling kernels then this change doesn't effect you in any case, since you can set this to whatever. Now I have to check :)
Processor type and features
() Low address space to protect from user allocation
User avatar
bugsbunny
 
Posts: 5355
Joined: 2008-07-06 17:04

Next

Return to Debian Development

Who is online

Users browsing this forum: No registered users and 2 guests

fashionable