date:20180111

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/11/2018 06:48 PM, Unman wrote:
> It's really easy to do this Sven.

I will try this next week ... not sure though if grub is even used. I
am booting via EFI. But I got the basic idea and will do some
google-ing. And of course make backups of everything first.

One of the things I love about Qubes is that "if things go
pear-shaped" I can always wipe, install and then restore all my qubes
from backup. Takes about 3 hours and I'm back in business.

I do a full backup every lunch break. ;-)

/Sven
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpYWI8ACgkQ2m4We49U
H7a/AxAAglGrADFVt876P1uo+d/GSYCIEeW/6E93x0UTj/ZlK9mZ6wakcRqw5E2s
1pyuNn6oONp34kBZnxgCOkXxPe7FyhOKusdeZQCufHQFgxBpSpOSpomVRaaqBSVK
36ZJ7oT6jeZJ3S/Ddxtns8R2I54o4w9n/fhsHLuzmk5Ea5P1pB7KeDAGlpfansnl
NyyYS2f6SxKphf9XfekMMXz5yaqIxzZcUr3ryGZHNRiZfm4uJ22+4cXkPvku3JJP
KXJqgENqomh9Fujwqpa9HOW5L81dCPZLJL/otrmL3FLXPUzIoKI+JisaORFlqE0n
JbbBI0kVl3rTWCPvUwekFgdkr2rSiwIQJykZlAWEL/lDMZHs4IzOPKFNzZAs4MXI
YBRKoYsLlPPWz7ivAzkbJ6sE4FgCJ6Q28ePOW0X5Eyy9kTBVWxH7K6kHoWIMtpCo
wx3pwbAN7MGobyNHqoY/y0cpHcwP8ywLez9/mmxGw6lVVD9UrocTx/rHjvLjCDXR
GxzDmFuvLYFoNjACR2NiJKv8gqR8t2EADj9HbDHyr174P98WkEfB93GQZj1aseRa
0ejr3jq8V4DXns/qixXH9nI57cfmTbjK+EzUinSedH28nEx8zut2Ph/a7aw1579Y
EqtAfnQAbkHz1RmQVnHBqOZA1dL4za482CfrcRjH4eiCSmo2uUU=
=M67V
-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/188c90dc-b2f6-e461-967d-3fda6f0ad41b%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Change default usb qube

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/11/2018 06:25 PM, Unman wrote:
> If you are connected through sys-firewall or similar, then it is 
> sufficient to set the netvm of sys-firewall to none.

Oh wow! Thank you! You just gave me back so much future time...

/Sven
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpYVuYACgkQ2m4We49U
H7bamg/+NhzvUJS53o9Zc6JH2EOep9nRB+6H/cuQPayFvkDPV5UqCocQuAW6Lpcb
HSh4xHy7dqNPWdYJRUIdrtZ9LI7Y7koKV1Wv2LGxHK270mJCmHgZThfhRjbsZDNV
J/WXA0peUjjJzEMBEGFsVekwCBUJ4YXAR2fyVNK4L7+PPf+jwV8Ae4Xd7iiVgHX2
jXu39tcbNRjRA1R/9up5TWcjJcE3VfYRWqqyuotMsbPeCnZHv/Vm8HfNL62d2n1W
fqIIkqGOfc6Iu7zqJdbzbAlhk9A6ctGvaa0yxhRnn4Z/BKMRB5afY5UGvm7SVgNa
Bdp5HcpQ5bgZDBefTW2u384PrUsTv73H8uTBKEEQTficCNFtoNruv+aqH9rbIAh0
1+WbhXEs1y/B3y9YyTLABySUBmknRY7lY4Tyuu/uqiRTLgiotpJniRrmzVs6YfDh
bErC5koNIz6LxNU1lonOjiGGQzP4H23f/cYqRdWtuhH5YR3rC39riskeB59E7cYx
vyKR3mhD0Jz+pDmE9MODJlTVzkjHJJ9CiYjX7XifEl+YVNQkzwPFZDncJuxBdqn9
VTk7KvMZBaPZD6wIOnpcjfcX9Ceurvj9XuFWRG7khOZXNaeYsNRfk3cyi9p4D/ev
Px/onaBg4571tbeTaqCqsoAVdmq0AtStI/n3Cw/1jdU9BRAJNlc=
=Pvhf
-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/27eb7b67-e476-0c60-912f-1e77192e3b82%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

On 01/11/2018 10:31 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-01-11 14:41, Chris Laprise wrote:
>>
>> At least no section repetition for the scripts should be necessary. But
>> doing this for the dialogs still adds a lot to an already long doc.
>>
> 
> Is it bad for a doc to be long when it's immediately obvious which
> half you can ignore because it's not the version you're using?

Not necessarily for a reader, except in the case where the instructions
are long to begin with and the reader happens to scroll into the section
for a different version... without a floating page element that always
keeps the heading visible, the reader might inadvertently mix directions
from the two version-sections.

> 
>> I feel that, apart from making some docs look deceptively long and less
>> readable, the most significant downside to melding 3.x/4.x instructions
>> together would be to discourage contributions from users. It makes the
>> thought of every potential edit seem like a slog through extra markdown,
>> and many will think "I don't have time to install 3.2 to write up that
>> version".
>>
> 
> I don't understand. Why would this be the case? If you want to make a
> small edit that pertains only to 4.0, you can simply make that small
> edit in the 4.0 section, or add such a section if one doesn't yet
> exist, which would only be a few extra characters. A 4.0 user who
> wants to add some true fact about 4.0 to the docs doesn't even have to
> think about 3.2, much less install it.

If they don't have to think about 3.2, that's fine. But I'd expect
queries/requests for "3.2 version" would appear in the PRs about some
new fixes, info or approaches the users are trying to introduce into the
document(s).

Making an edit "that pertains only to 4.0" isn't going to be the mental
context of the user-contributor in most cases. They will just have new
info that they are unsure whether it applies to 3.2 (or if it does,
how). And I'm sure even advanced users will be feeling the uncertainty
and friction before long.

Tom Zander makes some good points, too.

OTOH, I don't want to belabor the issue -- and I'm far from certain
anyway, this is about psychology.

-- 

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/b7b21880-4ecf-fd0f-bf87-3b67b3affda7%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

2018-01-11 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-11 16:11, 'Tom Zander' via qubes-users wrote:
> On Thursday, 11 January 2018 18:16:04 GMT Unman wrote:
>> On the VPN case your own comment confirms that it would be
>> better to provide a separate section, rather than trying to put 
>> "exceptions" in to the existing text.
> 
> Thank you for explaining that unman, much clearer indeed.
> 
> While I agree on the general statement above, I feel its not the 
> best solution in this case where 4.0 have massive changes in all 
> layers of the technology.

A lot of changes, sure, but I wonder whether there are more
similarities than differences overall (thinking about fundamental
things like the use of Xen and TemplateVMs).

> In many cases the about half of the text will be duplicated
> between the 3.2 and the 4.x sections, albeit with major changes.
> This will not help the reader much.

Why is that? Just because many docs will be longer, since they'll have
a section for 3.2 and a section for 4.0?

> More importantly, I fear that the new users (potential 
> contributors) that have not used 3.2 will have a hard time
> deciding what to do with information that clearly doesn't represent
> the current state of technology.
> 

Why will this be a problem? If the section is clearly labeled "Qubes
3.2," but they use 4.0, are you concerned that they won't realize the
section doesn't apply to them? If they can't make that distinction,
though, why expect them to be any more successful at distinguishing
between two sets docs?

> Asking people to put a lot of effort into reformatting 
> documentation

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.

> that may or may not actually be useful to anyone using an older 
> version

Wait, why wouldn't 3.2 documentation be useful to anyone using 3.2?
The majority of users are on 3.2 right now:

https://www.qubes-os.org/statistics/

And 3.2.1 will be supported for a full year after the stable release
of 4.0:

https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/

> is a big ask in a volunteer project.
>> I personally prefer the solution where a git repo is cloned for 
>> 3.2 as
> "legacy" which is then attached to the website under a
> subdirectory and people can edit that for maintainance and fixes. 
> http://qubes-os.org/doc/3/ or somesuch.
> 

If I understand this proposal correctly, all the current documentation
would initially exist in the 4.0 documentation set. But a lot of it,
as you've pointed out, only applies to 3.2. So, who's going to go
through and remove all the content that no longer applies in 4.0?
That's a lot more difficult than formatting a few headings, so it
strikes me as a much bigger ask.

Alternatively, we could start with an empty directory for 4.0. Then
no one has to sort through all the 3.2 documentation to see what still
applies. But now we have an even bigger problem: *all* the
documentation has to be written (or selectively copy/pasted)! This
seems like an even bigger ask the previous one.

Is there some third way you have in mind that I'm missing?

> The majority of changes would then be in the 'master' branch which 
> people can edit and they can add references to the github issues 
> concerning known bugs. We can mark known issues with the pages
> like the VPN one I described and people reading the docs will
> actually be aware of pitt-falls.
> 

You can (and are encouraged) to do exactly this under the current
system. There's nothing stopping you from doing this, and there are a
lot of examples where this has already been done in the existing
documentation.

> In my opinion there is only one thing worse than no documentation, 
> it is official looking documentation that is wrong.
> 

I agree, but I don't see why having clearly-labeled sections where
there are version differences would result in this. If there's some
official documentation in a section called "Qubes 3.2," it's not
"wrong." It applies to 3.2.

Maybe the concern is that, *before* someone gets around to adding the
"Qubes 3.2" heading, a 4.0 user will see it and be misled. That's a
legitimate concern, but how would your alternative proposal avoid it?
If we simply clone the documentation into two separate sets -- one for
3.2 and one for 4.0 -- we have the exact same problem. The 4.0 clone
still has stuff in it that's only true in 3.2, and until someone gets
around to deleting it, a 4.0 user who sees it could be

[qubes-users] HVM Window resizing with Ubuntu on it

2018-01-11 Thread yrebstv

So, thought I should learn how to use HVMs a bit re: the intel issue/4.0
etc. 

Was able to install Ubuntu in a HVM, however the HVM window is quite
small to do anything in , it appears to be un-resizable.  I'm not sure
if I ran Win7 on it, if there might be these "win tools" that might
change this , or maybe there is something simple I am missing?

Seems not an easy to sort through all the "windows" references when
doing search, as this isn't about the OS, but just the HVM window *size 
:)   thanks in advance   go qubes!

-- 
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/e5f9d4402e6bc714b6adcd1bd8dda085%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

2018-01-11 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-01-11 14:41, Chris Laprise wrote:
> On 01/11/2018 01:16 PM, Unman wrote:
>> On Thu, Jan 11, 2018 at 09:18:46AM +, 'Tom Zander' via qubes-users wrote:
>>> On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote:
 On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote:
>>>
> I poked the Qubes guys about providing a separate dir on the website to
> make it clear what is 3.x and what is 4.x specific, but they stated we
> should instead put notices about exceptions in the document pages.

 That's not exactly right. Please see:
>>> ..

 In other words, do not just add notices in the text about exceptions.
 Instead, make clearly-labeled sections for 3.x and 4.x so that users
 can easily find the right information no matter which version of Qubes
 they're using.

> So I guess things like ProxyVMs should be mentioned to be old and AppVM
> is the new.
>>>
>>> Ok, I am having problem seeing your solution and my explanation of it as 
>>> any 
>>> different, in practice.
>>> Maybe I'm missing the obvious, I'm just not seeing it.
>>>
>>> In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/
>>> * in v.4 there is no "NetVM".
>>> * There is no "ProxyVM"
>>> * The create qubes screenshot is considerably different.
>>> * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK).
>>> * does not use iptables anymore.
>>>
>>> Ok, going to stop now.  I got to half the page and some 80% of the text and 
>>> screenshots are wrong for v4.
>>>
>>> How would you solve that in line with the QubesOS policy?
>>
>> The difference is between this style:
>>
>> You can attach a disk image to a qube using qvm-block :
>> qvm-block -A  [qube:] 
>> (This syntax is not available in 4.0)
>>
>> and this:
>> 3.0
>> You can attach a disk image to a qube using qvm-block :
>> qvm-block -A  [qube:] 
>>
>> 4.0
>> You cannot attach a disk image to a qube using qvm-block.
>>
>>
>> The advantage of using labelled sections is that it should be easier
>> for users to find the material relevant to the version they are using.
>> Also, that once 3.0 is retired, it will be simple to remove the 3.0
>> relevant material, rather than filleting our bits from each page.
>>
>> On the VPN case your own comment confirms that it would be better to
>> provide a separate section, rather than trying to put "exceptions" in to
>> the existing text.
>>
> 
> At least no section repetition for the scripts should be necessary. But
> doing this for the dialogs still adds a lot to an already long doc.
> 

Is it bad for a doc to be long when it's immediately obvious which
half you can ignore because it's not the version you're using?

> I feel that, apart from making some docs look deceptively long and less
> readable, the most significant downside to melding 3.x/4.x instructions
> together would be to discourage contributions from users. It makes the
> thought of every potential edit seem like a slog through extra markdown,
> and many will think "I don't have time to install 3.2 to write up that
> version".
> 

I don't understand. Why would this be the case? If you want to make a
small edit that pertains only to 4.0, you can simply make that small
edit in the 4.0 section, or add such a section if one doesn't yet
exist, which would only be a few extra characters. A 4.0 user who
wants to add some true fact about 4.0 to the docs doesn't even have to
think about 3.2, much less install it.

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpYK/4ACgkQ203TvDlQ
MDCO5g//X83cUUXJ+wC3PbbyXFcPnryX+po4wpscNtzjN9XEY3isKFpbzWph2iPD
E365gKrhZCPn5Rmcum2cTtEdtoP9AOzMTgaZGF8xkkq0XZmZsAppAbfEhNHHkcdT
1WMkGvnYsFmt+Q8m0EgRmuKsU+STyrm7b5ZGI2ilweqYyBRMNtbOQl+PaPX4A6dY
snHECZ7yZ9wLQGPJaVV7uxirxEnxq0jtc55jbEou6Pk3yMY3hCKeYzlTi9DMJ8hh
kuVVoH58dXu0R2C7CunpfZ46Z5PRiV3+8Tm5pRBMZHhEomKLIv9VkVZ2JBw9kbmj
FMOmk3XTsYZAFfYpmlKM9yNM0s9ZrHniCZMA6cTlZpqVFlGnsZGso3fqapBayijy
zuGcwYPa0dIw+eWqnz+wbfOPrBxV5U0O3y9hM7HO6RDG0nrBLHO2QKO+wUugCmX0
DkKRkmN5a0oueIDf2DAdeXGLCBnSy9zdcyrtXDtbDh7Rlwg9ko9f82ZZoZM6alIb
7J0J73el8KjLiJEtJPu8vGTYq6EIhoflvXDMzXwd/49Oeoqb7MeJ7qo14iad3bp0
nu3z2n9MSa2VP71p6db9aKOGYb+chHMA6l09vd/Fab4mIQVl/LA2DpEDFV7wOgwv
VJ/Q5VuidOZ0lxw7jpmmeqFC07g98qdxnbP+TXVCsio2JbhcbZA=
=w/TA
-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/029619de-90c6-bdfd-ad38-4ce5f5beb739%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

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

On Thursday, January 11, 2018 at 10:26:53 PM UTC-5, cooloutac wrote:
> On Thursday, January 11, 2018 at 9:57:50 AM UTC-5, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Dear Qubes Community,
> > 
> > We have just published Qubes Security Bulletin (QSB) #37:
> > Information leaks due to processor speculative execution bugs.
> > The text of this QSB is reproduced below. This QSB and its accompanying
> > signatures will always be available in the Qubes Security Pack
> > (qubes-secpack).
> > 
> > View QSB #37 in the qubes-secpack:
> > 
> > 
> > 
> > Learn about the qubes-secpack, including how to obtain, verify, and
> > read it:
> > 
> > 
> > 
> > View all past QSBs:
> > 
> > 
> > 
> > View XSA-254 in the XSA Tracker:
> > 
> > 
> > 
> > ```
> >  ---===[ Qubes Security Bulletin #37 ]===---
> > 
> >January 11, 2018
> > 
> > 
> > Information leaks due to processor speculative execution bugs
> > 
> > Summary
> > 
> > 
> > On the night of January 3, two independent groups of researchers
> > announced the results of their months-long work into abusing modern
> > processors' so-called speculative mode to leak secrets from the system's
> > privileged memory [1][2][3][4]. As a response, the Xen Security Team
> > published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
> > previously share information about these problems via their (non-public)
> > security pre-disclosure list, of which the Qubes Security Team is a
> > member.
> > 
> > In the limited time we've had to analyze the issue, we've come to the
> > following conclusions about the practical impact on Qubes OS users and
> > possible remedies. We'll also share a plan to address the issues in a
> > more systematic way in the coming weeks.
> > 
> > Practical impact and limiting factors for Qubes users
> > ==
> > 
> > ## Fully virtualized VMs offer significant protection against Meltdown
> > 
> > Meltdown, the most reliable attack of the three discussed, cannot be
> > exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
> > matter whether the _target_ VM (i.e. the one from which the attacker
> > wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
> > para-virtualized (PV) by default, though users can choose to create
> > fully-virtualized VMs.  PV VMs do not protect against the Meltdown
> > attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
> > and thus offer protection. However, the fully-virtualized VMs in Qubes
> > 3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
> > "stub domains", making it possible for an attacker who can chain another
> > exploit for qemu to attempt the Meltdown attack.
> > 
> > ## Virtualization makes at least one variant of Spectre seem difficult
> > 
> > Of the two Spectre variants, it _seems_ that at least one of them might
> > be significantly harder to exploit under Xen than under monolithic
> > systems because there are significantly fewer options for the attacker
> > to interact with the hypervisor.
> > 
> > ## All attacks are read-only
> > 
> > It's important to stress that these attacks allow only _reading_ memory,
> > not modifying it. This means that an attacker cannot use Spectre or
> > Meltdown to plant any backdoors or otherwise compromise the system in
> > any persistent way.  Thanks to the Qubes OS template mechanism, which is
> > used by default for all user and system qubes (AppVMs and ServiceVMs),
> > simply restarting a VM should bring it back to a good known state for
> > most attacks, wiping out the potential attacking code in the
> > TemplateBasedVM (unless an attacker found a way to put triggers within
> > the user's home directory; please see [8] for more discussion).
> > 
> > ## Only running VMs are vulnerable
> > 
> > Since Qubes OS is a memory-hungry system, it seems that an attacker
> > would only be able to steal secrets from VMs running concurrently with
> > the attacking VM. This is because any pages from shutdown VMs will
> > typically very quickly get allocated to other, running VMs and get wiped
> > as part of this procedure.
> > 
> > ## PGP and other cryptographic keys are at risk
> > 
> > For VMs that happen to be running concurrently with the attacking VM, it
> > seems possible that these attacks might allow the attacker to steal
> > cryptographic keys, including private PGP keys.
> > 
> > ## Disk encryption and screenlocker passwords are at risk
> > 
> > There is one VM that is always running concurrently with other VMs: the
> > AdminVM (dom0). This VM contains at least two important user secrets:
> > 
> >  - The disk (LUKS) encryption key (and likely the

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

On Thursday, January 11, 2018 at 9:57:50 AM UTC-5, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> We have just published Qubes Security Bulletin (QSB) #37:
> Information leaks due to processor speculative execution bugs.
> The text of this QSB is reproduced below. This QSB and its accompanying
> signatures will always be available in the Qubes Security Pack
> (qubes-secpack).
> 
> View QSB #37 in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and
> read it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> View XSA-254 in the XSA Tracker:
> 
> 
> 
> ```
>  ---===[ Qubes Security Bulletin #37 ]===---
> 
>January 11, 2018
> 
> 
> Information leaks due to processor speculative execution bugs
> 
> Summary
> 
> 
> On the night of January 3, two independent groups of researchers
> announced the results of their months-long work into abusing modern
> processors' so-called speculative mode to leak secrets from the system's
> privileged memory [1][2][3][4]. As a response, the Xen Security Team
> published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
> previously share information about these problems via their (non-public)
> security pre-disclosure list, of which the Qubes Security Team is a
> member.
> 
> In the limited time we've had to analyze the issue, we've come to the
> following conclusions about the practical impact on Qubes OS users and
> possible remedies. We'll also share a plan to address the issues in a
> more systematic way in the coming weeks.
> 
> Practical impact and limiting factors for Qubes users
> ==
> 
> ## Fully virtualized VMs offer significant protection against Meltdown
> 
> Meltdown, the most reliable attack of the three discussed, cannot be
> exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
> matter whether the _target_ VM (i.e. the one from which the attacker
> wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
> para-virtualized (PV) by default, though users can choose to create
> fully-virtualized VMs.  PV VMs do not protect against the Meltdown
> attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
> and thus offer protection. However, the fully-virtualized VMs in Qubes
> 3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
> "stub domains", making it possible for an attacker who can chain another
> exploit for qemu to attempt the Meltdown attack.
> 
> ## Virtualization makes at least one variant of Spectre seem difficult
> 
> Of the two Spectre variants, it _seems_ that at least one of them might
> be significantly harder to exploit under Xen than under monolithic
> systems because there are significantly fewer options for the attacker
> to interact with the hypervisor.
> 
> ## All attacks are read-only
> 
> It's important to stress that these attacks allow only _reading_ memory,
> not modifying it. This means that an attacker cannot use Spectre or
> Meltdown to plant any backdoors or otherwise compromise the system in
> any persistent way.  Thanks to the Qubes OS template mechanism, which is
> used by default for all user and system qubes (AppVMs and ServiceVMs),
> simply restarting a VM should bring it back to a good known state for
> most attacks, wiping out the potential attacking code in the
> TemplateBasedVM (unless an attacker found a way to put triggers within
> the user's home directory; please see [8] for more discussion).
> 
> ## Only running VMs are vulnerable
> 
> Since Qubes OS is a memory-hungry system, it seems that an attacker
> would only be able to steal secrets from VMs running concurrently with
> the attacking VM. This is because any pages from shutdown VMs will
> typically very quickly get allocated to other, running VMs and get wiped
> as part of this procedure.
> 
> ## PGP and other cryptographic keys are at risk
> 
> For VMs that happen to be running concurrently with the attacking VM, it
> seems possible that these attacks might allow the attacker to steal
> cryptographic keys, including private PGP keys.
> 
> ## Disk encryption and screenlocker passwords are at risk
> 
> There is one VM that is always running concurrently with other VMs: the
> AdminVM (dom0). This VM contains at least two important user secrets:
> 
>  - The disk (LUKS) encryption key (and likely the passphrase)
>  - The screenlocker passphrase
> 
> In order to make use of these secrets, however, the attacker would have
> to conduct a physical attack on the user's computer (e.g. steal the
> laptop physically). Users who use the same passphrase to encrypt their
> backups may also be affected.

Re: [qubes-users] live Distro

On Thu, Jan 11, 2018 at 04:40:11PM -0500, Steve Coleman wrote:
> On 01/11/2018 01:35 PM, Unman wrote:
> 
> > I failed miserably to get anything running for 4.0-rc2, so that target
> > has shifted now.
> > 
> > I should be posting updated 3.2 images in the next few days.
> 
> unman,
> 
> Given your difficulty in getting 4.0-rc2 to run, what is the possibility of
> creating a DVD that merely checks the system for the proper BIOS, chipset,
> and other features needed to support a full 4.0 system?
> 
> It seems to me that with the tightening constraints slated for 4.0, just
> having a way to do a quick test of the system hardware before installing
> would be a wonderful tool for the community at large. If one could simply
> boot from a DVD and get some kind of a HCL report, of what "necessary" vs
> desired features needed to support 4.0 that did not work, then that could
> potentially save many people grief from wiping a working system only to find
> out their hardware will not adequately support it.
> 
> If booting your DVD works as a test before upgrade this would be a really
> good thing to have. Please do keep us advised as to your progress on the 4.0
> system capability. Having that as a tool would be awesome.
> 
> thanks,
> 
> Steve

Now that I should be able to do pretty easily. (famous last words.) Run
with one template and allow user to create qube and test network/usb
controllers, and generate HCL.

I'll keep you posted.

-- 
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/20180112005350.et22prraveir4v4f%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

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

On Thu, Jan 11, 2018 at 05:50:27PM -0600, Sven Semmler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 01/11/2018 07:15 AM, 'Blacklight447' via qubes-users wrote:
> > This issue described the lack of documentation how to multiboot 
> > qubes. I have decided that i will be writing it, but as described
> > in the issue above, I need some user feedback.
> 
> 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).
> 
> /Sven
> 

It's really easy to do this Sven.
Install 4 with its own /boot and system partitions, leaving the 3.2
/boot as it is: Let's say the /boot for 3 is sda1 and for 4 is sda3.
Then you can either install grub to sda or to sda3.

If you do the former, then on restart you will boot in to Q4.
If the latter, then on restart you will boot in to Q3, as before.

In either case, mount the OTHER /boot partition and copy the section
from THE OTHER /boot/grub2/grub.cfg starting 
"menuentry 'Qubes' {
.
.
.
}
and paste it in to THIS /boot/grub2/grub.cfg in the section headed 
### BEGIN /etc/grub.d/40_custom
(You MUST include the closing brace.)

You can edit the menuentry title so it's clear to which version it
relates. (e.g menuentry 'Qubes 4.0rc3').
On reboot you should now see the entry you've just inserted and be able
to boot that version.

Once you are happy, make the same change in /etc/grub.d/40_custom. If
you don't, your custom menu entry will disappear the next time you update
grub, perhaps with dom0 update.

I suggest you take a backup of /boot/grub2/grub.cfg before you start
editing. If it all goes pear shaped you can boot from a live distro and
copy the backup back into place.

unman

-- 
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/20180112004808.wzhqqytmrri72flq%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Change default usb qube

On Thu, Jan 11, 2018 at 05:03:22PM -0600, Sven Semmler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 01/10/2018 04:10 AM, 'Blacklight447' via qubes-users wrote:
> > I recently installed qubes on my new laptop, but i think i 
> > accidently ticked the box which configure qubes to use sysnet as
> > usb qube, does someone know i can revert this and usb a normal usb
> > qube instead?
> 
> I didn't try this right now, but based on previous experience I would
> suggest the following sequence should work:
> 
> 1. shutdown all qubes
> 
> 2. use qubes manager to remove all your USB controllers from sys-net
> 
> 3. dom0: check /etc/qubes-rpc/policy/qubes.InputKeyboard and
> /etc/qubes-rpc/policy/qubes.InputMouse and rename any mention of
> "sys-net" into "sys-usb"
> 
> 4. dom0: sudo qubesctl top.enable qvm.sys-usb
> 
> 5. dom0: sudo qubesctl state.highstate
> 
> That should be all!
> 
> /Sven
> 

It isn't necessary to shutdown all qubes, if you want to shutdown
sys-net.
If you are connected through sys-firewall or similar, then it is
sufficient to set the netvm of sys-firewall to none. Then close down
sys-net, remove the USB controllers, and start it up again.
Once started re-attach the fw/vpn/directly attached qubes.

Note that you may not be able to start sys-usb with the newly attached
USB controllers.  This is a security feature. If you come up against it,
then the simplest thing to do is to reboot. When Qubes restart you should
find the controllers attached to sys-usb.

unman

-- 
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/20180112002537.6danplt6lg3722hz%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/11/2018 07:15 AM, 'Blacklight447' via qubes-users wrote:
> This issue described the lack of documentation how to multiboot 
> qubes. I have decided that i will be writing it, but as described
> in the issue above, I need some user feedback.

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

/Sven

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpX+EIACgkQ2m4We49U
H7ZHsxAAiJF1z3NQ8MCRV1+kR7lWgIhp3/xGLoULoYAEgV24/apAKm5b7IEHmD2e
GBgoa1Nij2mIIrfqNNj8cIe9548tqLOAa4oaDGqQtI6u3MH3AgkBRgenvOtRCaKu
lWxAERCgC02LpAQx+pBMAcHH1WrT8i9twCeXhUSTxfYwRmC2PHSRXtrT+ttpv7XR
afFeSrybU6whRVvYjVySfJks8P7KImvaToVEZPsFbFIjKum8MGh4h+xmAysGyNhj
34Bxo3g+9eyWU03cCNcROQq0Mi/zuxQM9p3ydkahStJjD5FFRafha0TiyJIXXh7H
y5irTk+CxZ972Qq5ixq0I/MBw+nKk/uJEnRPra2E7SxPSZpKkjhvH6mWBPqtoDYo
U8VKCRIrcqTJLX2HPvQO69Z4o7Uzgkhjrzt2XbkbBpbp0Akh7Pwo2nFPOz94tW6+
o88ebhbB8QJSUzcjZ8JZOh+NQ6cH/7lPDRSkXuc+ZvNVw5GV5qka4dkTEmZAGMoI
9KVkGyDrbM5MHm0TkGVOvVa/vKioIrF9na9b4P5al+m3tHK/M8fiJuJ9AIrlXQIK
tBzLiuyfkrZalna7Zbp+NfZ8SctIXb+h4ikreiYPbrOkyib7/+V0YULllKugH/6T
PqS5Hgll8SvKQ6ikwnc582EeOqIkUjtwM7e2afcrvob96ayzX/s=
=hgxO
-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/37e53df9-d7c0-bc60-c1a1-50390560c04e%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Change default usb qube

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/10/2018 04:10 AM, 'Blacklight447' via qubes-users wrote:
> I recently installed qubes on my new laptop, but i think i 
> accidently ticked the box which configure qubes to use sysnet as
> usb qube, does someone know i can revert this and usb a normal usb
> qube instead?

I didn't try this right now, but based on previous experience I would
suggest the following sequence should work:

1. shutdown all qubes

2. use qubes manager to remove all your USB controllers from sys-net

3. dom0: check /etc/qubes-rpc/policy/qubes.InputKeyboard and
/etc/qubes-rpc/policy/qubes.InputMouse and rename any mention of
"sys-net" into "sys-usb"

4. dom0: sudo qubesctl top.enable qvm.sys-usb

5. dom0: sudo qubesctl state.highstate

That should be all!

/Sven


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpX7TkACgkQ2m4We49U
H7bv5RAAj5AoJjTShkFHribPSryZowXx9h2wtFCcsumjh0jB6P0QE0QL0h/+L/oT
iuxbhjkWX+Dz0mmBPAifR2iMex5hRXEiaHTFoHAXqdnJkn2VpI5Fi7G8opU6A3j1
9qgOkTjVV+IyuT/8xui8+4GJRyURpbDiTv4B704deUr3MuM5EjKKqt9fuQF1qpPv
Rhq7ZhDUuN2E3t9esEPbXfQK6johu1r0BdMYggE1MuSR/yOnHF/jUfQ/mBsMYTn+
Brb5YjbJfV83+N1jtW9ZdsoADFbxQaV/6NSb0oky6xMqOR3m0VrmFQhkOdlS9rY5
fcv6H5pIA0HUjpmqspR4hZ7wvLSFTVYS3bjSxMCueb8vOUJ2ZCW4OWVIRCmUMnqk
iaun1Xn0j9F3pHjl/s8/dcpBv7IA2c83+sQXcgVT06RhMsyrqBBaXMk8FTrSfxGZ
9ra0yL+uaVf+rY73KmlmHlaVsmNX/oibpDo4gjoMQb667xbC+TFBC8iMotW0UONi
IOkKRlRQolF2zgHV/iL0lNsGEmtyjpOmt3JVqnfGSHumv2UmdoXg3mbJYJB/zAB8
Bb9rsyJ2zdIa7R4UvrsZvbNIGf2M/s2g5SEQ4l73aBeGUde+814YBlIPHElcd8It
jHcunq4nAdp5dmfzwGwljUNZlPO6ZGh9KByFpglCksAYQd0v9fk=
=zzyL
-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/c2d5daf6-099c-bacf-60b6-dfe68fe38130%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

On Thursday, 11 January 2018 18:16:04 GMT Unman wrote:
> On the VPN case your own comment confirms that it would be better to
> provide a separate section, rather than trying to put "exceptions" in to
> the existing text.

Thank you for explaining that unman, much clearer indeed.

While I agree on the general statement above, I feel its not the best 
solution in this case where 4.0 have massive changes in all layers of the 
technology.
In many cases the about half of the text will be duplicated between the 3.2 
and the 4.x sections, albeit with major changes.
This will not help the reader much.
More importantly, I fear that the new users (potential contributors) that 
have not used 3.2 will have a hard time deciding what to do with information 
that clearly doesn't represent the current state of technology.

Asking people to put a lot of effort into reformatting documentation that 
may or may not actually be useful to anyone using an older version is a big 
ask in a volunteer project.

I personally prefer the solution where a git repo is cloned for 3.2 as 
"legacy" which is then attached to the website under a subdirectory and 
people can edit that for maintainance and fixes.
  http://qubes-os.org/doc/3/ 
or somesuch.

The majority of changes would then be in the 'master' branch which people 
can edit and they can add references to the github issues concerning known 
bugs. We can mark known issues with the pages like the VPN one I described 
and people reading the docs will actually be aware of pitt-falls.

In my opinion there is only one thing worse than no documentation, it is 
official looking documentation that is wrong.

> Also, that once 3.0 is retired, it will be simple to remove the 3.0
> relevant material, rather than filleting our bits from each page.

This would be even better, if qubes ever wants to they can just remove the 
subrepository.

What do others think?
-- 
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/11311960.j3zXc7upma%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

On Thu, January 11, 2018 9:03 pm, pa...@kc.pl wrote:
> On Thursday, 11 January 2018 21:58:32 UTC+1, awokd  wrote:
>
>
>> You can run qvm-backup from the command line. I thought there was a way
>> to start the GUI one too but am not finding it.
>
> I have no qvm* commands available. Nor qubes-dom0-*.
> Probably I can't also attach any external device at this point.
>
>
> I have only qubesctl command and qubesdb-* commands available.

Sorry then, no idea how that would have happened. You can maybe copy out
the VMs' image files directly from /var/lib/qubes/appvms and mount them
after repairing your install to recover the contents.

-- 
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/6ab97da0645c86c0b51331c2ba9c4b8d.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] live Distro

2018-01-11 Thread Steve Coleman

On 01/11/2018 01:35 PM, Unman wrote:

I failed miserably to get anything running for 4.0-rc2, so that target
has shifted now.

I should be posting updated 3.2 images in the next few days.

unman,

Given your difficulty in getting 4.0-rc2 to run, what is the possibility
of creating a DVD that merely checks the system for the proper BIOS,
chipset, and other features needed to support a full 4.0 system?

It seems to me that with the tightening constraints slated for 4.0, just
having a way to do a quick test of the system hardware before installing
would be a wonderful tool for the community at large. If one could
simply boot from a DVD and get some kind of a HCL report, of what
"necessary" vs desired features needed to support 4.0 that did not work,
then that could potentially save many people grief from wiping a working
system only to find out their hardware will not adequately support it.

If booting your DVD works as a test before upgrade this would be a
really good thing to have. Please do keep us advised as to your progress
on the 4.0 system capability. Having that as a tool would be awesome.

thanks,

Steve

unman

--
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/088472ca-2b27-ce01-29f6-dcb735b12c2d%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

2018-01-11 Thread Pawel G

On Wednesday, 10 January 2018 18:13:37 UTC+1, Pawel G  wrote:
> I upgraded dom0 from fedora-24 to fedora-25 on Qubes r3.2. 
> 
> After reboot, I can login, GUI starts, I'm able to open dom0 Terminal window 
> etc. but Qubes Manager is not running, I can't start VMs:
> 
> "Failed to execute child process "qvm-run" (No such file or directory)."
> 
> 
> "journaltcl | grep Fail" shows:
> 
> "Failed to start Qubes DB agent", and
> "Failed to start Virtualzation daemon".
> 
> I tried to restart qubesd (not sure if it's related), but it says that:
> 
> "Failed to restart qubesd.service: Unit qubesd.service failed to load: No 
> such file or directory".
> 
> I can't find any related thread to my problem (here and issues on github). 
> 
> Any help would be highly appreciated as I'm smart but unfortunately not too 
> bright. I have no idea how to diagnose this problem and how to make my Qubes 
> works again. 
> 
> Thanks!
> 
> Pawel

I found out some more information regarding qubes-db-dom0.service failure:

symlink /var/run/qub es/qubesdb.sock: No such file or directory
FATAL: server socket initialization failed
qubes-db-dom0.service: Main process exited, code=exited, status=1/FAILURE
Failed to start Qubes DB agent.


-- 
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/0b6eb3c6-d4d6-4ebc-8a3d-072e3b0ea717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

2018-01-11 Thread pawel

On Thursday, 11 January 2018 21:58:32 UTC+1, awokd  wrote:

> You can run qvm-backup from the command line. I thought there was a way to
> start the GUI one too but am not finding it.

I have no qvm* commands available. Nor qubes-dom0-*.
Probably I can't also attach any external device at this point.

I have only qubesctl command and qubesdb-* commands available.

 

-- 
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/e096d68d-8fc5-46a1-bf01-2033fe09ba61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

On 01/10/2018 03:47 PM, Connor Page wrote:
> The official templates use nftables so shouldn’t be mixed with iptables. I 
> didn’t have time to learn about nftables, so just removed nftables package 
> from debian 9 template. YMMV.
> 

Hmmm, I was just thinking how Qubes' own guest scripts still use
iptables even in fedora-26.

IIUC, iptables and nft are two different interfaces to netfilter. I
don't know if it really matters, at least for the R4.0 window. I'd
prefer to put the syntax change (for docs) off until a later release.


-- 

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/3ff66d44-d508-db8a-92cc-afaa16940560%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

On Thu, January 11, 2018 8:49 pm, Pawel G wrote:
> On Thursday, 11 January 2018 21:12:22 UTC+1, awokd  wrote:
>
>
>> If you back up the VMs first, you can reinstall then restore the VMs.
>> In
>> 3.2, go to Qubes VM Manager, then System menu, and choose Backup. Best
>> if you can do this to an external drive so the backups don't get wiped
>> by mistake on the install!
>
> Is this the only way? No recovery mode? :) Qubes VM Manager is not
> running unfortunetly, so no go for me.

You can run qvm-backup from the command line. I thought there was a way to
start the GUI one too but am not finding it.


-- 
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/52cef5d38984e014dffa22387918afb3.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

2018-01-11 Thread Pawel G

On Thursday, 11 January 2018 21:12:22 UTC+1, awokd  wrote:

> If you back up the VMs first, you can reinstall then restore the VMs. In
> 3.2, go to Qubes VM Manager, then System menu, and choose Backup. Best if
> you can do this to an external drive so the backups don't get wiped by
> mistake on the install!

Is this the only way? No recovery mode? :) Qubes VM Manager is not running 
unfortunetly, so no go for me.



-- 
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/58a39e1a-a74a-4e28-8a5d-69555f49f884%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

On 01/11/2018 01:16 PM, Unman wrote:
> On Thu, Jan 11, 2018 at 09:18:46AM +, 'Tom Zander' via qubes-users wrote:
>> On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote:
>>> On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote:
>>
 I poked the Qubes guys about providing a separate dir on the website to
 make it clear what is 3.x and what is 4.x specific, but they stated we
 should instead put notices about exceptions in the document pages.
>>>
>>> That's not exactly right. Please see:
>> ..
>>>
>>> In other words, do not just add notices in the text about exceptions.
>>> Instead, make clearly-labeled sections for 3.x and 4.x so that users
>>> can easily find the right information no matter which version of Qubes
>>> they're using.
>>>
 So I guess things like ProxyVMs should be mentioned to be old and AppVM
 is the new.
>>
>> Ok, I am having problem seeing your solution and my explanation of it as any 
>> different, in practice.
>> Maybe I'm missing the obvious, I'm just not seeing it.
>>
>> In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/
>> * in v.4 there is no "NetVM".
>> * There is no "ProxyVM"
>> * The create qubes screenshot is considerably different.
>> * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK).
>> * does not use iptables anymore.
>>
>> Ok, going to stop now.  I got to half the page and some 80% of the text and 
>> screenshots are wrong for v4.
>>
>> How would you solve that in line with the QubesOS policy?
> 
> The difference is between this style:
> 
> You can attach a disk image to a qube using qvm-block :
> qvm-block -A  [qube:] 
> (This syntax is not available in 4.0)
> 
> and this:
> 3.0
> You can attach a disk image to a qube using qvm-block :
> qvm-block -A  [qube:] 
> 
> 4.0
> You cannot attach a disk image to a qube using qvm-block.
> 
> 
> The advantage of using labelled sections is that it should be easier
> for users to find the material relevant to the version they are using.
> Also, that once 3.0 is retired, it will be simple to remove the 3.0
> relevant material, rather than filleting our bits from each page.
> 
> On the VPN case your own comment confirms that it would be better to
> provide a separate section, rather than trying to put "exceptions" in to
> the existing text.
> 

At least no section repetition for the scripts should be necessary. But
doing this for the dialogs still adds a lot to an already long doc.

I feel that, apart from making some docs look deceptively long and less
readable, the most significant downside to melding 3.x/4.x instructions
together would be to discourage contributions from users. It makes the
thought of every potential edit seem like a slog through extra markdown,
and many will think "I don't have time to install 3.2 to write up that
version".

-- 

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/c01a27b7-4f52-1764-9e26-ed0c0721832d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

On Thu, January 11, 2018 7:37 pm, Pawel G wrote:

> I upgraded dom0 (following "Installing and using Windows-based AppVMs"
> doc):
>
>
> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
> qubes-windows-tools
>
> and not long after that I upgraded all my VMs from f-24 to f-25.

OK, that's different, that should be fine. dom0 is still on f-24 then,
just your VMs are upgraded.

>
> I use my laptop for a few weeks puting it into hibernation mode. After
> restart - you know the story. I haven't found anything in bash_history
> what would damage qubes, aside from those updates.

I don't know what could have broken your QubesDB then, unless maybe you
ran just "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing"
at some point? That would have upgraded Xen and everything except the VMs
to the testing repo, which is not always stable.

> Is it possible to reinstall base system and have my VMs and data not
> earased (like from ISO installer)?

If you back up the VMs first, you can reinstall then restore the VMs. In
3.2, go to Qubes VM Manager, then System menu, and choose Backup. Best if
you can do this to an external drive so the backups don't get wiped by
mistake on the install!

-- 
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/2d445e8d9d4eba66e0f617acc25bb6a7.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: About wifi troubleshooting (Qubes R3.2)

On Tuesday, January 9, 2018 at 7:50:04 PM UTC-5, brutelle...@gmail.com wrote:
> I was wondering if the wifi modules blacklisting fix should only be 
> implemented on sys-net to work properly, or systematically to all VMs in 
> addition to sys-net ?
> 
> This fix seemed to work for some time, but I often get these times when the 
> wifi seems to be working, but is actually out, no matter how many restarts, 
> unloads and reloads or devices and so on...
> 
> Suggestions welcome !
> 
> PS: I'm running Qubes on a lenovo X220 if it helps

not sure what you mean,  but I wouldn't think all vms.  Just the templatevm if 
anything else.

What fix exactly are you talking about and how are you implementing it?

-- 
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/80e434ff-a834-4f8e-9be4-d37cbe2a6b75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Change Inter-VM Copy/Paste Shortcut?

On Saturday, June 25, 2016 at 6:57:40 AM UTC-4, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sat, Jun 25, 2016 at 11:52:08AM +0200, Niels Kobschaetzki wrote:
> > On 16/06/25 10:59, Markus Kilås wrote:
> > > Any chance the defaults could be changed in a future version?
> > > Having defaults working well for most people could have a value and make
> > > it easier for new users even if it is possible to customize at will.
> 
> No, we're not going to change the default at this stage. The current one
> works for almost every Qubes user, for years.
> 
> - -- 
> 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-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJXbmObAAoJENuP0xzK19cs/48H/jaRSoRuXTqBRLVztmXPQhZG
> 6dkQPSIz5C8UtdNpXiT3frYLVeIYnGSVw9xSvlqLKVN3QQhvCfvKH4BbRn3khBw/
> bpmRLNDfHc7OhKMH+nbXz0ABJRBYO0bWL6zbuwWdfxM1QTIvA0bHTkXIjrsXN5Hj
> 4I2zXozSsyl0PUlVKD0JqbhViNjGVrDrdpRVFV/UWEuRH6lXA4dEVB6TVMfKFfaY
> lGxeO4l6XqBZNrMvWz6sFNC1MlNnmHFDA0RCxIRKnFF0axFSJwhvcyLrXd5YCeFb
> HRVatHN5rXMSD0/SqWHPkH5d0yYGCI7q2k70eaKIIDgNIBQEhI+vqeWBMogImq0=
> =n8VH
> -END PGP SIGNATURE---

was just about to post,  tk goodness...lol

-- 
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/a15c4092-acc0-4e4d-8afa-9dbab77d1e33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2018-01-11 Thread 'Blacklight447' via qubes-users

Thats ofcourse an option to, all ideas and input are welcome.

Also cooloutac, believe me, I will make sure to put some big warning at the 
beginning to advise against this, and inform them of the dangers.

-- 
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/eu0LAh3c-C_-kFKNnUx3JTRVLjUDiUqCswbOEITLlUC6ZqnNVXnCdsaHvYUFSKET1c7NUbo6J3evDIma84DMgOdqiKKYYAYpKfbKJZFdVpk%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Failed to start Qubes DB agent after upgrade fedora 24 to 25 (r3.2)

2018-01-11 Thread Pawel G

On Wednesday, 10 January 2018 23:30:42 UTC+1, awokd  wrote:
> On Wed, January 10, 2018 5:13 pm, Pawel G wrote:
> > I upgraded dom0 from fedora-24 to fedora-25 on Qubes r3.2.
> 
> Well there's the problem! :) Ordinarily, you should not upgrade dom0.

Sorry for misunderstanding, I figured out what I did analysing my bash_history 
file (as I was sure that I haven't experimenting, just followed docummentation):

I upgraded dom0 (following "Installing and using Windows-based AppVMs" doc):

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
qubes-windows-tools 

and not long after that I upgraded all my VMs from f-24 to f-25. 

I use my laptop for a few weeks puting it into hibernation mode. After restart 
- you know the story. I haven't found anything in bash_history what would 
damage qubes, aside from those updates.

Is it possible to reinstall base system and have my VMs and data not earased 
(like from ISO installer)?

Thanks.

-- 
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/a0da733b-02cf-4605-84d8-c26993fcf5f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

On Thu, Jan 11, 2018 at 08:15:32AM -0500, 'Blacklight447' via qubes-users wrote:
> Hello Qubes users,
> 
> A while ago, a issue was raised on the Qubes github issue page: 
> https://github.com/QubesOS/qubes-issues/issues/3373
> This issue described the lack of documentation how to multiboot qubes. I have 
> decided that i will be writing it, but as described in the issue above, I 
> need some user feedback.
> 
> The main part is that I want to know what documentation users expect. I can 
> imagene the following layouts:
> 
> Option number 1 would be to write a paragraph about a specific OS(for 
> example, Windows). And then describe on how to add both a efi and/or bios 
> entry for windows in GRUB.
> 
> Option 2 would be to split the page in two halves, one paragraph describing 
> the process for all OS's with EFI and one paragraph describing the BIOS 
> option.
> 
> Further more i would like to know which OS's are wanted in the documebtation. 
> Does it have to be only windows and linux? Or also more rare systems like 
> *BSD's.
> How would you, as a user, as a user, expect to see this documentation.
> 
> Friendly greetings,
> Blacklight

I'd favour an option 3:
Split the page by UEFI/BIOS , and in each section give examples for
Windows and Linux.

There's a real difficulty in pitching it between "do this" and "learn
this". I'd say that the questions that come up either show that users
read but did not understand what is there now, or didn't read it at all.
(Of course, there could be many users who read, understood and did, and
never posted here.)

-- 
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/2018085225.iopd4nza727sthue%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] live Distro

On Sun, Jan 07, 2018 at 04:31:18PM -0800, Leo Reitano wrote:
> Hi all,
> I would love to know if is possible to use Qube as live distro on a usb or a 
> dvd and what is the procedure step by step
> 
> Moreover what is the release stage? alpha, beta? 
> 
> Thanks
> 
> Leo
> 

Yes - see here:
https://groups.google.com/forum/#!topic/qubes-users/kcB3BTNKny0

Those images run off DVD or USB.I know a number of people use the Tor
version extensively.
(Incidentally, you can run these images in Qubes, booting from the disk
image, if you just want to explore.)

I failed miserably to get anything running for 4.0-rc2, so that target
has shifted now.

I should be posting updated 3.2 images in the next few days.

unman

-- 
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/2018083528.wqz54f2enzqjkicx%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

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

2018-01-11 Thread Achim Patzner

On 11.01.2018 14:58:34, "Vít Šesták" 
 
wrote:


Qubes is a desktop OS*, so it does not make much sense to target ARM 
servers.


My current workstation is an Intel server system. What's wrong with that 
(besides the noise so the system is not exactly besides my desk)? I 
would definitely like using ARM-based (or POWER-based) systems instead 
just to throw a few bird droppings on Intel's heads.


Remember: Today the classification "server" does not mean "high I/O 
load-capable machine" but "very expensive system" the common user would 
not buy but is nice to have (as in Mac Pro with two 18-core CPUs and a 
metric shitload of memory -- on which booting Qubes is an adventure).



Achim

--
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/em9f53854b-e221-42bd-b337-05a4b0acc928%40sir-face.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3

On Thu, Jan 11, 2018 at 09:18:46AM +, 'Tom Zander' via qubes-users wrote:
> On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote:
> > On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote:
> 
> > > I poked the Qubes guys about providing a separate dir on the website to
> > > make it clear what is 3.x and what is 4.x specific, but they stated we
> > > should instead put notices about exceptions in the document pages.
> > 
> > That's not exactly right. Please see:
> ..
> > 
> > In other words, do not just add notices in the text about exceptions.
> > Instead, make clearly-labeled sections for 3.x and 4.x so that users
> > can easily find the right information no matter which version of Qubes
> > they're using.
> > 
> > > So I guess things like ProxyVMs should be mentioned to be old and AppVM
> > > is the new.
> 
> Ok, I am having problem seeing your solution and my explanation of it as any 
> different, in practice.
> Maybe I'm missing the obvious, I'm just not seeing it.
> 
> In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/
> * in v.4 there is no "NetVM".
> * There is no "ProxyVM"
> * The create qubes screenshot is considerably different.
> * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK).
> * does not use iptables anymore.
> 
> Ok, going to stop now.  I got to half the page and some 80% of the text and 
> screenshots are wrong for v4.
> 
> How would you solve that in line with the QubesOS policy?

The difference is between this style:

You can attach a disk image to a qube using qvm-block :
qvm-block -A  [qube:] 
(This syntax is not available in 4.0)

and this:
3.0
You can attach a disk image to a qube using qvm-block :
qvm-block -A  [qube:] 

4.0
You cannot attach a disk image to a qube using qvm-block.


The advantage of using labelled sections is that it should be easier
for users to find the material relevant to the version they are using.
Also, that once 3.0 is retired, it will be simple to remove the 3.0
relevant material, rather than filleting our bits from each page.

On the VPN case your own comment confirms that it would be better to
provide a separate section, rather than trying to put "exceptions" in to
the existing text.

-- 
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/2018081604.kpydxfvgvn636xqw%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: memory management in dom0 ?

On Thursday, 11 January 2018 14:07:57 GMT Vít Šesták wrote:
> For your case, I have few questions:
> 
> * What's dom0 swap usage? Qmemman includes this amount in memory
> requirements. 

My dom0 has no swap, I didn't disable it, it just never had any.
I guess thats because in the installer I didn't assign any swap partition.

> * Where does your “1.3 GB is in use” claim come from?

 Top :)
The "in use" is what top claims. Add the "buff/cache" amount (1MB) to it and 
the "free" amount (1.6MB) and I do get to the total reported in both top and 
xentop.

> * How much of memory does the AppVM use? 

I looked at it at the time I got repeated crashes, it had some 800MB 
assigned to it.

> What is the memory limit for the
> AppVM? See VM settings » Advanced » Initial memory.
The settings are 1GB initial and 4GB max.

I "solved" it by closing some VMs and my chromium got more space assigned.

-

The qmemman has some more room for growth.
For instance I have one "Work" VM where I compile C++ code. I assigned it 
16GB of memory and then qmemman came and only gave me 2GB.
I start a compile (8 cores times 0.6GB of mem used) and maybe 10 seconds 
later I get out-of-memory issues.
To my annoyance xentop shows me that there is still >10 GB free, 
unallocated. For some reason it just doesn't seem to allow growth of memory 
fast enough, regardless of my settings.
I "solved" that by turning off memory management for that VM and just 
setting it to 12GB always :(

-- 
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/1851645.2lrfOOeRYL%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] memory management in dom0 ?

On 01/11/2018 08:45 AM, 'Tom Zander' via qubes-users wrote:
> I understand that there is a memory-manager to balance the memory between VM 
> spaces.
> Does anyone know if dom0 is being managed this way?
> 
> Currently there is 4GB assigned to dom0, of which 1.3 GB is in use.
> At the same time I have chromium getting out-of-memory errors in an AppVM.
> I'd like to actually use that 2½GB that dom0 now claims but doesn't use, 
> anyone got ideas how?
> 
> Thanks!

There is a memory balancing bug in the R4 pre-release:

https://github.com/QubesOS/qubes-issues/issues/created_by/tasket

A workaround is to restart the qubes-qmemman.service periodically
(sometimes I need to do this every 5min or so).

I have also restricted dom0's max memory to help the situation. The
permanent setting for this is 'dom0_mem=max:' in /etc/default/grub,
which propagates to /boot/grub2/grub.cfg on the lines beginning with
'multiboot /xen'. Its currently at 1800M on this system and can probably
go lower.

-- 

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/30ebe4fa-cc65-5d30-1dcc-74f23d6b8430%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

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

2018-01-11 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack
(qubes-secpack).

View QSB #37 in the qubes-secpack:



Learn about the qubes-secpack, including how to obtain, verify, and
read it:



View all past QSBs:



View XSA-254 in the XSA Tracker:



```
 ---===[ Qubes Security Bulletin #37 ]===---

   January 11, 2018


Information leaks due to processor speculative execution bugs

Summary


On the night of January 3, two independent groups of researchers
announced the results of their months-long work into abusing modern
processors' so-called speculative mode to leak secrets from the system's
privileged memory [1][2][3][4]. As a response, the Xen Security Team
published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
previously share information about these problems via their (non-public)
security pre-disclosure list, of which the Qubes Security Team is a
member.

In the limited time we've had to analyze the issue, we've come to the
following conclusions about the practical impact on Qubes OS users and
possible remedies. We'll also share a plan to address the issues in a
more systematic way in the coming weeks.

Practical impact and limiting factors for Qubes users
==

## Fully virtualized VMs offer significant protection against Meltdown

Meltdown, the most reliable attack of the three discussed, cannot be
exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
matter whether the _target_ VM (i.e. the one from which the attacker
wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
para-virtualized (PV) by default, though users can choose to create
fully-virtualized VMs.  PV VMs do not protect against the Meltdown
attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
and thus offer protection. However, the fully-virtualized VMs in Qubes
3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
"stub domains", making it possible for an attacker who can chain another
exploit for qemu to attempt the Meltdown attack.

## Virtualization makes at least one variant of Spectre seem difficult

Of the two Spectre variants, it _seems_ that at least one of them might
be significantly harder to exploit under Xen than under monolithic
systems because there are significantly fewer options for the attacker
to interact with the hypervisor.

## All attacks are read-only

It's important to stress that these attacks allow only _reading_ memory,
not modifying it. This means that an attacker cannot use Spectre or
Meltdown to plant any backdoors or otherwise compromise the system in
any persistent way.  Thanks to the Qubes OS template mechanism, which is
used by default for all user and system qubes (AppVMs and ServiceVMs),
simply restarting a VM should bring it back to a good known state for
most attacks, wiping out the potential attacking code in the
TemplateBasedVM (unless an attacker found a way to put triggers within
the user's home directory; please see [8] for more discussion).

## Only running VMs are vulnerable

Since Qubes OS is a memory-hungry system, it seems that an attacker
would only be able to steal secrets from VMs running concurrently with
the attacking VM. This is because any pages from shutdown VMs will
typically very quickly get allocated to other, running VMs and get wiped
as part of this procedure.

## PGP and other cryptographic keys are at risk

For VMs that happen to be running concurrently with the attacking VM, it
seems possible that these attacks might allow the attacker to steal
cryptographic keys, including private PGP keys.

## Disk encryption and screenlocker passwords are at risk

There is one VM that is always running concurrently with other VMs: the
AdminVM (dom0). This VM contains at least two important user secrets:

 - The disk (LUKS) encryption key (and likely the passphrase)
 - The screenlocker passphrase

In order to make use of these secrets, however, the attacker would have
to conduct a physical attack on the user's computer (e.g. steal the
laptop physically). Users who use the same passphrase to encrypt their
backups may also be affected.

Additional remedies available to Qubes users
=

Thanks to the explicit Qubes partitioning model, it should be
straightforward for users to implement additional hygiene by ensuring
that, whenever less trusted VMs are running, highly sensitive VMs are
shut down.

[qubes-users] Re: memory management in dom0 ?

2018-01-11 Thread Vít Šesták

Yes, there is qmemman. I hope this is relatively up-to-date: 
https://www.qubes-os.org/doc/qmemman/ .

It should manage dom0 memory as well. By default, it assigns 1 GiB – 4 GiB of 
RAM to dom0.

For your case, I have few questions:

* What's dom0 swap usage? Qmemman includes this amount in memory requirements.
* Where does your “1.3 GB is in use” claim come from?
* How much of memory does the AppVM use? What is the memory limit for the 
AppVM? See VM settings » Advanced » Initial memory.

Regards,
Vít Šesták 'v6ak'

-- 
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/c8fe7ea6-ad0c-4590-bed8-d5183c863309%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2018-01-11 Thread Vít Šesták

Qubes is a desktop OS*, so it does not make much sense to target ARM servers.

*) I remember this has been emphasized by its authors somewhere. Of course, you 
can use it on server, but it if far from the intended usage.

-- 
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/a9c52a03-1c89-431d-99f3-c3b5c0b54a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] memory management in dom0 ?

I understand that there is a memory-manager to balance the memory between VM 
spaces.
Does anyone know if dom0 is being managed this way?

Currently there is 4GB assigned to dom0, of which 1.3 GB is in use.
At the same time I have chromium getting out-of-memory errors in an AppVM.
I'd like to actually use that 2½GB that dom0 now claims but doesn't use, 
anyone got ideas how?

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/1525819.gA7xBjyaEC%40mail.
For more options, visit https://groups.google.com/d/optout.

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

2018-01-11 Thread 'Blacklight447' via qubes-users

Hello Qubes users,

A while ago, a issue was raised on the Qubes github issue page:
https://github.com/QubesOS/qubes-issues/issues/3373
This issue described the lack of documentation how to multiboot qubes. I have
decided that i will be writing it, but as described in the issue above, I need
some user feedback.

The main part is that I want to know what documentation users expect. I can
imagene the following layouts:

Option number 1 would be to write a paragraph about a specific OS(for example,
Windows). And then describe on how to add both a efi and/or bios entry for
windows in GRUB.

Option 2 would be to split the page in two halves, one paragraph describing the
process for all OS's with EFI and one paragraph describing the BIOS option.

Further more i would like to know which OS's are wanted in the documebtation.
Does it have to be only windows and linux? Or also more rare systems like
*BSD's.
How would you, as a user, as a user, expect to see this documentation.

Friendly greetings,
Blacklight

--
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/Y8AbTN0_yx3bLXkvsRwjXoGVnvhuX5AqBwBV4UmhhcgqUgqb1nmJepVThofAs24ro5F7lKk2dBjiUAibEDqjm3s1kau1HGDOpS7Zd4uE5_E%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Upgrading directly from Fedora 23 to 26 ?

On Thursday, 11 January 2018 06:39:02 GMT brutellealexan...@gmail.com wrote:
> I don't seem to be able to download the 26 template either... It says all
> mirrors have been used and it fails.

This is definitely the direction you want to go, download the template from 
dom0 using
sudo qubes-dom0-update qubes-template-fedora-26

after it installed the new template, you should start a terminal in iit and 
run the following inside of that template;
   sudo yum upgrade --best --allowerasing


more info;
https://www.qubes-os.org/news/2018/01/06/fedora-26-upgrade/

If that faiils, please specify what you did and how it failed, this avoids 
guessing on our side :)

-- 
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/2669430.f8Qn7f0c1A%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Looking for a Qubes enthusiast in the Baar / Zug area of Switzerland

On Thu, January 11, 2018 10:42 am, Others call me jean wrote:
> Maybe it is because public.gmane.org can't receive mails? I had some
> time ago this error message:
>
> "Host or domain name not found. Name service error for
> name=public.gmane.org type=: Host found but no data record of requested
> type"
>
>
> On 01/10/2018 02:31 PM,
> mbaarc...@gmail.com wrote:
>> Hi Qubes Community,
>>
>>
>> I have not received even one notice of interest. Can it really be that
>> here in "Crypto Valley", there are no security and privacy concerned
>> enthusiasts who has some spare time and need some cash for spare
>> expenses whilst doing some interesting and independent work ..?
>>
>> I obviously don't want to force anyone's hand, but any input towards
>> someone who could fill this role will be highly appreciated.
>>

Looks like he has a gmail address? Too bad it's too far away for me, looks
like a fun exercise.

-- 
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/0b7c889dc6ec075dbc055837e32fc51f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Looking for a Qubes enthusiast in the Baar / Zug area of Switzerland

2018-01-11 Thread Others call me jean

Maybe it is because public.gmane.org can't receive mails? I had some
time ago this error message:

"Host or domain name not found. Name service error for
name=public.gmane.org type=: Host found but no data record of
requested type"


On 01/10/2018 02:31 PM,
mbaarc...@gmail.com wrote:
> Hi Qubes Community,
> 
> I have not received even one notice of interest. Can it really be that here 
> in "Crypto Valley", there are no security and privacy concerned enthusiasts 
> who has some spare time and need some cash for spare expenses whilst doing 
> some interesting and independent work ..?
> 
> I obviously don't want to force anyone's hand, but any input towards someone 
> who could fill this role will be highly appreciated.
> 
> Best regards Mogens
> 


-- 
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/p37eus%24tfg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

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/146a0b5a37d23bd75acdbfb45d455455.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] validate IOMMU support

2018-01-11 Thread Wim Vervoorn

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?

Best regards,

Wim Vervoorn



-- 
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/d35313c4f9dc418f824db307aa92f975%40Eltsrv03.Eltan.local.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3