Wine needs to disable the mmap_min_addr setting silently and automatically

[Steve Langasek]

On Fri, Jul 11, 2008 at 02:27:06PM -0700, Scott Ritchie wrote:
> A change to the kernel in Hardy has completely broken Wine's support for
> 16 bit applications (as well as DOS ones).

> Right now, users have to manually modify /etc/sysctl.conf and change
> vm.mmap_min_addr = 65536  to vm.mmap_min_addr = 0.  Otherwise, some of
> their programs refuse to launch and others may start crashing.  This is
> obviously unworkable, so I've been thinking of various fixes.

For intrepid and beyond, the procps package supports loading sysctl settings
not only from /etc/sysctl.conf, but also from /etc/sysctl.d.  So the obvious
solution is for each of dosemu and wine to ship a file of their own under
/etc/sysctl.d/ that disables this setting.  (Though I would question how
appropriate it is these days to enable that by default for wine, if only
16-bit programs need it.)

Ideally you would also re-process the sysctl settings on package install,
probably by calling "invoke-rc.d procps start".

> The ideal fix would allow access to that memory only to Wine and similar
> apps that are affected (eg dosemu and qemu), however I'm not sure if
> there's a way to configure this application-specifically.

In talking with Kees Cook about this, it sounds like the reason this setting
exists at all is to close an attack vector that could be used to exploit
kernel bugs.  So letting unprivileged processes change this setting is not
really an option.

What would be a better long-term solution, so that users who have wine
installed don't automatically lose out on the security, is if when running
16-bit code, wine would map address zero to somewhere else and could then
install a signal handler for SIGSEGV to fix up the addresses.

> In the mean time perhaps it would be best if we created a new package,
> named something like "early-memory-access", that contained little more
> than a script to modify this entry for the user on install/removal.
> Wine could then depend on that package, and users would thus only
> install it if Wine were installed.

I don't see any reason to make this a separate package unless wine would
*not* depend on it.  If it's going to be part of every wine install, it
should just be done in the wine package itself.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org