Testing Windows and QWT in R4.1

Almost everything. Certainly everything on the C drive.

The caveat is: the contents of PhysicalDisk1 (the 2nd volume) are retained on each boot. Currently on your system it is not initialized/formatted and is likely nearly all zero data.

So, you personally can use that if you wish to format and store data to retain from boot to boot (that would be where a moved profile would have gone). However, an attacker could do the same and store data on it, perhaps in an attempt to further signature your windows account, even without formatting it.

So, not exactly fully disposable, but…close?

B

1 Like

wow that is great thanks for the explanation

If during the QWT setup on a Windows 10 TemplateVM i selected the “Move user profiles” option and then deployed an AppVM based off that TemplateVM - changes made within the user profile persist between reboots?

Yes.

Unless you do what I did..
I store files and (mostly portable) apps on an exclusive external storage.

@brendanhoar, do you think it is overkill, or unnecessary as additional precaution?

Hard to say without knowledge of your threat model.

For some workflows, I set up a Windows template and (effectively) use Windows in a disposable fashion - in that case, any data saved would need to go to external/remote storage. It can be useful in this case to write scripts (bat/cmd or ps1) to automate some tasks (depends on workflow).

For other workflows, I set up a windows AppVM, with local files, but don’t put it on a network.

B

Thanks for the response.

  1. Never, ever it is allowed to user to write/execute to/from Q: Always, it can execute from C: (writing to it is disposable anyway).

  2. When I want to write and execute, it hast to be on/from external storage and in template based AppVM. I’m not hiding, and sys-firewall is default VM. I don’t execute from C: This is when I use win app which has no alternative in a Linux world and why I waited for 4.1 for four years. When jevank fixes at-the-moment-a-must-attaching via --persist (if this is about him at all), this appVM will basically look useless to the one who starts it and doesn’t know that it has to attach external storage cause everything happens there. As of now, qvm-block detach after each use…

  3. When I don’t want to write, I use dvm, and execute only from C: I’m hiding there behind sys-whonix. But I indeed have no special need for Windows dvm. If I need dvm, it’s the Linux one. But I’d like to set proper unggogled-chromium as I have under Windows, and so far still couldn’t customize it satisfactory under Whonix. I’ll try with other distros, it’s on my to-do list. I’ll be happy to get a recommendation.

  4. When jevank fixes choppy sound for win qubes, one app goes offline as multimedia. And that would be all from Windows.

Basically no browsing except always contacting several same specific sites for the win app stated under 1. Everything else - Linux.

How can I change the MAC address for my different Windows-10-VM?

I just noticed they are all using my real MAC address.

I tried qvm-prefs win10 -s mac 00:16:3E:5E:6C:05

does not recognize this command

Update: Just drop the -s from the command it works

Dupe.

A new fix for fullscreen HVM issue under R4.1 is now available in current-testing repo.

What the point of Windows VM without any 3D acceleration support?

Security?

1 Like

Definitely security.

What’s the point of Windows?

Hello, you wrote:

I checked now the new version 4.1-65 of QWT under Qubes R4.1,

Where, may I ask, are you getting this version? When I build @fepitre 's crossbuild I get a file called qubes-windows-tools-4.1-1.noarch.rpm which sounds 64 revisions older (and when installed shows same vesion number). There is a file from @ooooooooo above your message https://github.com/0rb677/dotfiles/raw/master/qubes-windows-tools-4.1-65.noarch.rpm but this is now 404.

You need to use the upstream repo: https://github.com/tabit-pro/qwt-crossbuild, the repo you refer is an outdated fork from https://github.com/tabit-pro :wink:

2 Likes

Little correction https://github.com/tabit-pro/qubes-windows-tools-cross :slight_smile:

This repo is adapted to qubes-builder

1 Like

Thanks @jevank @fepitre! I did get it built and installed into win10. And now working! Well, at least it can move files, haven’t done much else :slight_smile:

I did have to do a “repair” second run of the installer to get things working, not sure why - possibly because I did not have Windows updates (going back to September) installed the first time. (I also did not have qvm-features VMNAME gui 1 set at that point but I am guessing that should only affect dom0 not the win10 qwt install.)

Thanks again.

1 Like

It took me a while to find out this part was missing.

@adw, you think this should be mentioned in the Contents/docs/os/windows/windows-vm.md at master · Qubes-Community/Contents · GitHub ?

I don’t know enough to answer that question. I’m only the one who copied/moved the documentation there, not the one who wrote it.

I think you should add it. It will be useful.