Re: [qubes-users] Running Windows from Qubes VM ?

[ThierryIT]

Hi,
Seems to work better even if I am still not able to boot my windows.
With "fdisk" I can see that my bootable HDD is "sdc1".
>From Dom0, when doing a : qvm-start vm-test --hddisk /dev/sdc1, I do have a 
>popup from my Windows drive.

Booting from CDROM  error code failaure 2
Booting from Hard drive, failed no bootable disk 

No bootable device ...

Ideas ?



Le vendredi 12 janvier 2018 17:43:56 UTC+2, awokd a écrit :
> On Fri, January 12, 2018 2:53 pm, ThierryIT wrote:
> > Hello,
> >
> >
> > I am not able to use "qvm-start" because the HVM I have created is
> > "Empty".
> > Dom0 is able to see my Windows 7 hard drive:
> > /dev/sdc2 /run/media/user/32E...CCB type fuseblk
> >
> >
> > From Dom0 I am able to have access to all my Window 7 files.
> >
> >
> > Any ideas ?
> >
> >
> > Thx
> >
> >
> > Le vendredi 12 janvier 2018 13:59:56 UTC+2, awokd a écrit :
> >
> >> On Fri, January 12, 2018 6:48 am, ThierryIT wrote:
> >>
> >>> Hello,
> >>>
> >>>
> >>>
> >>> I have a laptop with two internal Hard Drives.
> >>> One HD with Windows 7 the second Hard Drive with Qubes on it.
> >>> Is it possible to run Windows 7 from a VM's Qubes instead of building
> >>> a Win dows's VM ?
> >>>
> >>
> >> You might be able to create a Win 7 HVM inside Qubes, then use
> >> qvm-start win7 --drive /dev/sdb5 (or wherever your Win7 bootable
> >> partition is located) to start it. Never tried it though.
> 
> Can you provide the exact error message? Not sure why qvm-start would care
> it's empty, it will still boot from a CDROM then too...

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dd05df3b-495a-4cab-a69b-13656a90f018%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

[joeviocoe]

P.S.

Can you please update https://www.qubes-os.org/doc/releases/4.0/schedule/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0c5bfb06-5fd0-4217-a03c-cbadc6857ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

[joeviocoe]

Great news.  Thank you.

I would prefer a fully functional Qubes Manager since a widget that requires 
mouse click or hover is a pain in the butt to keep as a running dashboard.  
That is what I like about the 3.2 version... that I can keep it in one of my 
extra monitors.  Seeing CPU spikes without having to drill down for it is 
convenient.

Thanks again.

On Friday, 12 January 2018 21:58:03 UTC-5, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> The Qubes VM Manager will be returning in Qubes 4.0-rc4, which is
> scheduled for release next week. The returning Qubes Manager will be
> slightly different from the 3.2 version. Specifically, it will not
> duplicate functionality that is already provided by the new 4.0
> widgets. Specific examples include attaching and detaching block
> devices, attaching and detaching the microphone, and VM CPU usage.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZdZwACgkQ203TvDlQ
> MDB4GBAAqKQKgbUHWuTpzfW8o2HOjvM/fSxt9gSlDi+tS3x/dogNC0riO6VgFIJr
> zNUm2/7nYF4iAiES0HamgVfNBHFpKY1QZgRYyokrLMK78HmCyIKJ3A0cF2LOvlsS
> x88xpwBL0zwUX0y/eqsaxGGIqr9D1c25psYdi/IeE3KhR35gz/2j8HiB1/mEl0Z4
> JvepszI6HD7vJ41ullWsygHemTT2JAeFSCG0zWrfdxvkwYFQgXEn+AeEhgOL6BhM
> RXFuMWnl2w0cbnPgDpnmT0IVHlz8gRsljkyWLkqT4k/pldhy9OCjtMKuHGIaaen6
> KLF2rGkpVObfgQQrQOdll03KrFqPona5ywtdeQUMDGVoNJXuhFidyCLWEKPBlAhS
> LDCb/UxRbbPhwol4eEYeOnxWbCMgEwnEtnkEZiT4m9y3lQQLK+8zSZpW5uMLDzs0
> om9Xd9iba7hZomXE1rEcg2UaYok0lSQmzGS2YKh3OQbEmXtrZdILXVo0NLtDcTun
> q47PzYjKc82ZeUZSLBjfkgf0mhocPuwk3FLsMb3rwW0kEbzuRZjHKgxgnRbOK67b
> qH0roZ8GHrX7Xu4AvjYxUvlkTU+h2ObPMvxf2IR1/S37UUyrwNFEaC6czA/VmVV6
> 5SzFVGJkH/SFZsQ9qvzgjz/8OnLOMvBi3X/ee21G8s4ACmcrmrM=
> =fcWR
> -END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e4f0c35-164c-4631-a51c-502ce7c57b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] rc3: Split-gpg + enigmail frequent "qubes.Gpg" prompts

[Chris Laprise]

On Qubes 4.0-rc3 I recently setup Enigmail in Thunderbird to access my
Split-gpg configuration, which I was already using with git. But every
time I encounter a signed message, I'm prompted by a dom0 "qubes.Gpg"
dialog box as many as 4 times in a row (the back-end vm prompts me only
once for the defined time interval).

With the current behavior, I'll probably have to disable Enigmail.

I've double-checked my settings with the split-gpg doc, but I'm
wondering if this could be a bug or if I'm just missing something.

Versions
Debian 9 or Fedora 26
Thunderbird 52.5.2
Enigmail 1.9.9

-- 

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8e8080b9-8422-0dc3-eff5-097deb995be4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-12 04:24, haaber wrote:
>>> 
>>> so people saying the intel meltdown bios patch slows 
>>> performance.  I got an increase in performance lmao.  probably 
>>> depends on os though.
>> 
>> but also in my particular case they also addressed other bugs, 
>> but intel pushed the bios patch for meltdown,  so worth a check 
>> from your boards manufacturer site.
>> 
> When I download the (in my case with HP a win exe) BIOS update 
> file, it contains the "real" bios update (the .BIN file) and some 
> other crap. The only way to avoid tampered downloads seems to 
> download it several times, via tor and some other independent 
> sources & to compare them. I guess you all do that?
> 

Yes, that's what I do. You can also upload the file to Virus Total
(or similar).

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZfKYACgkQ203TvDlQ
MDBwdw/+L3xxP48xEHGI+cd7mw2lw/twXnCz/G0zOcfrUCtdayPLicn921rAcqss
WwZeQGHBSn+ff+CWr7HRtnqn9DLWgVu4kYR+JE9tldf33wSKDJJFwRb0XXoeos2m
oOjOKmMRwYWS2d5VpKLjPmTi8If9dCQvUiH3Ru7XwrarINivZYrLPYTruEZ9joNg
V8cXDuSxgsz853/J9srroFRH/52q7EzW5fW/AGutkh7XrV4Ru4KaEpP2EEKLM0//
VUDBmsO/MrMu2Fsah8b6ypK65hpug5ewG/sx8bSW/O0kFjHzc8zCaffYDtyjt7z5
ezQpFj2XW08Z32nSkTgoXHi/PF07Tmkb5soYYpFfwe8DgaOdOdBfSnTja18d8E65
fjeVrnJANIIy/41oDK6oSlugXWrG50CDflznVCz48W01cX2XAXHifl3ScxT0KTr+
pUqNHWPpdVudp9KP25AFPYbQ5XxBpw07ak4xZC4XbCuNmG6KzPriRs8ncT704pDN
ethh1DViRyeF53xKW/FZS+zktRH2dmkbwVZvdJjtPAo2KnznVgpnMskW/2H6Y0VS
+Pt5f0YYihEM4Gb0+EB8rGMKLP6s1xMaQilki19VLkY0xVlQ6MT7cSEYP3Y5BIjG
tN3Nl2Rv458u4PnACCZnJtYFNxhQxfQUhCAC7JtXIbfh1T1+uJU=
=7yAc
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6ae8c0fe-d8b4-5bc4-83b9-ae1ea5e95fc9%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Manager is coming back in Qubes 4.0-rc4!

[Ted Brenner]

Woohoo! Thanks all!

On Fri, Jan 12, 2018 at 8:57 PM, Andrew David Wong  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The Qubes VM Manager will be returning in Qubes 4.0-rc4, which is
> scheduled for release next week. The returning Qubes Manager will be
> slightly different from the 3.2 version. Specifically, it will not
> duplicate functionality that is already provided by the new 4.0
> widgets. Specific examples include attaching and detaching block
> devices, attaching and detaching the microphone, and VM CPU usage.
>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZdZwACgkQ203TvDlQ
> MDB4GBAAqKQKgbUHWuTpzfW8o2HOjvM/fSxt9gSlDi+tS3x/dogNC0riO6VgFIJr
> zNUm2/7nYF4iAiES0HamgVfNBHFpKY1QZgRYyokrLMK78HmCyIKJ3A0cF2LOvlsS
> x88xpwBL0zwUX0y/eqsaxGGIqr9D1c25psYdi/IeE3KhR35gz/2j8HiB1/mEl0Z4
> JvepszI6HD7vJ41ullWsygHemTT2JAeFSCG0zWrfdxvkwYFQgXEn+AeEhgOL6BhM
> RXFuMWnl2w0cbnPgDpnmT0IVHlz8gRsljkyWLkqT4k/pldhy9OCjtMKuHGIaaen6
> KLF2rGkpVObfgQQrQOdll03KrFqPona5ywtdeQUMDGVoNJXuhFidyCLWEKPBlAhS
> LDCb/UxRbbPhwol4eEYeOnxWbCMgEwnEtnkEZiT4m9y3lQQLK+8zSZpW5uMLDzs0
> om9Xd9iba7hZomXE1rEcg2UaYok0lSQmzGS2YKh3OQbEmXtrZdILXVo0NLtDcTun
> q47PzYjKc82ZeUZSLBjfkgf0mhocPuwk3FLsMb3rwW0kEbzuRZjHKgxgnRbOK67b
> qH0roZ8GHrX7Xu4AvjYxUvlkTU+h2ObPMvxf2IR1/S37UUyrwNFEaC6czA/VmVV6
> 5SzFVGJkH/SFZsQ9qvzgjz/8OnLOMvBi3X/ee21G8s4ACmcrmrM=
> =fcWR
> -END PGP SIGNATURE-
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/qubes-users/6673c015-774a-9178-5aee-d5250610871f%40qubes-os.org.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sent from my Desktop

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CANKZutxc7kxC9Uz4743foOkjsuzRg2DKG9u8t1F3pLW1UVA4sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes Manager is coming back in Qubes 4.0-rc4!

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The Qubes VM Manager will be returning in Qubes 4.0-rc4, which is
scheduled for release next week. The returning Qubes Manager will be
slightly different from the 3.2 version. Specifically, it will not
duplicate functionality that is already provided by the new 4.0
widgets. Specific examples include attaching and detaching block
devices, attaching and detaching the microphone, and VM CPU usage.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZdZwACgkQ203TvDlQ
MDB4GBAAqKQKgbUHWuTpzfW8o2HOjvM/fSxt9gSlDi+tS3x/dogNC0riO6VgFIJr
zNUm2/7nYF4iAiES0HamgVfNBHFpKY1QZgRYyokrLMK78HmCyIKJ3A0cF2LOvlsS
x88xpwBL0zwUX0y/eqsaxGGIqr9D1c25psYdi/IeE3KhR35gz/2j8HiB1/mEl0Z4
JvepszI6HD7vJ41ullWsygHemTT2JAeFSCG0zWrfdxvkwYFQgXEn+AeEhgOL6BhM
RXFuMWnl2w0cbnPgDpnmT0IVHlz8gRsljkyWLkqT4k/pldhy9OCjtMKuHGIaaen6
KLF2rGkpVObfgQQrQOdll03KrFqPona5ywtdeQUMDGVoNJXuhFidyCLWEKPBlAhS
LDCb/UxRbbPhwol4eEYeOnxWbCMgEwnEtnkEZiT4m9y3lQQLK+8zSZpW5uMLDzs0
om9Xd9iba7hZomXE1rEcg2UaYok0lSQmzGS2YKh3OQbEmXtrZdILXVo0NLtDcTun
q47PzYjKc82ZeUZSLBjfkgf0mhocPuwk3FLsMb3rwW0kEbzuRZjHKgxgnRbOK67b
qH0roZ8GHrX7Xu4AvjYxUvlkTU+h2ObPMvxf2IR1/S37UUyrwNFEaC6czA/VmVV6
5SzFVGJkH/SFZsQ9qvzgjz/8OnLOMvBi3X/ee21G8s4ACmcrmrM=
=fcWR
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6673c015-774a-9178-5aee-d5250610871f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-12 07:58, awokd wrote:
> On Fri, January 12, 2018 1:04 pm, Tom Zander wrote:
>> On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users 
>> wrote:
>> 
>>> Would it be of value if I went through the published Docs and 
>>> added these version headers? Should newer versions be added at 
>>> the top (so 4.0 before 3.2 content)? 4.0 might just be "TBD".
>>> 
>> 
>> I think that would be wonderful,
>> 
>> 
>> my main issue is with the not knowing if the current docs are 
>> actually applicable still. If someone could do as much as flag 
>> known out of date content as 3.2 only, this would be a huge 
>> help.
>> 
>> The problem of knowing / identifying what isn't actually 
>> applicable anymore is the main one that I think is causing pain 
>> right now.
> 
> I have a relatively good amount of experience so should be able to 
> call out which is which on sight. If not, I can I point that out 
> too in the 4.0 TBD section.
> 

That would be very helpful! Thank you!

> To your point, some of these docs are pretty version specific. 
> https://www.qubes-os.org/doc/qubes-r3-building/ as a possibly bad 
> example. It's similar to the 4.0 build procedure but at least the 
> name should be generalized then. I think I agree with you those 
> should be separated. I'll plan on skipping them for now.
> 
> I'm a bit concerned it's going to result in ugly looking documents 
> too, but at least by splitting out the contents now it will be 
> easier in the future to move into separate documents if we go that 
> route.
> 

Doing this will provide evidence that helps us decide which system to
us. For example, if it turns out that nearly every document has to be
split into two sections, that might be a strong indication that there
should just be two sets of documents. But if it's only 30%, or if it's
usually just certain sections *within* documents, for example, then it
might make more sense to stick with the current system.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZcjIACgkQ203TvDlQ
MDBB8hAAhuP4K0RtpYbTQoDRSKjomgx7q3TWZUziYNJ7TE2MCgDiGCqs7Bdh8Pk7
4PgNlkOOTVUEgq4ehOgCXbTEL/Gofaat2vrxdPDcXl94Gd4Oi9dhN6c2SGBEAhkL
nkyjY6iXxTRBd0+duqI4jN5CIAUcxOPqV+D/naQaLS2uiRX73rwJkAYDHOhiRUY1
hjd+iLK1AzGjjqJs7yBn2UshxwIMZnEHn7GnwzbI1at+vFOIXLaMk5xIEUiekICL
+9NeC4ijbOVYIni6UjiJ4Dtr1sGk0Nm8XNHKve5/YOlQEDcciXDFk158yZmYUcR+
h9XwV4afPpSe17p+SZiZLG4UkYjner1GSPY5GhbqHM5+FpYEeWmCbkiSBI9HAEiZ
6PMSUwY2yLJ9V7jQHhzbCqYeLDKcsssn/VmNrcH8aPjrs8dDAxmSYHt+Q0O3mn5G
Ka4zgCt6t91PUxYIE2HqAQB3mOSLtKd8gp3rmgkR/HcawSxQfy8Oh6atYMnTu2fG
5G3g407cwwXWedSO9CrqkNz9anCt2MjVKnTXy5j0q0OQtkC7n8GwOz7Q8nPAnH27
WGUlp+0dG6PlLn/MqiR66JdxFMmfv37ATwXj03Zol0JY51B3kczeXzsB5ky6zi2T
T9YjFN0oiJFA3fxCt4iMc51vSB56ufYG5yROCnhbdsfksYU59sQ=
=EGor
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d4c9f2f6-d3ed-e018-c4f0-ed281b1434ab%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-12 08:00, 'awokd' via qubes-users wrote:
> On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote:
> 
>> I'm not so sure, why not use git branches?
> 

One reason that comes to mind:

Segregating the documentation into two different branches would mean
that contributions that apply to both Qubes versions would only end up
in one branch, unless someone remembers to manually submit the same
thing to the other branch and actually makes the effort to do so. Most
of the time, this won't happen. When it does, it means a second pull
request that has to be reviewed. Over time, the different branches
will diverge in non-version-specific content. Good general content
that was submitted only to the 3.2 branch will effectively disappear
once 3.2 is deprecated. (Even if it's still on the website, no one
will look at it, since it'll explicitly be in the subdirectory of a
deprecated version. And there will be a motivation to remove it from
the website so that search results aren't populated with out-of-date
information.)

> It doesn't sound like that's the route the Qubes team wants to
> take right now,

Not necessarily. We want to take whichever route is best. We just want
to be sure it would be a big enough improvement to be worth the
associated costs. As I wrote above:

"If there turn out to be significant, compelling reasons to make
completely separate sets of docs (one for 3.2 and one for 4.x), of
course I'd be happy to do that. We should weigh the costs and
benefits, and choose whichever system is best. From a maintainability
perspective, it seems simpler and easier just to have a single set of
docs, and that's what Qubes has always had, so that's why it's the
default system right now. That's not set in stone, but I think an
alternative system should deliver significant benefits for it
be worthwhile for us to move from the default system. So far, it seems
like the objections to sticking with the default system and simply
having separate sections within the existing docs rest on
misunderstandings about how that system would work, but I'd be
happy to be convinced otherwise. :)"

> but at least splitting the content on the same page would make it 
> easier to migrate to that approach if they change their minds!
> 

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZcEkACgkQ203TvDlQ
MDCcZBAAnmAlCRfKluzVBd36jqGoXGsk9efWDJSSSIS2OUsebk6Tv+cwvDcOfzA6
HhevMmP6iMB637NkHfDe/aMLbmLfq+401g1Ob5JLzvZ008K3Cb88da0VTUmtQ/k1
DKAusV0j/eNGNg9UM9hpRu2XLHdt7fAovIllARKc2hoDLeNA5uxzb0y2ByArpNib
UpaNRZPTPAOCMl2RqjWQIBVhez0Ve8chTqrEx6RHF1NoIBD2FZxJw331z7YLwNUL
iLBtpD928mywhk3VeOZtipP4W6W5l3cgxprYGzU/unxKltOb4D1T5iD+dzkBftFr
euGg07OY5w/lqr9FBONqtgtKLWNrOsT1Ko60eCOuXLA2oBGcV4wIB2Zb22J0JPgW
rCqTn2vhF4wLLW/h0hhMdmj9abxQoShrLoLiUfJa8i+R8yyxWImiY6VbCP7gjAF+
kMHmA88i3yroQawJBwmfnfgGtEpBcFo3+L2uYSUnIQGt3BIW7HYNV1EHKvlA/PIN
xUZGAQkPeaCni3GhsVcGBg3YQcYyrcEn5KyRXQYwvHDUBfA5LDmXH26HCDA6el0F
MOoZk408Mg0QUZD/Tk72K50c5/XzNC9TF7f9JLWtZ+i2ClJu62OORMpYx4ncaq+e
sg6rrSrTZkeZejXh0XbraHNs8WiZVt50kV0JGAFhzSHExnp3Xio=
=WcO8
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bec819c3-c695-ff06-3bca-edbcc79b257e%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qubes app menu keeps old templatevm entries.

[PS1]

> 
> On Qubes xfce 3.2 I had the entries in ~/.local/share/applications
> and the directories in ~/.local/share/desktop-directories
> 
> not sure if it is the right place to clean up however...

It worked for me.
Got rid of the old fedora-23 and debian-8 listings by doing as suggested above. 
 ie. going to  ~/.local/share/applications  and doing  rm -fr   
 Once each listing for,eg. fedora-23 was removed then fedora-23 disappeared 
from the drop-down.
  Could probably have done it quicker via ~/.local/share/desktop-directories 
though?
Thanks for the advice @Tom Zander and @dy...@riseup.net

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fa1a6526-7d94-48b1-b5bb-8957406f66a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] validate IOMMU support

[taii...@gmx.com]

On 01/12/2018 06:31 AM, 'awokd' via qubes-users wrote:


On Fri, January 12, 2018 8:23 am, Wim Vervoorn wrote:

Hello,


Thanks. I tried this. Now I am running into problems with the PCI devices
I am using. Qubes can't reset those. For some reason they are not
exposing the FLR capability. I am trying to find out why because they
should according to the datasheet.

I'm personally interested in this because I have the same issue with a
Corebooted laptop so please let me know if you figure it out, but there
are probably going to be more subject matter experts over on the Coreboot
mailing list!

For purposes of validating IOMMU support though, as long as you can get
one PCI device passed through I think that would be all that matters?
If you can pass through a device, you have quality IOMMU groups and 
IOMMU-IR is enabled in dmesg then you are good to go.


I too would like to know how to modify the PCI capabilities list.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d51bcc21-6893-09fa-d604-eb300eec2f2c%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: porting to ARM

[Leo Gaspard]

On 01/12/2018 12:45 PM, 'awokd' via qubes-users wrote:
> On Fri, January 12, 2018 8:59 am, Ph.T wrote:
>> . my initial motivation for ARM was that
>> intel seemed more prone to #spectre than ARM;
>> https://developer.arm.com/support/security-update
>> "majority of Arm processors are not impacted
>> by any variation of this side-channel speculation mechanism."
> 
> AMD is less prone than Intel too. :)

The vast majority of ARM processors that are not impacted by spectre is
the one that doesn't do speculative execution, afaik. So that's
basically all the “embedded” ones you wouldn't want on a desktop
computer because they are too slow. Then hopefully I'm not thinking of
some processors that would be both unaffected by spectre and
performant... :)

>> and is ARM saddled with ME or SMM? ...not sure.
> 
> It has https://www.arm.com/products/security-on-arm/trustzone, but I don't
> know if owner controlled implementations are available or not.

I don't know TrustZone, but TrustZone-M (on Cortex-M's, embedded world
processors) you can choose what code runs in the TrustZone-M (which is
quite the point) [1]. A quick google search also makes me think with
TrustZone-A too (the “performance” branch of ARM), eg. on RPi, you can
run custom code in it [2], though I haven't read the full paper.

That said, for security reasons it is necessary to lock down the secure
OS in order to prevent offline modification, as it would pave the way
towards evil maid attacks. [3] seems to give ways to do that. And so
manufacturers could, if they wanted to, decide to just sell the chips
with locked-down secure OSes, not giving any way for the user to change
them.


[1]
https://link.springer.com/chapter/10.1007/978-3-319-66332-6_12?no-access=true

[2] https://arxiv.org/pdf/1605.07763.pdf

[3]
https://www.sbs.ox.ac.uk/cybersecurity-capacity/system/files/ARM%20Security%20Technology.pdf

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e2595cd9-1d69-0430-5a02-d1b2c01c6cf7%40gaspard.io.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Running Windows from Qubes VM ?

['awokd' via qubes-users]

On Fri, January 12, 2018 2:53 pm, ThierryIT wrote:
> Hello,
>
>
> I am not able to use "qvm-start" because the HVM I have created is
> "Empty".
> Dom0 is able to see my Windows 7 hard drive:
> /dev/sdc2 /run/media/user/32E...CCB type fuseblk
>
>
> From Dom0 I am able to have access to all my Window 7 files.
>
>
> Any ideas ?
>
>
> Thx
>
>
> Le vendredi 12 janvier 2018 13:59:56 UTC+2, awokd a écrit :
>
>> On Fri, January 12, 2018 6:48 am, ThierryIT wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> I have a laptop with two internal Hard Drives.
>>> One HD with Windows 7 the second Hard Drive with Qubes on it.
>>> Is it possible to run Windows 7 from a VM's Qubes instead of building
>>> a Win dows's VM ?
>>>
>>
>> You might be able to create a Win 7 HVM inside Qubes, then use
>> qvm-start win7 --drive /dev/sdb5 (or wherever your Win7 bootable
>> partition is located) to start it. Never tried it though.

Can you provide the exact error message? Not sure why qvm-start would care
it's empty, it will still boot from a CDROM then too...

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8889817fd5428891fa0923ab9d6aa32c.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Running Windows from Qubes VM ?

[ThierryIT]

Hello,

I am not able to use "qvm-start" because the HVM I have created is "Empty".
Dom0 is able to see my Windows 7 hard drive:
/dev/sdc2 /run/media/user/32E...CCB type fuseblk

>From Dom0 I am able to have access to all my Window 7 files.

Any ideas ?

Thx 

Le vendredi 12 janvier 2018 13:59:56 UTC+2, awokd a écrit :
> On Fri, January 12, 2018 6:48 am, ThierryIT wrote:
> > Hello,
> >
> >
> > I have a laptop with two internal Hard Drives.
> > One HD with Windows 7 the second Hard Drive with Qubes on it.
> > Is it possible to run Windows 7 from a VM's Qubes instead of building a
> > Win dows's VM ?
> 
> You might be able to create a Win 7 HVM inside Qubes, then use qvm-start
> win7 --drive /dev/sdb5 (or wherever your Win7 bootable partition is
> located) to start it. Never tried it though.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/388e882b-5bfe-4f6b-b755-cb1b61280445%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

['awokd' via qubes-users]

On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote:

> I'm not so sure, why not use git branches?

It doesn't sound like that's the route the Qubes team wants to take right
now, but at least splitting the content on the same page would make it
easier to migrate to that approach if they change their minds!


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b6546209d17b77cc1b22250b1ae8a4be.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

['awokd' via qubes-users]

On Fri, January 12, 2018 1:04 pm, Tom Zander wrote:
> On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote:
>
>> Would it be of value if I went through the published Docs and added
>> these version headers? Should newer versions be added at the top (so 4.0
>> before 3.2 content)? 4.0 might just be "TBD".
>>
>
> I think that would be wonderful,
>
>
> my main issue is with the not knowing if the current docs are actually
> applicable still. If someone could do as much as flag known out of date
> content as 3.2 only, this would be a huge help.
>
> The problem of knowing / identifying what isn't actually applicable
> anymore is the main one that I think is causing pain right now.

I have a relatively good amount of experience so should be able to call
out which is which on sight. If not, I can I point that out too in the 4.0
TBD section.

To your point, some of these docs are pretty version specific.
https://www.qubes-os.org/doc/qubes-r3-building/ as a possibly bad example.
It's similar to the 4.0 build procedure but at least the name should be
generalized then. I think I agree with you those should be separated. I'll
plan on skipping them for now.

I'm a bit concerned it's going to result in ugly looking documents too,
but at least by splitting out the contents now it will be easier in the
future to move into separate documents if we go that route.




-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2e113eb73c9fd9f04b452ed23c231242.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

['Tom Zander' via qubes-users]

On Friday, 12 January 2018 13:09:35 GMT Holger Levsen wrote:
> I'm not so sure, why not use git branches?

That has my preference still, but I'm ok for any workable solution.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/22624025.OBojS6ySok%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

['Tom Zander' via qubes-users]

On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote:
> Would it be of value if I went through the published Docs and added these
> version headers? Should newer versions be added at the top (so 4.0 before
> 3.2 content)? 4.0 might just be "TBD".

I think that would be wonderful,

my main issue is with the not knowing if the current docs are actually 
applicable still.
If someone could do as much as flag known out of date content as 3.2 only, 
this would be a huge help.

The problem of knowing / identifying what isn't actually applicable anymore 
is the main one that I think is causing pain right now.

Thanks!
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1727079.pSIrDA7H5a%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Multiple usability issues Qubes 4RC3

['awokd' via qubes-users]

On Fri, January 12, 2018 12:28 pm, aaq via qubes-users wrote:
> Den fredag den 12. januar 2018 kl. 12.38.20 UTC+1 skrev awokd:
>
>> On Fri, January 12, 2018 10:12 am, aaq via qubes-users wrote:
>>
>>
>>> 6) Resizing a urxvt window in my debian unstable to a certain
>>> dimension (or fullscreen hotkey) crashes the terminal. If I have
>>> another window running the VM, and that window already 'broke' the
>>> dimensions in question, then urxvt has no issues taking on any
>>> dimensions. If urxvt is the only window running in the appvm, it will
>>> however keep crashing when it reaches a specific size.
>>
>> That sounds like this issue:
>> https://github.com/QubesOS/qubes-issues/issues/2617. Try starting from a
>>  fresh Qubes Stretch template and upgrading it to unstable. If that's
>> what you did, it might be a regression.
>
> Can anything be done to fix this?
> I can't seem to find a solution in that issue, other than core components
> being updated.
>
> It's fine with me if there aren't any workarounds btw. Just wondering :)

You're right, it's fixed (or should be!) if you are running the stable
Qubes templates but all bets are off if you decide to go and upgrade them
to unstable. :)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/11be549d0310cd1ab3550503ac9e14c2.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Multiple usability issues Qubes 4RC3

[aaq via qubes-users]

Den fredag den 12. januar 2018 kl. 12.38.20 UTC+1 skrev awokd:
> On Fri, January 12, 2018 10:12 am, aaq via qubes-users wrote:
> 
> > 6) Resizing a urxvt window in my debian unstable to a certain dimension
> > (or fullscreen hotkey) crashes the terminal. If I have another window
> > running the VM, and that window already 'broke' the dimensions in
> > question, then urxvt has no issues taking on any dimensions. If urxvt is
> > the only window running in the appvm, it will however keep crashing when
> > it reaches a specific size.
> 
> That sounds like this issue:
> https://github.com/QubesOS/qubes-issues/issues/2617. Try starting from a
> fresh Qubes Stretch template and upgrading it to unstable. If that's what
> you did, it might be a regression.

Can anything be done to fix this?
I can't seem to find a solution in that issue, other than core components being 
updated.

It's fine with me if there aren't any workarounds btw. Just wondering :)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2d2c8071-359d-44fa-af9f-8004a52a62fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Running Windows from Qubes VM ?

['awokd' via qubes-users]

On Fri, January 12, 2018 6:48 am, ThierryIT wrote:
> Hello,
>
>
> I have a laptop with two internal Hard Drives.
> One HD with Windows 7 the second Hard Drive with Qubes on it.
> Is it possible to run Windows 7 from a VM's Qubes instead of building a
> Win dows's VM ?

You might be able to create a Win 7 HVM inside Qubes, then use qvm-start
win7 --drive /dev/sdb5 (or wherever your Win7 bootable partition is
located) to start it. Never tried it though.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d8c97927644ca4f7c3af066bea0d5bf0.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: porting to ARM

['awokd' via qubes-users]

On Fri, January 12, 2018 8:59 am, Ph.T wrote:
> . my initial motivation for ARM was that
> intel seemed more prone to #spectre than ARM;
> https://developer.arm.com/support/security-update
> "majority of Arm processors are not impacted
> by any variation of this side-channel speculation mechanism."

AMD is less prone than Intel too. :)

> and is ARM saddled with ME or SMM? ...not sure.

It has https://www.arm.com/products/security-on-arm/trustzone, but I don't
know if owner controlled implementations are available or not.



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/417826305e26fd58084dffbb988a1cda.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Multiple usability issues Qubes 4RC3

['awokd' via qubes-users]

On Fri, January 12, 2018 10:12 am, aaq via qubes-users wrote:

> 6) Resizing a urxvt window in my debian unstable to a certain dimension
> (or fullscreen hotkey) crashes the terminal. If I have another window
> running the VM, and that window already 'broke' the dimensions in
> question, then urxvt has no issues taking on any dimensions. If urxvt is
> the only window running in the appvm, it will however keep crashing when
> it reaches a specific size.

That sounds like this issue:
https://github.com/QubesOS/qubes-issues/issues/2617. Try starting from a
fresh Qubes Stretch template and upgrading it to unstable. If that's what
you did, it might be a regression.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1209585faf59c9328bb5ba67b0d015fc.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

RE: [qubes-users] validate IOMMU support

['awokd' via qubes-users]

On Fri, January 12, 2018 8:23 am, Wim Vervoorn wrote:
> Hello,
>
>
> Thanks. I tried this. Now I am running into problems with the PCI devices
> I am using. Qubes can't reset those. For some reason they are not
> exposing the FLR capability. I am trying to find out why because they
> should according to the datasheet.

I'm personally interested in this because I have the same issue with a
Corebooted laptop so please let me know if you figure it out, but there
are probably going to be more subject matter experts over on the Coreboot
mailing list!

For purposes of validating IOMMU support though, as long as you can get
one PCI device passed through I think that would be all that matters?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e7eece61bf481dec30d8113178aad1fb.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes in a corporate network behind HTTP proxy

['awokd' via qubes-users]

On Fri, January 12, 2018 8:03 am, pr0xy wrote:
>
>
> SUCCESS!
>
>
> Changing the /etc/apt/apt.conf.d in Debian and the /etc/dnf/dnf.conf in
> Fedora, AND allowing the proxy IP on the firewall of EACH TemplateVM
> finally allows me to update them via the sys-firewall. That's a huge speed
> improvement over sys-whonix.
>
> Now I'm wondering if my failure to set firewall rules was the reason I
> couldn't use your earlier IPtables examples. I might revisit that, but for
> now this solution allows me to use Qubes somewhat normally behind this
> corporate proxy.

Glad to hear it! Sorry I couldn't help more. Would you mind providing a
detailed list of steps you had to do to get this set up behind a corporate
proxy? I know I'm a bit lost and it might help others in the future.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b0bdd7093b4d7986f90b2434d589269c.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

['awokd' via qubes-users]

On Fri, January 12, 2018 4:20 am, Andrew David Wong wrote:

> It shouldn't require much effort. In most cases, all you have to add
> is `## Qubes 3.2` above the existing documentation, shift the rest of the
> headers down one by adding a `#` in front of each one, then add `## Qubes
> 4.0` above the 4.0 content you want to add. It might be
> slightly trickier if the current headings use the underlining syntax. This
> requires basic familiarity with Markdown, but that's already required for
> most doc contributions. Only one person has to do this for each document,
> and many documents will not even require this because the content applies
> to both 3.2 and 4.0.

Would it be of value if I went through the published Docs and added these
version headers? Should newer versions be added at the top (so 4.0 before
3.2 content)? 4.0 might just be "TBD".

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/89c7fa47e95e74b13e9c21e1d721a636.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[haaber]

>>
>> so people saying the intel meltdown bios patch slows performance.  I got an 
>> increase in performance lmao.  probably depends on os though.
> 
> but also in my particular case they also addressed other bugs,   but intel 
> pushed the bios patch for meltdown,  so worth a check from your boards 
> manufacturer site.
> 
When I download the (in my case with HP a win exe) BIOS update file, it
contains the "real" bios update (the .BIN file) and some other crap. The
only way to avoid tampered downloads seems to download it several times,
via tor and some other independent sources & to compare them. I guess
you all do that?

HP does not seem to deliver pgp signatures afaik. But they do ship some
signature files. Is someone aware of how checking these manually? Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6d0c435f-6926-55ae-f5f3-39f5ee38%40web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Multiple usability issues Qubes 4RC3

[aaq via qubes-users]

Den fredag den 12. januar 2018 kl. 10.45.02 UTC+1 skrev a...@it-minds.dk:
> Den mandag den 8. januar 2018 kl. 14.29.06 UTC+1 skrev Ahmed Al Aqtash:
> > Hello all!
> > 
> > 
> > I apologise for the vague subject, but I have been trying all kinds of 
> > things, and I simply can't understand half of the issues, and the other 
> > half I can't seem to find a solution to.
> > 
> > 
> > First of all I have all the respect in the world for the entire Qubes team, 
> > and I sincerely believe that you are making the world a better place.
> > 
> > 
> > The machine: ThinkPad X270 (full specs: 
> > https://www.uk.insight.com/en-gb/productinfo/portatili-e-notebook/0007017591).
> >  It has 8 GB RAM.
> > 
> > 
> > So.. to the issues..
> > 1) A more general gripe with not having enough documentation to actually 
> > get through a setup process. I used Qubes 3.2 before, and I simply went 
> > about Qubes 4 the same way. I know that there have been multiple changes, 
> > and I honestly believe the changes are for the better.
> > 
> > 
> > But issues like moving a templates home directory to /etc/skel (meaning 
> > that appvm's inherit /etc/skel as home dir from the template) left me 
> > baffled with my first install.. I setup my template exactly as I wanted, 
> > created an appvm, and nothing was initialised. I had no idea what was going 
> > on, and the only way I could get some information was through a GitHub 
> > issue. Even after moving everything over to /etc/skel, I still have 
> > issues.. not everything is being carried over, not everything is being read 
> > correctly, and /etc/skel is not being synchronised either. If I add 
> > something new to /etc/skel AFTER creating a appvm, the appvm's homedir 
> > won't be updated.
> > 
> > 
> > I like the idea with moving all the GUI functionality to the shell. I 
> > prefer using the shell anyway. But for instance, in 3.2, you could allow 
> > access to through the firewall for a templatevm. Now it has to be done 
> > through qvm-prefs. This is not documented anywhere, and this was also an 
> > infuriating issue for me.
> > 
> > 
> > 2) I have reinstalled qubes multiple times over the weekend (friday through 
> > sunday) to get my install at a state that I am actually satisfied with.
> > 
> > 
> > Most griping issues: sys-net and sys-firewall do not start on boot. 
> > Journalctl claims that there isn't enough memory to start sys-net on boot 
> > (I don't have anything more descriptive for sys-firewall).
> > I can easily start them after boot and login. If I need more memory, then I 
> > will happily upgrade. I intended to do so anyway, but I cannot understand 
> > why it worked fine in 3.2 with 8 GB RAM.
> > 
> > 
> > 3) The issue mentioned under documentation with setting up a template 
> > exactly the way I want it.
> > To understand the issue in depth, I think it's in place to describe my 
> > setup:
> > Having 2 base templates (based on the debian 9 template):
> > 
> > 
> >   * One I call 'trusted' which is based on debian sid (unstable) that I 
> > install everything I use for daily usage (firefox, libreoffice, mpv, emacs, 
> > other open source tools). Primarily AppVM's will be based out of this 
> > template.
> > 
> > 
> > * One I call 'untrusted' that is going to be a clone of 'trusted', and that 
> > I install proprietary software in, that I also use on a daily basis (e.g. 
> > spotify). Also AppVM's out of this, but probably only 1 to start with.
> > 
> > 
> > * I will probably create a standalone VM based off of 'trusted' that I use 
> > for development. So I will install stuff like docker, golang, and all other 
> > stuff I would otherwise use for developing.
> > 
> > 
> > I have not been able to create my 'trusted' template in a proper manner, 
> > since I can't get /etc/skel to work properly.
> > 
> > 
> > NOTE: I use zsh with oh my zsh and spacemacs. Both of which are git repos 
> > that are cloned to the homedir of the user (meaning they are git repos 
> > cloned to /etc/skel)
> > If this is improper usage, then please guide me to how I should go about 
> > doing this instead, as I have no idea what the smartest solution would 
> > otherwise be.
> > 
> > 
> > Sorry for the long email, and thanks in advance for clarifying answers.
> > 
> > 
> > Best regards and all the best.
> 
> UPDATE:
> 
> So, I decided to go on with an install and with the knowledge of my previous 
> misinstalls and guidance from here this is the result:
> 
> 1) I decided to go on with the install and scheme that I already wrote about. 
> I looked into bind-dirs, and it is definitely something I am going to use at 
> some point, but the effort right now on a 'per-application basis' is simply 
> too much (I just need a running system).
> 
> 2) I still have an issue with sys-net/sys-firewall not being started on boot, 
> but this problem isn't really a dealbreaker for me. It's just an annoyance.
> 
> 3) Sound doesn't seem to be working in debian (unstable). None of the fixes 
> seem 

[qubes-users] Re: Multiple usability issues Qubes 4RC3

[aaq via qubes-users]

Den mandag den 8. januar 2018 kl. 14.29.06 UTC+1 skrev Ahmed Al Aqtash:
> Hello all!
> 
> 
> I apologise for the vague subject, but I have been trying all kinds of 
> things, and I simply can't understand half of the issues, and the other half 
> I can't seem to find a solution to.
> 
> 
> First of all I have all the respect in the world for the entire Qubes team, 
> and I sincerely believe that you are making the world a better place.
> 
> 
> The machine: ThinkPad X270 (full specs: 
> https://www.uk.insight.com/en-gb/productinfo/portatili-e-notebook/0007017591).
>  It has 8 GB RAM.
> 
> 
> So.. to the issues..
> 1) A more general gripe with not having enough documentation to actually get 
> through a setup process. I used Qubes 3.2 before, and I simply went about 
> Qubes 4 the same way. I know that there have been multiple changes, and I 
> honestly believe the changes are for the better.
> 
> 
> But issues like moving a templates home directory to /etc/skel (meaning that 
> appvm's inherit /etc/skel as home dir from the template) left me baffled with 
> my first install.. I setup my template exactly as I wanted, created an appvm, 
> and nothing was initialised. I had no idea what was going on, and the only 
> way I could get some information was through a GitHub issue. Even after 
> moving everything over to /etc/skel, I still have issues.. not everything is 
> being carried over, not everything is being read correctly, and /etc/skel is 
> not being synchronised either. If I add something new to /etc/skel AFTER 
> creating a appvm, the appvm's homedir won't be updated.
> 
> 
> I like the idea with moving all the GUI functionality to the shell. I prefer 
> using the shell anyway. But for instance, in 3.2, you could allow access to 
> through the firewall for a templatevm. Now it has to be done through 
> qvm-prefs. This is not documented anywhere, and this was also an infuriating 
> issue for me.
> 
> 
> 2) I have reinstalled qubes multiple times over the weekend (friday through 
> sunday) to get my install at a state that I am actually satisfied with.
> 
> 
> Most griping issues: sys-net and sys-firewall do not start on boot. 
> Journalctl claims that there isn't enough memory to start sys-net on boot (I 
> don't have anything more descriptive for sys-firewall).
> I can easily start them after boot and login. If I need more memory, then I 
> will happily upgrade. I intended to do so anyway, but I cannot understand why 
> it worked fine in 3.2 with 8 GB RAM.
> 
> 
> 3) The issue mentioned under documentation with setting up a template exactly 
> the way I want it.
> To understand the issue in depth, I think it's in place to describe my setup:
> Having 2 base templates (based on the debian 9 template):
> 
> 
>   * One I call 'trusted' which is based on debian sid (unstable) that I 
> install everything I use for daily usage (firefox, libreoffice, mpv, emacs, 
> other open source tools). Primarily AppVM's will be based out of this 
> template.
> 
> 
> * One I call 'untrusted' that is going to be a clone of 'trusted', and that I 
> install proprietary software in, that I also use on a daily basis (e.g. 
> spotify). Also AppVM's out of this, but probably only 1 to start with.
> 
> 
> * I will probably create a standalone VM based off of 'trusted' that I use 
> for development. So I will install stuff like docker, golang, and all other 
> stuff I would otherwise use for developing.
> 
> 
> I have not been able to create my 'trusted' template in a proper manner, 
> since I can't get /etc/skel to work properly.
> 
> 
> NOTE: I use zsh with oh my zsh and spacemacs. Both of which are git repos 
> that are cloned to the homedir of the user (meaning they are git repos cloned 
> to /etc/skel)
> If this is improper usage, then please guide me to how I should go about 
> doing this instead, as I have no idea what the smartest solution would 
> otherwise be.
> 
> 
> Sorry for the long email, and thanks in advance for clarifying answers.
> 
> 
> Best regards and all the best.

UPDATE:

So, I decided to go on with an install and with the knowledge of my previous 
misinstalls and guidance from here this is the result:

1) I decided to go on with the install and scheme that I already wrote about. I 
looked into bind-dirs, and it is definitely something I am going to use at some 
point, but the effort right now on a 'per-application basis' is simply too much 
(I just need a running system).

2) I still have an issue with sys-net/sys-firewall not being started on boot, 
but this problem isn't really a dealbreaker for me. It's just an annoyance.

3) Sound doesn't seem to be working in debian (unstable). None of the fixes 
seem to work either. This is kind of critical to me..

4) All around okay for now, but I can definitely tell that I would love some 
more stability, but that's just a matter of patience :)

Thank you for your assistance Tom, much appreciated.

I hope this thread can help others.

-- 
You received this 

Re: [qubes-users] Re: porting to ARM

[Ph.T]

. my initial motivation for ARM was that
intel seemed more prone to #spectre than ARM;
https://developer.arm.com/support/security-update
"majority of Arm processors are not impacted
by any variation of this side-channel speculation mechanism."

and is ARM saddled with ME or SMM? ...not sure.

I've had an ARM-based laptop (the chromebook),
there are more coming but it was rocky start.
https://www.computerworld.com/article/3161291/chromebooks/arm-to-battle-intel-in-chromebooks-and-windows-10.html
however:
https://www.pcworld.com/article/2834764/arm-vs-intel-why-chipmakers-want-your-chromebooks-brains.html
"while ARM can run most other operating systems,
it can’t run Windows—at least, not the traditional
X86-based Windows that is powered by AMD and Intel chips."

deal killer?

On Wed, Jan 10, 2018 at 5:25 PM, taii...@gmx.com  wrote:
>
> And yes ARM has a kind of IOMMU, I believe it is called GIC-v3 but not
> available on the average ARM stuff like a laptop or phone.
>

. GIC-v3 is version 3 of the Generic Interrupt Controller;
http://infocenter.arm.com/help/topic/com.arm.doc.dai0492b/GICv3_Software_Overview_Official_Release_B.pdf
the feature like VT-d on ARM is SMMU:
https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf
"Intel Virtualization Technology for Direct I/O [Intel VT-d]
is an I/O memory management unit (IOMMU)
designed for the VMM (Virtual Machine Monitor),
to support I/O virtualization.
Since Intel VT-d has the capability of
fine-grained access control per device,
it is a better mitigation for DMA attacks.
Other system architectures also have similar IOMMU capability,
such as [AMD IOMMU], [ARM SMMU]."

details of GIC-v3:
http://infocenter.arm.com/help/topic/com.arm.doc.dai0492b/GICv3_Software_Overview_Official_Release_B.pdf
Support for virtualization.
Support for more than eight PE[processor elements]s.
Support for up to 1020 interrupt IDs.
Support for two Security states.
Support for more than eight PEs.
Support for message-based interrupts.
Support for more than 1020 interrupt IDs.
System register access to the CPU Interface registers.
An enhanced security model,
separating Secure and Non-secure Group 1 interrupts.
Virtualization:
ARMv8-A includes optional support for virtualization.
To complement this, GICv3 also supports virtualization.
Support for virtualization support in GICv3 adds:
 Hardware virtualization of the CPU interface registers.
 Virtual interrupts.
 Maintenance interrupts.
NOTE: The GIC architecture does not provide
features for virtualizaing the Distributor,
Redistributors or ITSs.
Virtualization of these interfaces must be handled by software.
This is outside the scope of this document and is not described here.

ARM Virtualization with SMMU:
https://www.arm.com/files/pdf/System-MMU-Whitepaper-v8.0.pdf

The ARM® Architecture Virtualization Extensions
and the importance of System MMU [mem mgt unit]
for virtualized solutions and beyond.
This paper ...explores how SMMU
will enable vast reductions in
software costs and complexity,
and at the same time aligning with the ARM’s ethos of
low power, high performance designs.
.
Memory management challenges in virtualized systems:
In a virtualized system, the subject of memory management
is very important and can lead to substantial complexity.
One of the key functions of most operating systems
is to support a stage of virtual memory management
to partition the physical memory
controlled by the operating system
across multiple processes.
In a system where each Guest OS is running inside a Virtual Machine,
the memory that is being allocated by the Guest OS
is not the true physical memory of the system,
but instead it is an intermediate physical memory.
The VMM directly controls the allocation of the
actual physical memory,
thereby fulfilling its role of arbiter
of the shared physical resources.
There are two approaches to handling the
two stage of address translation (VA to IPA and IPA to PA).
In current systems where only one stage
of memory address space translation
is provided in hardware,
for example using the MMU in the CPU,
the hypervisor must manage the relationship between
VA, IPA and PA directly.
This is generally done by the hypervisor
maintaining its own translation tables
(called shadow translation tables),
which are derived by interpreting
each Guest OS translation table.
The hypervisor must ensure that
all changes to the Guest OS translation tables
are reflected in the shadow structures,
as well as enforcing protection and redirecting
access faults to the appropriate stage.
The required mechanism can be complex
and add performance overhead.
The alternative is to use hardware assistance
for both stages of translation,
and this is what the ARM SMMU enables.

I later thought this topic more appropriate for the qubes-devel newsgroup;
https://groups.google.com/d/msgid/qubes-devel/ce1a9bb0-5b7e-441f-87ae-16df277fd428%40googlegroups.com
.
but if ARM can't do 

RE: [qubes-users] validate IOMMU support

[Wim Vervoorn]

Hello,

Thanks. I tried this. Now I am running into problems with the PCI devices I am 
using. Qubes can't reset those. For some reason they are not exposing the FLR 
capability. I am trying to find out why because they should according to the 
datasheet.

Best regards,

-Original Message-
From: awokd [mailto:aw...@danwin1210.me] 
Sent: Thursday, January 11, 2018 10:50 AM
To: Wim Vervoorn 
Cc: qubes-users 
Subject: Re: [qubes-users] validate IOMMU support

On Thu, January 11, 2018 9:43 am, Wim Vervoorn wrote:
> Hello,
>
>
> I added IOMMU support to coreboot (DMAR tables with filled DHRD and 
> RMRR
> structures) and want to make sure everything is configured correctly.
>
> I did check this using the Ubuntu fwts and also checked using 
> qubues-hcl-report. All of these seem fine and I don't notice any 
> obvious issues issues in my Qubes 4.0 rc 3 installation.
>
> There are no warnings regarding this in the dmesg and journalctl.
>
>
> Can I assume everything has been implemented correctly in Qubes or 
> should I perform additional testing to  make sure this is really working?

Not sure how "obvious" you mean, but I think if you have tested PCI passthrough 
to an HVM and it works, you should be good.




-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a980234ef1b74ba5b802ff80a9d7321b%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes in a corporate network behind HTTP proxy

[pr0xy]

On 2017-12-28 01:07, Unman wrote:
> On Thu, Dec 21, 2017 at 10:57:26PM -0800, pr0xy wrote:
>> On 2017-12-19 15:33, Unman wrote:
>> > On Tue, Dec 19, 2017 at 03:09:05PM +0100, 'Tom Zander' via qubes-users 
>> > wrote:
>> >> On Monday, 18 December 2017 10:13:48 CET pr0xy wrote:
>> >> > I am still a bit stuck concerning the Qubes Update Proxy. Where would I
>> >> > set the environment variables for my corporate proxy so that I could
>> >> > update dom0, templates and VMs?
>> >>
>> >> You should add sys-net to your template VM if you want that since the 
>> >> proxy
>> >> that is in place today is to avoid your template VM from accessing the
>> >> intranet or internet outside of your own machine.
>> >>
>> >> Then google on where the template operating system (Fedora or Debian etc)
>> >> sets proxies for doing the command-line update, the configuration is the 
>> >> same
>> >> as Fedora or Debian etc.
>> >> I don’t know fedora at all,
>> >> in archlinux you’ll have a file in /etc/pacman/ which sets the current 
>> >> proxy,
>> >> in debian you’ll likely have one in /etc/apt/
>> >>
>> >> grep -R -i  PROXY /etc/*
>> >>
>> >> may be useful too.
>> >
>> > Tom
>> >
>> > Ive suggested before that if you give this advice you should
>> > clearly state the consequences.
>> >
>> > op - please dont do this. sys-net will not enforce a firewall and it is
>> > bad practice to expose your templates in this way.
>> >
>> > i understand you chose  not to use the iptables route.
>> > If you want to combine the Qubes proxy with an external proxy on
>> > your network you should be able to do this by editing the tinyproxy.conf
>> > file. You will find this in /etc/tinyproxy.
>> >
>> > Qubes uses tinyproxy for all the template updates. you can make
>> > tinyproxy use an external proxy.
>> > The change you need to make is:
>> > upstream  host:port
>> >
>> > check the documentation at
>> > https://tinyproxy.github.io
>> >
>> > unman
>>
>> I did try the iptables method you suggested, but like Marek said, the
>> applications weren't aware of the proxy and didn't use it. I would just
>> get failed connections without setting the proxy in each piece of
>> software in each AppVM. The environment variable setting seemed to work
>> better in the AppVMs.
>>
>> I tested setting the upstream  host:port in the tinyproxy.conf of
>> sys-firewall. That didn't seem to work as I couldn't get Template
>> updates to connect to look for updates. I also tested setting this same
>> method on sys-net, but with the same results.
>>
>> I also asked around on IRC about this, and was told that the Qubes
>> Update Proxy could be adjusted from here:
>>
>> /etc/systemd/system/multi-user.target.wants/qubes-updates-proxy.service
>>
>> Wasn't sure how I could manipulate the proxy from there, but it does
>> point to tinyproxy at /etc/tinyproxy/tinyproxy-updates.conf
>> I tried adding the upstream  host:port to that file on sys-firewall, but
>> the template updates still give me an "Error: Failed to synchronize
>> cache for repo 'updates'" The result was the same attempting the same
>> setting on sys-net.
>>
>>
> 
> Its very difficult to troubleshoot this without knowing more about what
> is happening at the proxy , and in the Qubes networking.
> 
> Those iptables rules work with squid as a transparent proxy without any
> client configuration. But they dont work for you. Please make sure that
> you therefore remove any trace of them from your system.
> 
> As setting the proxy in tinyproxy didn't work for you either make sure
> you  remove those entries too.
> 
> I  suspect the best thing to try is to to edit the qubes proxy config
> file in the template. In a Debian template its in /etc/apt/apt.conf.d and
> in Fedora /etc/yum.conf.d or /etc/dnf/dnf.conf
> (Sorry to be vague but i dont have a Qubes box to hand.)
> 
> 
> Edit the file so that it points to your corporate proxy instead of the
> 10.137.255.254 host.
> Then make sure that you add the corporate proxy IP and port to allowed
> in the template firewall.
> You should be able to use just the HTTPS proxy port for both HTTP and
> https traffic from the template.
> 
> good luck
> 
> unman

Thanks for following up on this Unman. I really appreciate it.

SUCCESS!

Changing the /etc/apt/apt.conf.d in Debian and the /etc/dnf/dnf.conf in
Fedora, AND allowing the proxy IP on the firewall of EACH TemplateVM
finally allows me to update them via the sys-firewall. That's a huge
speed improvement over sys-whonix.

Now I'm wondering if my failure to set firewall rules was the reason I
couldn't use your earlier IPtables examples. I might revisit that, but
for now this solution allows me to use Qubes somewhat normally behind
this corporate proxy.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: [qubes-users] A question for the Qubes community: multiboot documentation

['Blacklight447' via qubes-users]

Great! Would you consider including instructions on how to multiboot
between Qubes OS 3.2 (main system) and Qubes OS 4 (test/future system)?

I'd love to test and play with 4RCx but need to have a stable
environment for work (3.2).

I can see where your coming from, but I dont know if it would be practicel to 
include documentation for something that will only be used so shortly, because 
it wont be long before qubes 4 gets released, and writing the documentation 
correctly takes some time.
Anyhow, people are always free to contribute it if people deem in neccesary :).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2rHyQ8ddSUb3vC5ZFpsYavhju-SJJds5EEQa-Y4IjwK50jY2GFJxoBL_TJui445dm6a9U1TfWy8OL0UZfYrNjrZM8c7m96b0LoIAU3nAKfo%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.