Wine needs to disable the mmap_min_addr setting silently and automatically

Stéphane Graber stgraber at
Tue Jul 15 17:32:16 BST 2008

Hash: SHA1

Steve Langasek wrote:
> 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,

As I understood it the idea was to have it a recommend for wine so
people not running 16-bit softwares in wine could just remove that
package and restore the sysctl settings while keeping wine installed.

Version: GnuPG v1.4.6 (GNU/Linux)


More information about the ubuntu-devel mailing list