Explore possibility to create ReactOS-based template for Qubes

[rootkovska]

Inspired by this thread: https://twitter.com/reactos/status/863673534710788096

Idea is to distribute ReactOS-based template for Windows AppVMs for Qubes. Specifically a template optimized to run specific MS Windows applications, such as MS Office.

In Qubes 4.1 or 4.2, i.e. when we will have GUI domain, we could even consider using RactOS as an alternate GUI domain, to provide some users with familiar Windows look and feel.

Potential benefits:

1. Seamless integration for Windows-based AppVMs done right. We have faced lots of troubles when implementing proper seamless mode for MS Windows-based AppVMs. On Linux-based (X-based) AppVMs, we can easily get addresses of all the windows composition buffers and send their PFNs to our GUI daemon, which provides a very nice, native look and feel. However this task seems undoable on MS Windows because of undocumented win32k internals. AFAIK no body else, i.e. no other VMM vendor, has implemented proper seamless mode for Windows VMs. Most (all?) attempts revolve around cutting rectangles from one framebuffer, which has many disadvantages: 1) non-zerocopy, so slower, 2) visible artifacts when one moves overlapping windows, 3) occasional difficulty in determining windows structuring.

2. ReactOS is GPL and BSD licensed according to the project wiki [1]. This is a great benefit in itself in a few ares: transparency (think: backdoors), easy of tinkering (think: better integration with Qubes), ability to distribute freely, no need for users to worry about licenses (yet still would need to have licenses e.g. for MS Office).

[1] http://www.reactos.org/wiki/ReactOS

3. Possibility to create much lighter (i.e. with smaller memory footprint) Windows AppVM, likely due to ability to customize (disable) unneeded stuff.

Steps to proceed:

• determine if there is joint interest between ReactOS devs and Qubes
• determine resources needed (developer-months), discuss funding possibilities
• sketch roadmap
• apply for funding

Likely stages of creating ReactOS-based template:

• Run in Qubes HVM (should just work)
• Try porting qrexec and all Qubes Tools, except for the GUI agent, run in full desktop mode
• Ensure works well as Qubes template (i.e. root/system filesystem separated from "home dir")
• Write GUI agent

Many of these tasks could likely be directly copied from our MS Windows Qubes Tools:
https://github.com/QubesOS/qubes-core-agent-windows
https://github.com/QubesOS/qubes-windows-utils
https://github.com/QubesOS/qubes-vmm-xen-windows-pvdrivers
https://github.com/QubesOS/qubes-builder-windows
https://github.com/QubesOS/qubes-gui-agent-windows (with not-so-great seamless mode)

[erkinalp]

ReactOS corresponding issue https://jira.reactos.org/browse/CORE-13358

[Jeeppler]

I created a ReactOS HVM in QubesOS. The VM worked out of the box. I tested several applications and functionalities to evaluate potential use cases. Software developed for Windows XP and before works. However, there is no guarantee that software will work. The QubesOS community should work with the ReactOS community to evaluate which use cases and scenarios would be important to support. Skype, Adobe Reader and MS Office support are some of the use cases I had in mind, but maybe there are more. It would be helpful to create a simple survey on the mailing list or something like that to figure out what the community wants.

One issue which I run into was that I had to use the VirtualBox image and convert the .vhd file into a raw .img file to use ReactOS, because the live and iso edition did not work and the QEMU version is not an image file. The problem with the VirtualBox image is the size. After converting the .vhd file to a raw .vhd file the image was 20 GB in size. I assume the .vhd file uses a dynamically allocated VirtualBox harddrive type. The first thing I would like to see is an image for Qubes OS. This is something where the ReactOS and QubesOS community could immediately work together.

Tested:

• Internet connection: works out of the box

• Sound: does not work

• Playing videos youtube: works well in firefox

• USB Pass-through: does now work

• Window resizing in ReactOS works

• Microphones cannot be attached

• Games:

  • Pingus (works)
  • Age of Empires Demo (works)
  • Anno 1602 Demo (works)
  • Stronghold Demo (works well)
  • Cossacks European Wars (mouse does not work)
  • Empire Earth Demo (memory error)
  • Soldier of Fortune 2 (error needs OpenGL)
  • Praetorians (does not work)

• PDF reader:

  • Adobe Reader 11 (Connection fails)
  • Adobe Reader 9 does not work (rendering issues)

• Haxe Development: FlashDevelop

  • Requires at least .Net 3.5
    • Can be downloaded (XP version)
    • Installation of .Net 3.5 fails

• VoIP:

  • Skype: Has problems while installing and running (Skype 7.3.6)

• Reverse Engineering:

  • IDA 5.0 Freeware (works)

• Password Safe:

  • Keepass 2.3 (error during installation)
  • Keepass 1.3 (works)

• 512 MB RAM are enough to run ReactOS smooth

• Startup and shutdown are fast

Note: The author's computer does not have Intel VT-d

Feel free to look at my notes if you want to reproduce my setup or you want to have more information.

[Jeeppler]

I posted in the ReactOS forum to promote the idea of QubesOS + ReactOS a little in the ReactOS community: https://www.reactos.org/forum/viewtopic.php?f=2&t=16480

[rootkovska]

Thanks! Just a few comments:

1. Sound is not expected to work for any HVM at this moment, because... we don't have an audio agent for stubdoms yet. This also applies to mics, of course.

2. Similarly, qvm-usb is also not expected to work for HVMs generally. We're currently in the process of implementing qvm-usb support for Windows-based AppVMs, using USBIP drivers, similarly as we did for Linux AppVMs. Note these tools are to be installed within the Windows VMs (not in the stubdom) and are currently being developed for MS Windows, and likely will need some (hopefully minor) porting to run on ReactOS.

[rootkovska]

Also, some apps I personally consider useful (and which have essentially no Linux alternatives, so one is destined to use Windows to get their functionality):

1. iTunes -- very useful for offline syncing and provisioning iPhones and other iOS devices.

2. Skydemon (for VFR pilots): http://www.skydemon.aero/start/

[v6ak]

- USB Pass-through: does now work (author's computer don't have Intel VT-d)

Do you mean USB passthrough, or PCI passthrough of USB controller? USB passthrough would be surprising to work without any further modification of guest OS and it is unrelated to VT-d. PCI passthrough should theoretically work to the same degree as the USB controller works with ReactOS on bare metal.

[v6ak]

I've tried ReactOS in HVM. Installation was pretty fast, oldschool and without serious issues. It also boots very quickly. The usage itself was like… Well, what's ReactOS advantage over Wine? First, I have tried to install Firefox. The repository contains pretty outdated versions (I haven't checked if there is any verification of signatures, just tried it and believed everything will be OK). OK, let's install some old version, Firefox updater will make it up-to-date. Yes, updater works pretty automatically, but updated Firefox doesn't. So, I can browse the Internet just with some browser without recent security updates. I've tried installing DeeControl, and I got probably slightly further than with Wine. But a short while later, I got a BSOD. Never mind, let's try it again. ReactOS hasn't written some changes (DeeControl wasn't even downloaded), but let's try it again. The result is, sadly, the same. I also had various minor issues, most prominently desynced mouse cursors. (Workaround: hit the edges of virtual screen, cursors get synces.) I also had some graphic artifacts and one boot-time freeze. Well, I see there must have been huge amount of work done, but frankly, I don't see much practical benefits. Wine is subjectively more stable and Qubes integration is for free. ReactOS in QubesOS might have some niche (maybe for applications that need USB and few other apps), but my experience hasn't been much encouraging. When needing some Windows app, I'd probably try Wine before ReactOS, even if ReactOS integration to Qubes was already done.

[rootkovska]

FWIW, last time I tried Wine (IIRC in Debian 8 AppVM) I was disappointed by the very slow GUI. Admittedly I tested this on a GUI intensive software (the previously mentioned SkyDemon), but the very same software ran much faster on native Windows 7-based AppVM.

[marmarek]

Have you tried this on Fedora? Debian 8 have _very_ old version...

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[rootkovska]

IIRC, there was a specific reason I decided to try on Debian, but I don't remember now what that was... I should try this at some point on Fedora, maybe on 25th this time ;)

[Jeeppler]

@v6ak what is DeeControl? Could you provide a link to the software.

[Jeeppler]

@v6ak What method/medium did you use to install ReactOS?

[Jeeppler]

For me the top reasons to support ReactOS are:

1. No license issues
2. Running old applications from the Windows XP era and before
   • Specific application which only or still run on Windows XP and before
   • Games
   • Device software (Printer/Scanner)
   • Development tools made for XP
3. Education
   • Learning about Windows internals

[AS383]

You can find more information about tested APPs on current ReactOS release: https://www.reactos.org/wiki/Tests_for_0.4.5
About Wine. There are some ugly hacks. For example Wine creates some registry keys "on the fly" if they doesn't exist. This hacks can introduce some regressions in future. It is the reason why ReactOS developers clear Wine code before importing it into trunk. The pay is making some applications unsuported.

[Jeeppler]

Here are more testing results:

• iTunes 12.1.3.6 32-bit (works until "registering modules" phase in the installation)
  • I assume registry key issues
• Skydemon 3.8.1 (installer: works, application can not be started)
  • Requires .NET Framework 2.0 -> can be found in ReactOS Application repo

Games:

• Robin Hood - The Legend of Sherwood Demo (installation: works, game hangs at start screen)
• Wild Life Park Demo (installer does not work -> does not recognize language)
• GTA 2 Demo (installer errors, fails afterwards)
• Stronghold Crusader Multiplayer Demo (works well)
• Age of Empires II: Age of Kings Demo (installation: no sound card warning, game works)
• Battlefield 1942 Multiplayer Demo (installer hangs)

[Jeeppler]

In addition I tested the Xen PV Driver:

https://www.xenproject.org/developers/teams/windows-pv-drivers.html

• all driver installed without showing any visible error
• can't load drivers xenbus.sys and xenfilt.sys -> system start

However, I don't know how to test if the device driver are working.

[v6ak]

@Jeeppler I've installed ReactOS from BootCD. I've missed Advanced downloads at https://www.reactos.org/download . Well, now I read it did not work for you.

DeeControl is controlling software for be3D 3D printers: https://www.ysoft.com/cs/support-and-download

[v6ak]

BTW, the qemu download also contains an image (ReactOS.vmdk). I've converted both VirtualBox and QEMU images and it does not look like there are much differences. The VHD is larger, has more users, additional Internel Explorer and some probably rather formal differences (different time in log files etc.). Maybe in ReactOS/system32/config, there can be some important difference, but a brief look via vbindiff does not suggest any real difference.

Screenshot of directory diff (with excluded differences in Documents and Settings):

So, there might be no reason to try the QEMU image.

[blackcrack]

Hi Joanna :)
(sorry for my bad english)
i have read what you have wrote on the top, you have the Factory Microsoft in the hand if you think about WinNT, but it is wrong *imho* we have now a WinNT, so an Windows Network OS as better to say a its a Surface Programmed, Gui Related Ordering System and belongs not only the Factory Microsoft(with their Facility's in the background *g*) so it is possible to have an WinNT with
WindowsApi in a Community also, like the Linux Communitys, so have maybe canonical ubuntu as a debian related Distribution, but exist other Community's also like OpenMandriva.org (with clang) and other Community's of a Distributions be also Linux (by side the "linux" it is the kernel with other tools as Distribution) , so it is this Reactos an WinNT Community where work together with the community of Wine where programming Windows Api's and this be what also used in Reactos.org as Community work together.. (only to bring out of your Brain the word "MS" , because all what do you association together with Microsoft it is also a advertising for the Factory in Redmond and we want not support this factory, isn't it ? :) *g* we want give the peoples something better .. and more honest and less commerce ..)

edit: and by the way you can download daily Builds, => head page, right-sided, more down, clicking on "Daily Builds" => "Download here!" this link it is for you interesting, because they are the daily Builds iso into 7Zip's (you can also write into the Revision textbox "75000 - 75070" with this become you all iso's from 75000 up to 75070 to see..

best regards
Blacky

[marmarek]

Cross referencing: https://jira.reactos.org/browse/CORE-13358

[ColinFinck]

I'm Colin, developer at the ReactOS Project, and I have discussed a possible ReactOS and Qubes collaboration with @marmarek and @woju at FOSDEM in February. I was told that a basic ReactOS AppVM in Qubes only needs standard drivers and they wanted to try out such an installation as the first step. Don't know about its outcome though, so maybe you could comment here.

Apart from that, possible ideas for a collaboration include:

• Running Qubes drivers and tools on ReactOS, possibly porting them to NT 5.2 (what ReactOS is currently targeting at the kernel level) and fixing related bugs in ReactOS
• Improving ReactOS application compatibility towards specific applications (like MS Office)

These tasks should be of mutual interest to both projects.
Independent of Qubes, ReactOS developer @ThFabba also proposed a Google Summer of Code idea for improving paravirtualization support: https://reactos.org/wiki/Google_Summer_of_Code_2018_Ideas#Paravirtualization_Support
We don't expect a student to take the idea this summer, but the interest definitely exists in our project as well.

Furthermore, Qubes and ReactOS also fit well together from the organizational standpoint: ReactOS is backed by the German non-profit organization ReactOS Deutschland e.V. while Qubes has the Invisible Things Lab company behind it. ReactOS Deutschland e.V. is getting a lot of donations from individual people, however - as a non-profit - the only way for it to fund development is granting scholarships (up to ~1000 EUR/month) to students or hiring IT freelancers who invoice us. Hiring developers directly has never been an option for us, but this should be different for Invisible Things Lab.
That means, if we find a task of mutual interest and a suitable developer, the person may be hired by ITL and partly funded by ReactOS Deutschland e.V. (having ITL invoice ReactOS Deutschland e.V.).
Additionally, I was told that ITL may acquire some customers to pay for Windows application support on Qubes. This adds another source of funding to these tasks, which is currently unavailable to ReactOS Deutschland e.V.

Finally, @vicmarcal of the ReactOS Project also explored possible collaborations with your project earlier.
Adding him to this discussion.

[marmarek]

Thanks for writing @ColinFinck !

I was told that a basic ReactOS AppVM in Qubes only needs standard drivers and they wanted to try out such an installation as the first step. Don't know about its outcome though, so maybe you could comment here.

There are a little more technical details about the problem here: https://groups.google.com/d/msgid/qubes-users/20180318152707.GH8712%40mail-itl
In short: installation fails (either lack of disk drivers, or some weird crash - also in disk drivers?). But live image more or less works.

As of today, Windows support is pretty low on ITL's priority list, so it's unlikely we'll commit significant resources to it. But we're more than happy to help coordinating this work, review code, test things. There are also multiple people in Qubes community interested in this work, maybe someone is able to help here.

[vicmarcal]

Hi! Victor here. Aside the potential income stream from QubesOS customers willing to be running Windows software, there is a nice opportunity of several Horizon2020 R&D grant opportunities from the EU. These grants could be used to fund the R&D and integration needed for this project. These grants need 3 parties from different countries. The amount that can be requested are up to 3M$, covering 70% of the amount requested. (100% in case all the parties are non-profit ones). QubesOS+ReactOS would be 2, a 3rd one could be one of these potential final companies/customers as part of the pilot phase. This way we could leverage QubesOS plus ReactOS investment in this project.
I'm glad to help with anything related to H2020 Grants, and while this talk should follow up in private(in case we are both interested in it) just willing to highlight here this potential funding way that probably you're already aware.

[blackcrack]

the Eu support is a good thing, good to hear/know ! :))

[Jeeppler]

@XVilka ReactOS released a couple new releases since I last tested it. I have not done any tests with newer versions of ReactOS on Qubes OS 4+.

Do you have anything in particular you want to achieve? For example, run a specific software?

[brunoais]

In my specific case, I'd like to run the old office 2003 on qubes, for example

…

On Fri, Jul 12, 2019 at 10:58 AM Jeppler ***@***.***> wrote: @XVilka <https://github.com/XVilka> ReactOS released a couple new releases since I last tested it. I have not done any tests with newer versions of ReactOS on Qubes OS 4+. Do you have anything in particular you want to achieve? For example, run a specific software? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2809?email_source=notifications&email_token=AAE4D27T5LHT3CXGIF7FUMDP7BIUPA5CNFSM4DLJJR5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZKAAY#issuecomment-510828547>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE4D253O54MK53C6BGHN3LP7BIUPANCNFSM4DLJJR5A> .

[tlaurion]

@marmarek @Jeeppler @XVilka @vicmarcal
With Windows7 going EOL soon, having a ReactOS template would really be awesome.

@marmarek : How can we setup a bounty for that so that people just preauth money until a dev provides proof of work? This kind of system is more then needed. Is there another issue opened on that subject?

Please tag other people that have worked on this so that the status of this issue is clear.

[andrewdavidwong]

How can we setup a bounty for that so that people just preauth money until a dev provides proof of work?

Currently, you would set that up yourself, as others have done for #4318.

This kind of system is more then needed. Is there another issue opened on that subject?

As far as I know, there is no open issue for a system that is officially sanctioned by the Qubes OS Project (as opposed to the kind of community-run bounty you see on #4318). You are welcome to open such an issue. However, it should acknowledge our policy against donations being tied to feature requests.

[mfc]

FYI I just created a bounty tag for the issue tracker, so once this has a public bounty we can add this so others can more easily find issues with public bounties.

[XVilka]

You can add donate cryptocurrency donation daemon that operates without any fee to be able to attach a bounty to this issue without any third-party platform.
See how it looks, for example:
https://github.com/jollheef/donate/issues/13#issuecomment-610856574

Another option would be run OpenCollective + GitHub Sponsors.

[tlaurion]

@mfc @XVilka : really interesting concept!

But just like for #4318, the problem lies the other way around IMHO.

• Devels need to quote needed funded work by creating milestones and required amount of work (funds) to accomplish work.
• Funds will come for devel committed tasks for interested known developers being able to do the work (who provided milestones)
• Work will start when funds are available to pay a milestone.
• Funds are released upon proof of work.

Or am I wrong?

[fepitre]

I'll give some details soon on my current work on integrating ReactOS in Qubes 4.1 but in the mean time, here what I've just sent to @marmarek:

[Jeeppler]

@fepitre wow, looks good. Can we test it?

• Are you working on drivers as well?
• Are you working on clipboard sharing, window resizing too?

[fepitre]

@fepitre wow, looks good. Can we test it?

I'm currently debugging a post-install issue on one laptop with Qubes but I don't have this problem in the setup you can see: KVM -> QubesOS (as VM) -> Reactos as HVM. So I would say you can try by picking a very new WIP R4.1 with dom0 fc32 on openqa.qubes-os.org and try to install the today nightly build of ReactOS. But I would recommend to try on the previous R4.1 with dom0 fc31. It should produce the same result as version for Xen, libvirt and stubdom are the same.

* Are you working on drivers as well?
* Are you working on clipboard sharing, window resizing too?

As it's not on my assigned tasks for Qubes, I'm doing this on my free time and I want to go as far as I can on your topic questions. Mostly this is a new and very interesting challenge for me :)

[brendanhoar]

openqa 4.1 iso from 2-3 days ago is available now, worth trying, @fepitre ?

[fepitre]

openqa 4.1 iso from 2-3 days ago is available now, worth trying, @fepitre ?

We are currently merging and finishing all the dom0-root thin pool split with @marmarek so it's certainly no the latest iteration of merged components but you can give it a try if this is for trying only ReactOS :). Any post-install log of serial console of ReactOS are welcomed. For this, you need to add a serial console to the ReactOS HVM. For example, if you create a HVM called reactos, follow the guide https://dev.qubes-os.org/projects/core-admin/en/latest/libvirt.html#file-paths. The interesting part is:

{% extends 'libvirt/xen.xml' %}
{% block devices %}
    {{ super() }}
    <serial type='pty'>
        <target port='0'/>
    </serial>
{% endblock %}

to be added to the file (to be created with parent folders): /etc/qubes/templates/libvirt/xen/by-name/reactos.xml. Then on the boot menu of ReacOS, start in Debug mode and finally, in dom0, xl console -r reactos.

[fepitre]

openqa 4.1 iso from 2-3 days ago is available now, worth trying, @fepitre ?

I just succeeded to install it on my laptop as HVM. The trick was first to setup ROS without network then skipping the detection tool. Shutdown and attach network. Now it remains to understand what is messing. Some talk has been made on chat.reactos.org

[unman]

I use the "init" hack to load xvda as a hda - I dont use it (much) but am told ReactOS is solid as a rock.
I do this for all "react..." qubes. Interestingly, when that patch was applied to all HVMs, a Windows7 qube booted just fine, marking the disk as ide, and keeping others as scsi, without a problem. Surprising.

[brendanhoar]

Tell us more about the "init" hack?

[unman]

You can customise the init in /usr/lib/xen/boot/stubdom-linux-rootfs to override the qemu launch parameters.
In particular, you can change the parameters for system storage so it is presented as an ide device. Doing so allows you to install ReactOS (and Android) in to an HVM.
Networking in ReactOS works out of the box in 4.0.3, with no configuration needed.

Since the init is a shell script, it's possible to apply these changes to specific qubes, rather than across the board. For example, any qube whose name begins with 'react' will have /dev/xvda on ide bus.
Some notes - https://github.com/unman/notes/blob/master/disks_in_Qubes

The file isn't protected on dom0 updates, so I use a shell script to automate the process.

[tlaurion]

I was pointed to the hacks to be implemented directly in future TemplateVM

[marmarek]

If changing disk to IDE is enough to make it fully work, it should be possible to modify it at the libvirt config level, without the need to hack stubdomain. Note we use SCSI disks, because IDE does not support readonly=on attribute. But it shouldn't be an issue for ReactOS (or Windows).

[erkinalp]

An image mount for the %windir% and %userprofile% a bind mount (to dom0's fs) for the rest will also work.

[tlaurion]

Someone proposed a TemplateVM? What is missing?

[ideologysec]

Someone to do the work of testing, bringup, and maintenance, then getting it approved into the community repos...

[icequbes1]

I quickly trialed this on an up-to-date R4.1 on current-testing and kernel-latest (5.8.16-1), Xen 4.14.0-6. My observations:

1. The official version on the web site (0.4.13) would boot, and I could install using the text-based installer. But booting ended up with a dark gray screen after the splash screen. Same result when using the LiveCD version.

2. Using the Nightly version as of today (0.4.16) did boot successfully and get to the desktop. DHCP worked. But attempting to ping froze the VM. The stubdomain used 99% CPU after that. I could not get into the DM's console.

3. I did not have to do any of the stubdomain tricks with IDE/SCSI/$dm_args. It appears the (R4.1/Xen-4.14) stubdomain always uses IDE for xvd[a-c] now. It's now located at /usr/lib64/xen/boot/qemu-stubdom-linux-rootfs, but the mechanics are still the same as described in unman's "init" hack.

[jeditobe]

Please retry your experiments with a fresh nightly version. There were a lot of updates!

https://reactos.org/blogs/newsletter-100/

[tlaurion]

If changing disk to IDE is enough to make it fully work, it should be possible to modify it at the libvirt config level, without the need to hack stubdomain. Note we use SCSI disks, because IDE does not support readonly=on attribute. But it shouldn't be an issue for ReactOS (or Windows).

@marmarek @unman what are the next steps needed here?

[icequbes1]

Please retry your experiments with a fresh nightly version. There were a lot of updates!

https://reactos.org/blogs/newsletter-100/

I gave the latest nightly a quick try under R4.1, unfortunately did not get it to boot after installation. I did not debug but I suspect it has issues installing on the MBR. Boot sector looked somewhat empty after install, used 99% CPU at boot.

[fepitre]

Please retry your experiments with a fresh nightly version. There were a lot of updates!
https://reactos.org/blogs/newsletter-100/

I gave the latest nightly a quick try under R4.1, unfortunately did not get it to boot after installation. I did not debug but I suspect it has issues installing on the MBR. Boot sector looked somewhat empty after install, used 99% CPU at boot.

See my message one year ago: https://reactos.org/archives/public/ros-dev/2020-May/019132.html

Brief IRC discussion with ReactOS people looks like to be at driver detection. Notably Xen platform. I've never continue this quest because I don't have time. I wish you good luck with some of ReactOS IRC people ;)

[Narvey]

I'd like to hear if this goes anywhere. It seems the ability to create a Windows qube is a phantom, sometimes there and sometimes not, so it would be nice to have an alternative.