On Thursday, February 8, 2018 at 2:13:42 AM UTC+1, Marek Marczykowski-Górecki
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wed, Feb 07, 2018 at 02:18:59PM -0800, Yuraeitha wrote:
> > @Ivan
> >
> > On Monday, February 5, 2018 at 7:50:30 AM UTC+1, Ivan Mitev wrote:
> > > On 02/04/18 19:26, Yuraeitha wrote:
> > > > On Sunday, February 4, 2018 at 6:00:15 PM UTC+1, Ivan Mitev wrote:
> > > >>> Also it seems like some functions "might (maybe)" work as intended,
> > > >>> for example I can copy files between VM's and Win7, on a Win7 that
> > > >>> was installed on Qubes 3.2., but backup restored on Qubes 4. Others
> > > >>> seem like they can do this too. Also it seems it's a common problem
> > > >>> not to be internet in the restored Q3.2-Win7, perhaps the code is
> > > >>> different in regards to how it ties networking with Qubes 4? I have
> > > >>> no idea about the rest of the mechanics from a users perspective
> > > >>> though, and most certainly not as a developer as I unfortunately
> > > >>> don't have such skills, I wish I could help more.
> > > >>
> > > >> I just spent a bit of time restoring my windows VM from 3.2, here are a
> > > >> few notes that might be helpful to work around some bugs that you're
> > > >> probably hitting too (I haven't filed any issues yet):
> > > >>
> > > >> - PVH/HVM: in the VM's settings gui, PVH is always displayed whatever
> > > >> the real pref value. -> use qvm-prefs vmname virt_mode to make sure
> > > >> you're really in HVM mode.
> > > >>
> > > >> - Networking: the PV network adapter was stuck at "Identifying" ;
> > > >> pinging an *ip* works but ping a host fails. tcpdump on sys-firewall
> > > >> shows that the requests were sent to the gateway's ip and were
> > > >> rejected.
> > > >> The reason seems to be that in R4.0 VMs are now using the exposed
> > > >> "/qubes-{primary,secondary}-dns" values, while in R3.2 the DNS server
> > > >> was the same as "/qubes-gateway" (see [1]). In my setup,
> > > >> "/qubes-{primary,secondary}-dns" are 10.139.1.{1,2} and /qubes-gateway
> > > >> is 10.137.0.6. DNS requests are rejected because they're sent to
> > > >> 10.137.0.6 instead of 10.139.1.{1,2}
>
> Yes, exactly. Actually /qubes-primary-dns entry is present on R3.2 too,
> but is the same as /qubes-gateway.
>
> > > >> workaround 1-> manually set the DNS servers to
> > > >> /qubes-{primary,secondary}-dns ips. Ping and Internet Explorer worked,
> > > >> but the PV adapter was still suck at "identifying" and my Amazon Kindle
> > > >> for PC app complained about finding no network (it seems there's a
> > > >> windows "connectivity" API/flag that some apps use). However you will
> > > >> have to do this each time after boot since Qubes tools will reset the
> > > >> network settings.
> > > >>
> > > >> workaround 2-> in Program Files/Invisible.../Qubes.../bin/..., rename
> > > >> network-setup.exe to network-setup.exe.bkp to prevent Qubes tools from
> > > >> messing with your network settings, and manually set the VM's IP and
> > > >> DNS
> > > >> servers in the PV adapter network setting. Everything should then work
> > > >> OK, the only problem being that you'll have to make sure you keep your
> > > >> network settings synced (esp. the IP when you clone the VM).
> > > >>
> > > >> - Copying to/from the Win VM: works perfectly - you just have to type
> > > >> twice the destination VM (once in Windows, once in Qubes/dom0), since
> > > >> Qubes Tools aren't updated to reflect R4.0 new "way".
>
> I guess this should be easy to fix, just need to skip the first prompt
> and provide "$default" as destination name in qrexec call.
> Looks this file is relevant:
> https://github.com/QubesOS/qubes-core-agent-windows/blob/master/core-agent-windows.wxs
>
> Compare "Copy to other VM" and "Edit in DispVM" entries.
>
> > > >> note: before finding what was causing the connectivity problem I tried
> > > >> to update xen's windows PV drivers [2] but it broke the VM (ie. it
> > > >> wasn't starting anymore) so I had to restore it again. Anyway IIRC R3.2
> > > >> Qubes Tool's drivers were at the same version as Xen's (8.2), so no
> > > >> need
> > > >> to fiddle with this.
>
> There is also difference in emulated hardware - in R3.2 we use MiniOS
> based stubdomain, with "qemu-traditional" (veeeery old, mostly
> unmaintained qemu fork), while in R4.0 we use Linux based stubdomain,
> with recent version of upstream qemu (2.10.1 at the moment).
> This may cause problems when migrating HVMs between R3.2 and R4.0. There
> is a way to switch some VMs on R4.0 to the old qemu, and it is
> automatically done when restoring HVMs from R3.2 backup:
>
> qvm-features VMNAME linux-stubdom ''
>
> ('' means to _disable_ linux stubdomain...)
>
> When testing new installations, I recommend using new qemu (default
> settings when you create VM). You can copy windows tools installation
> iso from R3.2, it's in /usr/lib/qubes/qubes-windows-tools.iso.
>
> (...)
>
> > > BTW I assumed there was a single "Qubes Tools" service responsible for
> > > setting the network, launching qubesdb daemon, ..., but I noticed a bit
> > > after my post that each task was handled by a different service. So you
> > > can simply disable the "Qubes Network Setup" service instead of renaming
> > > the .exe
> > >
> > > Also,
> > >
> > > https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/network-setup/qubes-network-setup.c
> > >
> > > indeed shows that qubesGateway (/qubes-gateway) is used for DNS (line
> > > 287). The code is easy to understand and adding the new DNS variables, +
> > > setting the servers accordingly (if the variables aren't empty) should
> > > be straightforward. I don't have a Windows build environment to test any
> > > changes though.
>
> For anyone interested, here is instruction how to setup build
> environment:
> https://github.com/QubesOS/qubes-builder-windows/
>
> I know Rafał "Omeg" used Visual Studio for development, but I have no
> idea if anything special was needed there. I see vs2012, vs2013, vs2015
> etc directories in relevant repositories.
>
> > > > It's also very ensuring to hear that it's safe to copy files between
> > > > Win7 and other VM's. I was a bit stressed out over this one due to
> > > > worry of bit-rot.
> > >
> > > Well, it is working but I can't say how safe it is. But I imagine that
> > > R4.0 would disable such copy operations if they were deemed unsafe.
>
> File copy service itself is safe. But if you copy malicious file, it
> will still be malicious.
>
> (...)
>
> A general note about Qubes Windows Tools. This project currently have no
> maintainer, which is the main reason why it isn't uploaded to R4.0
> repositories. But if anyone want to step in and take care of this
> project, even in very basic scope, it would be enough to upload it for
> R4.0. The most basic level needed for that, is testing it on R4.0 and
> fixing the most basic functionality. I think all problems are already
> named in this thread:
> - DNS setup
> - target VM name prompt on file copy
>
> Both looks like 1-line change, but the most time consuming work here is
> testing if that's really enough.
>
> That's all what is needed for including it in R4.0.
>
> Something that would be nice to have, is trying to build it for newer
> Windows versions. I'm by no means Windows developer, but here is what
> I'd try, in order:
>
> 1. Use newer Windows Driver SDK (WDK?) and try building the current code.
>
> 2. Update Xen drivers[1] to newer upstream version (connected there as
> git submodules). Note that some parts of it[2] will need rebasing
> Qubes-specific patches. And try again.
>
> 3. If both fails, I guess that's the point where some actual development
> is needed, possibly including some Windows API knowledge.
>
> Note that GUI agent will surely not work on newer Windows version,
> because Windows Vista is the last version supporting the API we used for
> graphics driver (AFAIR that API is called XDDM, and the new one is
> WDDM). Rafał has spent about half an year trying to develop a new
> driver using WDDM, but apparently there are no longer shortcuts for
> simple drivers without real hardware, you need to emulate a lot of stuff
> that real GPU is doing...
>
> But even getting the thing working without GUI agent would be something
> - - you'll get basic services (file copy etc), network setup and probably
> some more.
>
> [1] https://github.com/QubesOS/qubes-vmm-xen-windows-pvdrivers
> [2] https://github.com/QubesOS/qubes-vmm-xen-win-pvdrivers-xeniface
>
> - --
> 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?
> -----BEGIN PGP SIGNATURE-----
>
> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlp7pDYACgkQ24/THMrX
> 1ywXawgAh+mYZFQbE+k9HtqB/KPDZQC1dOBWOc0pq0HyRKOUFJnT7D4u4mKq5+f8
> TmCbiIAagkyqq2ddZCkdM0zcN7RV+E58Nt0qbLE67pWogJpil/Q/Su1hnt5VBN5y
> 5tP3AtB7Q554IHXacIWG6RUgrkWIjQPKo3bA65EE1eo2xoeVbHgQS0v1UNt3wxLE
> tdzHiKsq3saV+/4ApdIoStzSXGgdHrqsP6VSZplfQm9K8sQtSdsRU+g3IwqT7N1K
> gfzXVi6pndRsg7R7tINYbj1iV1B4elz2l2FjnaMl5W7wauxQdvQg0CqwE/rs5DhI
> oMv4cbLn/1dim+V4Sf2Tsvqbk2FH+g==
> =aIqj
> -----END PGP SIGNATURE-----
This is really nice, thanks a lot Marek!
Are there anyone here up for looking into the needed code changes for a basic
release like Marek described? As for testing, I'll be happy to help out if
anyone is going to update the code, if it is possible to help testing it
without having knowledge of coding. Feel free to ask me if needed. Maybe others
are interested in help testing too.
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/f735fc7a-73e8-43f2-8695-0f2ee660255f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
