search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
526 stars 46 forks source link

Explore possibility to create ReactOS-based template for Qubes #2809

Open rootkovska opened 7 years ago

rootkovska commented 7 years ago

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

  1. 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:

Likely stages of creating ReactOS-based template:

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 commented 7 years ago

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

Jeeppler commented 7 years ago

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:

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.

reactos_desktop skype_installer ida_5 0_re_tool vlc_big_buck_bunny youtube game_pingus age_of_empires_demo_login age_of_empires_demo anno_1602_demo stronghold_demo

Jeeppler commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago
  • 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

Jeeppler commented 7 years ago

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

Jeeppler commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Here are more testing results:

Games:

age_of_empires_ii_demo stronghold_crusader_demo

Jeeppler commented 7 years ago

In addition I tested the Xen PV Driver:

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

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

v6ak commented 7 years ago

@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 commented 7 years ago

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):

ros

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

blackcrack commented 7 years ago

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 commented 6 years ago

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

ColinFinck commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

XVilka commented 4 years ago

Was there any progress towards this goal?

marmarek commented 4 years ago

None I'm aware of.

Jeeppler commented 4 years ago

@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 commented 4 years ago

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 notifications@github.com 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 https://github.com/QubesOS/qubes-issues/issues/2809?email_source=notifications&email_token=AAE4D27T5LHT3CXGIF7FUMDP7BIUPA5CNFSM4DLJJR5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZKAAY#issuecomment-510828547, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE4D253O54MK53C6BGHN3LP7BIUPANCNFSM4DLJJR5A .

tlaurion commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

image

Another option would be run OpenCollective + GitHub Sponsors.

tlaurion commented 4 years ago

@mfc @XVilka : really interesting concept!

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

Or am I wrong?

fepitre commented 4 years ago

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: Screenshot_qubesos4 1_2020-05-18_16:08:55

Jeeppler commented 4 years ago

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

fepitre commented 4 years ago

@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 commented 4 years ago

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

fepitre commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

reactos

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 commented 4 years ago

Tell us more about the "init" hack?

unman commented 4 years ago

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 commented 3 years ago

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

marmarek commented 3 years ago

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 commented 3 years ago

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

tlaurion commented 3 years ago

Someone proposed a TemplateVM? What is missing?

ideologysec commented 3 years ago

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

icequbes1 commented 3 years ago

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 commented 3 years ago

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

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

tlaurion commented 3 years ago

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?