Solved mmap full access to the first megabyte for DOS mode

Hello,

Is it possible to grant full access to the first megabyte of memory for DOS mode? I'm looking for the FreeBSD equivalent of what is

# sysctl -w vm.mmap_min_addr="0"

in Linux.

For context, I'm trying to run an old Windows program in Wine. It gives me the following error message:
Error:
0120:err:dosmem:DOSMEM_MapDosLayout Need full access to the first megabyte for DOS mode

Also, what are the security implications of this move? Could a runaway program in Wine damage the FreeBSD kernel?

(Sorry for that idiotic smiley in the error message. These user-unfriendly interfaces that always think they know better what you wanted to type are decidedly annoying :( )
 
Last edited:
While I don't use wine I don't think you can do this. I vaguely remember doscmd(1) being obsoleted in FreeBSD 7 or 8, one of the reasons being this NULL page.
There's no such sysctl on FreeBSD. You can squeeze that limit down to 0x1000 by disabling vm.pmap.pg_ps_enabled but still you won't be able to allow the first page to be allocated. At least not by sysctl (you could modify the source code though to allow it).

Yes, allowing to allocate a page at 0 (which is implied by that "first megabyte for DOS mode" message) has big security implications.
 
I was looking at the source code checking out why there is actually a lower limit set to 0x1000. If somebody is interested it's because of this.
That map_at_zero is very interesting variable as it is sysctl variable and it's the one that actually does allow you to map page 0. I frankly didn't know about this.

So to answer your question you can do:
Code:
sysctl security.bsd.map_at_zero=1
And try to use wine again. You can always disable it once you finish your wine program.
 
_martin: thanks, I could now try this on a throwaway system and confirm that sysctl security.bsd.map_at_zero=1 indeed solves the problem as you said. Wine now crashes with another error message (Data segment exceeds process limit; will ask this in another thread).

kpedersen: The program is Chessmaster 5000 from 1996. It was written for Windows 95.
 
Last edited by a moderator:
forget wine and run win95 in a good DOS emulator. DOSbox has never steered me wrong. I still run generic cadd in it frequently.

This of course assumes that you can run win95 under a DOS emulator. I've never tried.

Quick web search yields a known problem. win95 detects that dos emulator is already running under protected mode, so it wont' start completely.

So...In my best Gilda Radner voice "Never mind".
 
Data segment exceeds process limit;
This error is most likely coming from FreeBSD itself, not wine. I don't know what is wine doing here and why would you hit this limit on this old program (that would require me to debug it) but for the sake of argument you could set the system wide tuneable kern.maxdsiz to max by sysctl kern.maxdsiz=-1 or, and this is maybe better, try to double the current size first, check it, double again, and so on. We are talking about desktop system where reboot is no issue.

It's worth a thought whether running Windows 95 under qemu or VirtualBox is not a better idea. Strictly legally speaking though you would need to have valid W95 license (it's still not free in 2023).
 
Strictly technically speaking I'd avoid Windows 95, or anything from Microsoft, like the plague. I was just hoping that by 2023 Wine had advanced to the point that it could run 25-year-old software without problems. Guess I was wrong...

My current data seg size is 33,554,432 kilobytes. Considering that's 4 times the RAM in my system, it should be enough ;)
 
I think last time I used wine was at uni when I was running Mafia on FreeBSD. And I think it was even crossover..something, don't remember, it was 18 years ago or so.

Note that wine could be lowering this limit by setting setrlimit() on itself. Maybe it has some tunable for this.
You could experiment and lower the limit by ulimit -d to something more suitable for that era.

As it requires page0 I'm confident enough to say it will be doing VM86 call at some point. That error you see then could be misleading.
 
Back
Top