Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Debian kernel change may break applications
-
- Posts: 496
- Joined: 2009-05-06 11:34
Debian kernel change may break applications
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 ??? .
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.
Re: Debian kernel change may break applications
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.
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
---------------------------------------------
umop apisdn
-
- Posts: 496
- Joined: 2009-05-06 11:34
Re: Debian kernel change may break applications
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 ?
Re: Debian kernel change may break applications
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:
They specifically tell you in the article how to revert if necessarydosemu
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.
Re: Debian kernel change may break applications
And how many wine 16 bit apps are out there? Not many (relatively speaking). They're almost all 32 bit.
-
- Posts: 496
- Joined: 2009-05-06 11:34
Re: Debian kernel change may break applications
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.
Re: Debian kernel change may break applications
If you really need 16 bit apps in wine then create a file /etc/sysctl.d/wine.sysctl.conf that contains the following
Problem solved.
Code: Select all
# Wine needs to access the bottom 64k of memory in order to launch
# 16 bit programs.
vm.mmap_min_addr = 0
-
- Posts: 496
- Joined: 2009-05-06 11:34
Re: Debian kernel change may break applications
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.
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.
Re: Debian kernel change may break applications
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.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.
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.
-
- Posts: 496
- Joined: 2009-05-06 11:34
Re: Debian kernel change may break applications
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
Looks better to me:
http://www.freebsd.org/security/advisories.html
http://www.openbsd.org/security.html
Re: Debian kernel change may break applications
So use OpenBSD/FreeBSD if it's better for your purposes. What's the problem?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
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.
Re: Debian kernel change may break applications
A future option you probably already know about: Debian are adding the FreeBSD kernel in Squeeze.shadowking wrote:So many security holes in the kernel - like every few weeks. For a server would OpenBSD/FreeBSD be a better option ?
- Jackiebrown
- Posts: 1246
- Joined: 2007-01-02 04:46
- Location: San Antonio, TX
Re: Debian kernel change may break applications
I disagree with 1 but adding a debconf question would be nice.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.
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?
Re: Debian kernel change may break applications
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 checkJackiebrown wrote:I disagree with 1 but adding a debconf question would be nice.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.
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?
Processor type and features
() Low address space to protect from user allocation
- Jackiebrown
- Posts: 1246
- Joined: 2007-01-02 04:46
- Location: San Antonio, TX
Re: Debian kernel change may break applications
You're right.
It is adding the "fix" that would force the prompt that the maintainers config is different than the local one since the fix is what would change the config file.
It is adding the "fix" that would force the prompt that the maintainers config is different than the local one since the fix is what would change the config file.
Re: Debian kernel change may break applications
Even that isn't necessarily true. If they add a new file to /etc/sysctl.d/ then they're not changing the original file at all. This would also have the advantage that upon package removal they can easily purge that file, again without impacting the original.Jackiebrown wrote:You're right.
It is adding the "fix" that would force the prompt that the maintainers config is different than the local one since the fix is what would change the config file.
- Jackiebrown
- Posts: 1246
- Joined: 2007-01-02 04:46
- Location: San Antonio, TX
Re: Debian kernel change may break applications
Good point - I was thinking of /etc/sysctl.conf
Never really look at that (currently) empty folder and forgot it was there.
Never really look at that (currently) empty folder and forgot it was there.
Re: Debian kernel change may break applications
For the dosemu situation from #505247 - dosemu low memory sysctl - Debian Bug report logs
Based on comments inside dosemu.conf vm86 is actually the default if you're running a 64 bit system.Subject: dosemu low memory sysctl
Date: Sat, 24 Oct 2009 20:17:44 +0200
Hi
dosemu has been patched to to address the vm.mmap_min_addr = 0 issue
(implemented before the actual svn revision 1988). I know of no
application, that does not run. For this patch to work, the vm86 mode of
the processor has to be simulated, which is an performance issue. To use
simulated mode for vm86, you have to set $_cpu_emu = vm86 in
dosemu.conf. You get a warning for using an experimental feature.
Reinhard
# Usage of cpu emulation: "off" (default on x86),
# "vm86" only (default on x86-64) or "full" (vm86 and DPMI, experimental!).
# Use "vm86sim" or "fullsim" to use simulation instead of JIT code generation.
# $_cpu_emu = "off"
Re: Debian kernel change may break applications
There are loads of win16 apps out there and many of them work just fine under wine.bugsbunny wrote:And how many wine 16 bit apps are out there? Not many (relatively speaking). They're almost all 32 bit.