MS-DOS compatible OS running processes in VMs

[orbitaldecay]

Greetings OSDevers!

So, I am a total DOS geek and the phasing out of BIOS totally breaks my heart. Decades of beautifully crafted x86 code will be rendered completely unusable (outside of DOSBox / VirtualBox) on new machines in the very near future. I recently had an (good / bad?) idea and I thought I would end my multi-year lurking streak to share it. A 64 bit DOS clone which runs each process from within a virtual machine using hardware virtualization features. "But, why?" you ask? I think it could satisfy three goals:

1. FreeDOS is great. But once motherboard manufacturers drop BIOS in favor of UEFI, FreeDOS won't work. It would be nice if there were an OS which was binary compatible with MS-DOS that would run on todays x86-64 machines and (hopefully) the machines which will come out for the next couple decades.

2. IMHO, the biggest problem with real mode DOS is process isolation. Using hardware virtualization would make it possible to run unmodified DOS binaries while retaining control over memory, hardware, and filesystem access.

3. Maintaining binary compatibility with traditional (MS-)DOSes would make a wide variety of tools available.

Yes, I know that like most (even modest) OS projects, this would be a lot of work. Emulating BIOS + MS-DOS API is a pretty lofty goal, but one that has been achieved previously with reasonable success by other teams (so lots of existing GPLed code to look at ).

Does anyone know if there is already a project with similar aims that I could assist with? Maybe there is some other way to achieve these goals that I'm not aware of? Maybe there is some fatal flaw in my plan that would render it impossible or extremely difficult to do? I would really appreciate any and all feedback ranging from "That's stupid" to "Great idea!".

I have started researching the technicalities of implementing this idea and it seems feasible so far to me, but I won't go into details (unless you're interested) lest this post become pages long.

Thanks for reading!

[Octocontrabass]

Maybe there is some other way to achieve these goals that I'm not aware of?

It doesn't sound like the sort of thing that needs an entire OS. Why not just run FreeDOS in a VM?

[orbitaldecay]

Hello,

Maybe there is some other way to achieve these goals that I'm not aware of?

It doesn't sound like the sort of thing that needs an entire OS. Why not just run FreeDOS in a VM?

Thanks for your response!

Obviously, part of the reason I want to write an entire OS is simply, "because I like writing OS code". But from a more practical standpoint, I agree with you up to goal #2.

Say you have an untrusted DOS executable that you've downloaded from the internet and you would like to ensure that it doesn't infect other executables on your DOS partition with a virus. If I were running FreeDOS within a VM, I could ensure that the untrusted executable couldn't modify anything outside of my VM, but it could certainly infect my FreeDOS installation with a virus.

Alternately, any code that's exposed to a network interface should really always be running in an isolated process space for obvious security reasons (not that a lot of people are browsing the internet under DOS these days ).

I'm sure you can think of other reasons why this feature might be nice from a security standpoint.

[Octocontrabass]

Say you have an untrusted DOS executable that you've downloaded from the internet and you would like to ensure that it doesn't infect other executables on your DOS partition with a virus. If I were running FreeDOS within a VM, I could ensure that the untrusted executable couldn't modify anything outside of my VM, but it could certainly infect my FreeDOS installation with a virus.

You could create a snapshot of an empty DOS VM, and create a new VM from that snapshot for each program. Having some way to do that automatically would make it more practical.

This doesn't solve the problem if the virus can spread through files that you'd want to move between VMs.

Alternately, any code that's exposed to a network interface should really always be running in an isolated process space for obvious security reasons (not that a lot of people are browsing the internet under DOS these days ).

You could probably skip network support and most people wouldn't notice that it's missing.

[Brendan]

So, I am a total DOS geek and the phasing out of BIOS totally breaks my heart. Decades of beautifully crafted x86 code will be rendered completely unusable (outside of DOSBox / VirtualBox) on new machines in the very near future. I recently had an (good / bad?) idea and I thought I would end my multi-year lurking streak to share it. A 64 bit DOS clone which runs each process from within a virtual machine using hardware virtualization features. "But, why?" you ask? I think it could satisfy three goals:

Why stop there? You could optimise the "virtual devices" to use a leaner interface (e.g. virtio), and improve performance while also avoiding a lot of "hardware compatibility" problems in the guests.

But, why stop there? You could use a leaner interface for all virtual devices, which would allow you to switch to para-virtualisation. Then, because the guests are "DOS like" (single-tasking, single-virtual address space), you can avoid the ugly mess that is hardware virtualisation (and the compatibility problems caused by AMD and Intel doing it differently, each with multiple additional features) by using "CPL=3 with different virtual address space" for each virtual machine, and improve performance even more.

But why stop there? For multiple virtual machines, sharing resources between them (everything from files to RAM to clipboard contents) is a pain in the neck, and you end up with things like "guest additions" to make it less bad; but you can optimise all of that to make it much more efficient (possibly even good) just by changing the way things are para-virtualised a little.

But why stop there? Now that you've improved everything in multiple ways; there's one last issue - the terminology used to describe it is a little unfamiliar. This is easily fixed by changing the descriptions of things (without changing a single line of code and without changing how anything actually works). For an example; rather than saying "a virtual machine has a virtual address space and one or more virtual CPUs" you could say "a process has a virtual address space and one or more threads".


Cheers,

Brendan

[rdos]

I no longer find supporting DOS worthwhile. Still, I have most of the code for emulating important parts of the BIOS and DOS, and it doesn't need to run in an emulator. I always run it in V86-mode, something that works even if your ordinary OS runs in long mode. The feature you need is the ability to switch between long mode and protected mode (V86 for DOS). That feature only requires multimodal interrupt handlers.

However, when I did this, I found it necessary to emulate access to the DOS and BIOS area, which had to be done through emulation. You also need to emulate IO ports to support direct hardware access. Thus, even if you run DOS in V86 mode, you still need a full-blown emulator for x86.

[Octocontrabass]

Why stop there?

Because some DOS software (e.g. Windows) will try to directly access the hardware, and it won't support the virtio device.

[orbitaldecay]

Why stop there?

Thanks for your thoughts. Unless I am misunderstanding you, I don't think you're taking into account my desire to remain binary compatible with MS-DOS, as Octocontrabass points out. The point of writing it would be to allow users to run existing DOS programs. I agree that it is not efficient, but I do not see how the path you are describing could be used while maintaining binary compatibility. Perhaps I am missing something?

I no longer find supporting DOS worthwhile. Still, I have most of the code for emulating important parts of the BIOS and DOS, and it doesn't need to run in an emulator. I always run it in V86-mode, something that works even if your ordinary OS runs in long mode. The feature you need is the ability to switch between long mode and protected mode (V86 for DOS). That feature only requires multimodal interrupt handlers.

However, when I did this, I found it necessary to emulate access to the DOS and BIOS area, which had to be done through emulation. You also need to emulate IO ports to support direct hardware access. Thus, even if you run DOS in V86 mode, you still need a full-blown emulator for x86.

Interesting. I had only put passing thought into dropping back into protected mode and running processes in V86 mode. Thank you for raising this idea. I should give it more serious thought.

[orbitaldecay]

You could create a snapshot of an empty DOS VM, and create a new VM from that snapshot for each program. Having some way to do that automatically would make it more practical.

This doesn't solve the problem if the virus can spread through files that you'd want to move between VMs.

Yeah, there are ways to use VirtualBox + FreeDOS to achieve similar functionality, but as you point out I think it'd be slightly inconvenient.

The term VM is a little misleading here, as in my thinking so far the VM would only exist for the life of the process and would only run a single process. But, your point stands. If a process has write access to some other binary file it could indeed spread a virus. My thought was to support file ownership and permissions via ext or something similar. A totally untrusted program could just be run with a user that doesn't have access to any files, or has read-only access to certain necessary files (something akin to sudo -u would be useful here). I'm definitely open to other ideas concerning file access rights, but this seems to be the most trodden path. Maybe even something like sudo that can be passed a flag that denies the process access to the filesystem at all. There are probably a lot of interesting ways to approach this problem.

You could probably skip network support and most people wouldn't notice that it's missing.

No argument there, though it'd be nice to at least consider it as a long term possibility

[Octocontrabass]

The term VM is a little misleading here, as in my thinking so far the VM would only exist for the life of the process and would only run a single process.

Sort of like a cross between QEMU and DOSBox? That still doesn't need an entire OS, though it would need OS support for hardware virtualization.

My thought was to support file ownership and permissions via ext or something similar. A totally untrusted program could just be run with a user that doesn't have access to any files, or has read-only access to certain necessary files (something akin to sudo -u would be useful here).

If your VM is an application running in Linux, you can use "sudo -u". :p

[orbitaldecay]

Sort of like a cross between QEMU and DOSBox? That still doesn't need an entire OS, though it would need OS support for hardware virtualization.

Yeah, I think we're on the same page. I must concede that you make a good point. It would be possible (and easier) to implement the idea as a KVM. To be fair, I think something similar could be said about most kernels (especially hobby kernels). Isn't it usually possible to:

1. Write an emulator inside of an existing OS to run the binaries for your new OS, rendering the creation of your new OS unnecessary? Or
2. Modify an existing OS to include your useful new feature or API?

The only exception I can think of to these possibilities is if you believe the fundamental design of your kernel will be better than all existing kernels. I can't begin to believe that I am that clever Best of luck to anyone who is!

If your VM is an application running in Linux, you can use "sudo -u". :p

Touche