[qubes-devel] broken dom0 updates, shall I report this at qubes-issues?

[Demi M. Obenour]

On 3/19/21 4:07 PM, Sven Semmler wrote:
> On 3/19/21 2:03 PM, Marek Marczykowski-Górecki wrote:
>> Are you sure you don't have security-testing or current-testing
>> enabled? Those packages are currently only there.
> 
> I had it enabled once to see which packages would update, but did not say yes 
> ... so they might have been cached in the updatevm?
> 
>> You can retry with `qubes-dom0-update --refresh`
> 
> That tells me "Command line error: no such option: --refresh"
> 
> I am actually fine with enabling security-testing, I just said "no" because 
> the dependency errors scared me. When I try again now, I still see the 
> errors. Either the dependencies or with the additional parameters the warning 
> that something critical will be removed.
> 
> Is there another way I can force a --refresh? ... should I just wait?

‘qubes-dom0-update --clean’ should work.

> Since this is the devel list and this not a bug but something I did, shall I 
> take it to qubes-users?
> 
> Sorry for the noise.
> 
> /Sven

Sincerely,

Demi Marie Obenour
she/her/hers
QubesOS Developer, Invisible Things Lab

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d82d8e74-30d5-986a-e5ee-5e839a95ed84%40invisiblethingslab.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal

[Demi M. Obenour]

On 2/17/21 7:27 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Dec 28, 2020 at 11:50:56AM +0100, Giulio wrote:
>> Hello everybody, although I understand it's a bit early, I've got a
>> project idea for the 2021 GSoC. I plan to also apply to it as a student
>> if it gets reviewed and approved, but that of course will come later.
> 
>> # Qubes GSoC 2021: Simplified external port forwarding and automatic NAT
>> traversal
>> ## Introduction
>> Forwarding ports to Qubes VM is currently possible only though a multi
>> step, error prone, manual process that also requires writing custom
>> configuration in order to survive between reboots.
>> Things as simple as starting a webserver or netcat for lan file sharing
>> can be eventually a troublesome and time-wasting process[1][2].
> 
> Since some time there is an easier way:
> https://www.qubes-os.org/doc/firewall/#opening-a-single-tcp-port-to-other-network-isolated-qube
> 
> It isn't fully automatic, but _much_ easier than manual iptables rules.
> 
>> Furthermore, applications that rely on NAT traversal protocols such as
>> those for audio and video communications do not work in direct P2P mode
>> with STUN and always use TURN instead[3].
> 
>> ## Project goals
>> Implement a GUI for automatic and persistent, eventually with a
>> predefined timespan (ie: until reboot), port forwarding. The idea is to
>> split horizontally the "Firewall Rules" tab in the "Qubes Settings"
>> window and add another area below it. Add a checkbox to enable NAT
>> traversal requests. When the checkbox is selected, the FirwallVM will
>> redirect NAT traversal requests to a local python daemon or a dedicated
>> VM that will negotiate the NAT traversal and configure the network
>> accordingly. In this case, prompt the user in Dom0 about the NAT
>> traversal request. Of course the qvm-* set of tools must e able to
>> achieve the same tasks via CLI.
> 
> While indeed appealing, this feature may be very easily abused to
> unknowingly expose a VM to an extra attack surface.
> At the very least there needs to be a way to a) see that some
> connections are redirected into a VM and b) easy way to block them.
> But to be honest, I'm not sure if this isn't too dangerous. Allowing a
> VM to influence the firewall, even as a proposal for user to confirm
> sounds risky.

I have mixed feelings about this.

On the one hand, this is indeed risky.  On the other hand, P2P
applications are currently crippled except in sys-net.  Some protocols
can fall back to TURN servers, but that doesn’t always work and is
at best a fallback behavior.  I have personally hit this problem more
than once.  NAT traversal and port forwarding aren’t something
everyone needs, but for those who *do* need it, it is extremely
difficult to work around the lack of it.

IMO, port forwarding and NAT traversal should be clearly separated,
as the use-cases are extremely different.  Port forwarding is used
to expose a server to the outside world, whereas NAT traversal is
used for P2P communication.  Furthermore, my understanding is that
port forwarding usually needs to be persistent, whereas NAT traversal
usually does not.  And port forwarding often requires a specific port
to be forwarded, whereas for NAT traversal I would not be surprised
if the system can choose the port.

I agree that allowing a qube to set up its own port forwarding is a
Bad Idea in most cases.  That said, it should be possible to set up
port forwarding via the Admin API, with fine-grained access controls.
So it should be possible to express, “Qube X can request port Y
to be forwarded to it,” as a qrexec policy.  In practice, however,
I expect most users to manage port forwarding from the management qube.

NAT traversal is a different matter altogether.  It is already
possible for a qube and a peer that are *trying* to establish a P2P
connection to do so, by means of a brute force attack.  Nobody does
this in practice, because it requires (on average) somewhere around
65536 outgoing connections from each side, which is a good way to
overload firewalls.  But it can be done, assuming that all outgoing
UDP traffic is allowed.  And there are a large number of applications
that need it.  These applications often need to set up and tear down
connections at will.

Overall, I consider allowing qubes to request NAT traversal a net win,
provided a few restrictions are enforced:

- Only UDP forwarding may be requested.  TCP is not allowed.

- Only certain ports can be forwarded.  Well-known ports (anything
  in /etc/services) and ports below 1024 are blocked.  Ideally,
  the port number should be chosen by QubesOS, rather than by the
  requesting qube.

- Only the qube that made the request can receive the traffic.
  Intermediate qubes, such as sys-net and sys-firewall, pass through
  the traffic, but attempts to listen on the relevant port fail with
  EADDRINUSE or similar.

- NAT traversal is only allowed if a certain preference has been set
  via the Admin API.

Sincerely,

[qubes-devel] Re: Qubes Canary 025

[Demi M. Obenour]

On 12/12/20 9:22 AM, Andrew David Wong wrote:
> Dear Qubes Community,
> 
> We have published Qubes Canary 025. The text of this canary is
> reproduced below.
> 
> Note: We have decided to make some minor formatting changes to the way
> Qubes Canary and Qubes Security Bulletin (QSB) numbers are printed,
> such as dropping the '#' symbol and using hyphens instead of spaces.
> 
> This canary and its accompanying signatures will always be available in
> the Qubes Security Pack (qubes-secpack).
> 
> View Qubes Canary 025 in the qubes-secpack:
> 
> https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-025-2020.txt
> 
> Learn about the qubes-secpack, including how to obtain, verify, and
> read it:
> 
> https://www.qubes-os.org/security/pack/
> 
> View all past canaries:
> 
> https://www.qubes-os.org/security/canaries/
> 
> ```
> 
> 
>     ---===[ Qubes Canary 025 ]===---
> 
> 
> Statements
> ---
> 
> The Qubes core developers who have digitally signed this file [1]
> state the following:
> 
> 1. The date of issue of this canary is December 8, 2020.
> 
> 2. There have been 62 Qubes Security Bulletins published so far.
> 
> 3. The Qubes Master Signing Key fingerprint is:
> 
>     427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
> 
> 4. No warrants have ever been served to us with regard to the Qubes OS
> Project (e.g. to hand out the private signing keys or to introduce
> backdoors).
> 
> 5. We plan to publish the next of these canary statements in the first
> two weeks of March 2020. Special note should be taken if no new canary
> is published by that time or if the list of statements changes without
> plausible explanation.
> 
> Special announcements
> --
> 
> None.
> 
> Disclaimers and notes
> --
> 
> We would like to remind you that Qubes OS has been designed under the
> assumption that all relevant infrastructure is permanently
> compromised.  This means that we assume NO trust in any of the servers
> or services which host or provide any Qubes-related data, in
> particular, software updates, source code repositories, and Qubes ISO
> downloads.
> 
> This canary scheme is not infallible. Although signing the declaration
> makes it very difficult for a third party to produce arbitrary
> declarations, it does not prevent them from using force or other
> means, like blackmail or compromising the signers' laptops, to coerce
> us to produce false declarations.
> 
> The news feeds quoted below (Proof of freshness) serves to demonstrate
> that this canary could not have been created prior to the date stated.
> It shows that a series of canaries was not created in advance.
> 
> This declaration is merely a best effort and is provided without any
> guarantee or warranty. It is not legally binding in any way to
> anybody. None of the signers should be ever held legally responsible
> for any of the statements made here.
> 
> Proof of freshness
> ---
> 
> Tue, 08 Dec 2020 16:46:42 +
> 
> Source: DER SPIEGEL - International 
> (https://www.spiegel.de/international/index.rss)
> Dangerous Accusations: German Tennis Star Alexander Zverev Faces Career 
> Turning Point
> Skiing in the Pandemic: Alpine Rivalries Flare amid Resort Closures
> Biden's Goal of Saving the Iran Deal Just Got Harder - A Murder and an 
> Ultimatum
> Heiko Maas: Germany's Foreign Minister on the Future of Trans-Atlantic 
> Relations
> Generation Corona: The Pandemic Is Changing Our Children's Lives for the Worse
> 
> Source: NYT > World News 
> (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
> Covid-19 Live Updates: Britain Begins Vaccinating Citizens
> U.K. Covid Vaccine: Side Effects, Safety, and Who Gets It First
> U.S. Leaves Behind Afghan Bases  and a Legacy of Land Disputes
> Covid Infections, and Blame, Rise Along Southeast Asian Borders
> U.S. Imposes Sanctions on Chinese Officials Over Hong Kong Crackdown
> 
> Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
> Safety data on Pfizer jab released by US
> Lloyd Austin: Biden picks ex-general as defence secretary
> The man saving monkeys in the Colombian Amazon
> Charlie Hebdo attack: France seeks long jail terms in Paris trial
> Christchurch massacre: Inquiry finds failures ahead of attack
> 
> Source: Blockchain.info
> 000c6550025327ca735099e0c621a9ad4599a49dab41f573
> 
> Footnotes
> --
> 
> [1] This file should be signed in two ways: (1) via detached PGP
> signatures by each of the signers, distributed together with this
> canary in the qubes-secpack.git repo, and (2) via digital signatures
> on the corresponding qubes-secpack.git repo tags. [2]
> 
> [2] Don't just trust the contents of this file blindly! Verify the
> digital signatures!
> ```
> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2020/12/12/canary-25/

Thunderbird states that the signature on this message was not properly
signed, FYI.  

[qubes-devel] Fwd: [QubesOS/qubes-issues] Efficient compiled binary policy format (#6266)

[Demi M. Obenour]

On 12/7/20 3:33 PM, Marek Marczykowski-Górecki wrote:
> [moving to qubes-devel, to keep qubes-issues on topic]
> 
> On Mon, Dec 07, 2020 at 09:50:01AM -0800, Demi Marie Obenour wrote:
>> There are other improvements I can think of:
> 
>> - Avoid spawning a `qrexec-client` process for each call.
> 
> Yes, this is in fact the very next improvement to qrexec I'd like to see
> (when we get to next round of qrexec improvements). Specifically:
> 
> When qrexec-daemon receive call request from qrexec-agent, it should
> connect to qrexec-policy-daemon (like it does now) and based on the
> response, connect to the other qrexec-daemon (of the target domain) and
> negotiate connection parameters. Avoid having qrexec-policy-daemon
> spawning `qrexec-client` for this purpose.
> But if the call target is dom0, still spawn a separate process (can be
> existing `qrexec-client`). Similarly, when making a call from dom0, use
> `qrexec-client`.
> 
> The motivation for this approach is cleanup of responsibilities:
>  - qrexec-policy-* should be about policy evaluation, disentangled from
>connection setup
>  - qrexec-daemon should be about connection coordination (control
>packets, optimized for low latency), but not data path (optimized for
>high throughput); this is because I fear some optimizations we could
>make in one part may increase complexity of the other to preserve
>performance requirements
>  - qrexec-client - data proxy (vchan <-> pipe/socket) for service calls
>originating/targeting dom0
> 
> It isn't clear to me whether we need such control/data split on the VM
> side, since there is significantly less control flow processing (no
> interaction with policy, or other's VMs instances).

Agreed.  The data path should be extremely simple and fast.

>> - Handle all requests inside a single agent process, rather than forking a 
>> new process per connection.
> 
> Just `fork` is relatively cheap in Linux, so I'd first carefully
> evaluate what we would gain here.

Indeed it is, but some applications (such as Qubes Manager) may make
hundreds of qrexec calls, so the cost can add up.  This is probably
not the lowest-hanging fruit, though.  

> But, there is another place that could use an improvement: avoid the
> requirement of spawning new `qrexec-client-vm` process to make each call.
> This could be done either by implementing `qrexec-client-vm`
> functionality as a library that could be used from within arbitrary
> application (IMO quite tricky, especially if such application has some
> event loop we'd need to integrate with), or by qrexec-agent exposing a
> socket where data could be exchanged directly (vchan connection would be
> handled on the agent side, not client side like right now). The latter
> one would look like SOCKS-like connection from the outside: simple
> header for qrexec call metadata (service, target) and then just data
> stream. Perhaps this could be even SOCKS(5?) protocol directly, to
> enable using existing client implementations.

A qrexec library would indeed be awesome.  While having `qrexec-agent`
expose a socket would work, it won’t be able to be as fast, due
to requiring extra copies.  However, it does have the advantage that
only the agent needs to be able to make Xen ioctls.  Perhaps we could
use shared memory and SCM_RIGHTS?

The best way to integrate with event loops is probably to expose
a file descriptor that can be polled.  In the future, we might
want a kernel-mode vchan driver, which could simplify matters
quite a bit.  On Windows, I am honestly not certain how best to
integrate with event loops, although I believe the undocumented
Nt{Create,Associate,Cancel}WaitCompletionPacket syscalls might help.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b2023a05-8b9d-9c5c-feb3-6a33fd17da51%40invisiblethingslab.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-devel] ITL email keys

[Demi M. Obenour]

On 11/13/20 7:56 AM, Andrew Clausen wrote:
> Hi Demi,
> 
> On Thu, 12 Nov 2020 at 16:26, Demi M. Obenour  wrote:
> 
>> FYI, I am not sure how to obtain the public key that signed that
>> message.
>>
> 
> All Qubes keys are available inside the "distribution-gpg-keys" package,
> which you can install with "dnf install distribution-gpg-keys".  Since this
> package is signed, it has a pretty good chain of trust built into it.
> Since this is a Fedora package, it is also helpful for securely installing
> Qubes from another Fedora-based distribution.
> 
> I have been meaning to update the Qubes documentation about this, but I
> have been a bit busy!
> 
> Kind regards,
> Andrew

Thank you!  That is quite helpful, although it doesn’t include the
email keys.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/07366e32-37ff-0910-8f7b-ca65f362a9d1%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] Travis-CI changes

[Demi M. Obenour]

On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi all,
> 
> Recently Travis-CI have changed their limits for public repositories[1].
> We've used up new free monthly limit in just 3 days. They do offer extra
> limits for some open source projects, but the project requesting it must
> meet the following criteria:
> 
> - - Project must be at least 3 months old and is in active development (with 
> regular commits and activity)
> - - Project meets the OSD specification
> - - Project must not be sponsored by a commercial company or organization 
> (monetary or with employees paid to work on the project)
> - - Project can not provide commercial services or distribute paid versions 
> of the software
> 
> We do not meet the third one. I see following options:
> 
> 1. Buy their paid plan - for $79/month we can have one parallel job (we
> had 4) and unlimited time.
> 2. Migrate to alternative CI service. Specifically I have gitlab-ci in
> mind.
> 
> The first option is not so cheap, but also we use CI quite a lot given
> how fast we've used up the limit.
> 
> As for the second opiton, why gitlab-ci? Because Frédéric done most of
> the integration already[2]. But there are still few options:
>  - use gitlab.com and connect our own worker(s)
>  - use Frédéric's gitlab instance
>  - setup separate gitlab instance
> 
> My main concern regarding which instance to use is about availability
> and maintenance. I'd like to avoid situation when only one person can
> fix things if something is broken. Believe it or not, some of us do
> take vacations form time to time ;)
> 
> Any opinions? Any other options?

GitLab CI seems to be a good choice.  The GHC team has had good
experiences with it, for example.  Since we consider the CI to be
untrusted, and since we want to minimize maintenance, I suggest using
https://gitlab.com as opposed to hosting our own instance.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d2ed2a7d-7b87-431a-f1a3-b21dc00f0d90%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] QSB #61 Information leak via power sidechannel (XSA-351)

[Demi M. Obenour]

On 11/12/20 11:49 AM, unman wrote:
> On Thu, Nov 12, 2020 at 11:26:32AM -0500, Demi M. Obenour wrote:
>> FYI, I am not sure how to obtain the public key that signed that
>> message.
>>
>> Sincerely,
>>
>> Demi
>>
> 
> https://www.qubes-os.org/team/
> Or search on keyserver

I was able to import the key, but am not sure how to build a chain
of trust to it.  Once I have managed to build one, I will file a PR
to the documentation.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/efb5f8e6-df13-735e-e5a4-af950129343d%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] QSB #61 Information leak via power sidechannel (XSA-351)

[Demi M. Obenour]

On 11/12/20 11:49 AM, unman wrote:
> On Thu, Nov 12, 2020 at 11:26:32AM -0500, Demi M. Obenour wrote:
>> FYI, I am not sure how to obtain the public key that signed that
>> message.
>>
>> Sincerely,
>>
>> Demi
>>
> 
> https://www.qubes-os.org/team/
> Or search on keyserver

I imported the key, but am trying to figure out how to build a chain
of trust to it.  If someone could help me, that would be greatly
appreciated.  Once that is done, I will file a PR to the documentation.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8ea62f57-fdaa-6377-cb4f-59fbf07102ad%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] QSB #61 Information leak via power sidechannel (XSA-351)

[Demi M. Obenour]

FYI, I am not sure how to obtain the public key that signed that
message.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e4b07c12-0537-7a24-115d-853c3f421ffc%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-devel] Exploitability of the multiple signature bug

[Demi M. Obenour]

There were recent changes in qubes-builder related to a logic bug
in the verify-tag script.  The bug could be triggered by a malformed
signed tag with multiple signatures.  However, my reading of the post
that disclosed the vulnerability seems to indicate that it could
not be exploited in the context of qubes-builder, as we check for
TRUST_(FULLY|ULTIMATE), rather than GOODSIG and VALIDSIG.

Is this accurate?

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e332798d-e487-5a39-59dd-da67a648d40c%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] Signed repository metadata and untrusted templates

[Demi M. Obenour]

On 7/26/20 8:31 PM, Marek Marczykowski-Górecki wrote:
> In theory, it could be even simpler - the build VM could generate
> repository metadata out of local repository copy, sign it and only then
> upload to the server (currently it upload packages and generate metadata
> on the remote host). One issue with that is that local copy would need
> to be a full copy - currently we keep only latest packages in that
> environment to save some disk space, but we keep all of them in the
> public server (to allow explicit downgrades and also reproducing build
> environment for specific package).

Which code would I need to change for this?  I imagine it is somewhere
in qubes-builder, but I am not sure.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/86c9287b-c8bd-51d9-60e6-10af48186c72%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] Is it more secure to update dom0 and templates via Salt?

[Demi M. Obenour]

On 10/16/20 2:17 PM, Chris Laprise wrote:
> I'm recalling times when I received a cryptic error message that the update 
> failed (no detail). In these cases I would just go back to my update script 
> and then the update(s) would succeed. So this is not something I tried to 
> troubleshoot, and the failures were a little too common for me to keep using 
> that method.

Also, Arch explicitly does not support unattended upgrades (which Salt is).

Sincerely,

Demi M. Obenour
she/her/hers

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/556ebbc1-5650-f854-a7b4-5fce85bf4ae8%40gmail.com.


OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-devel] WIP: Qubes on KVM

[Demi M. Obenour]

On 2020-08-01 18:02, Marek Marczykowski-Górecki wrote:
>> In most KVM setups that I know of, the kernel network stack is
>> considered trusted.  That’s a reasonable assumption for production
>> servers, which have server-grade NICs and are behind enterprise
>> routers, but not for Qubes.
> 
> TBH I don't think "behind enterprise routers" really helps them. In many
> cases (all the cloud providers) the untrusted traffic comes from within
> the VMs, not only from outside.

That is true.  Nevertheless, RCEs in the Linux network stack are
*rare*, especially in LTS kernels.  Other than GRO Packet of Death
(which didn’t affect any LTS kernel), I am not aware of a single
such RCE in the last decade.  There are likely some vulnerabilities in
exotic protocols like SCTP and AX_25, but exploiting them requires
the relevant modules to be loaded, which they usually are not.
I believe most cloud hosts run very few (if any) network services
that are exposed to untrusted guests, so the userspace attack surface
is likely small as well.  Furthermore, cloud hosts don’t need to
implement Wi-Fi or Bluetooth.

>>> One idea is to use netdev socket to connect two VMs directly, but I
>>> worry about the performance...
> 
>> We could also reimplement the Xen netfront/netback protocols on top
>> of KVM shared memory.  Future versions of KVM might even have direct
>> support for Xen paravirtualized drivers.
> 
> While this would be a nice development, I think it *way more* complex
> development that is realistic in the short term future and without a
> specific directed funding for that.
> 
> As for the KVM upstream support for Xen PV drivers, all the plans I've
> seen focus on just compatibility (run unmodified Xen VMs on KVM),
> ignoring superior Xen security model. Specifically - implement backend
> drivers with the assumption of full guest memory access and have them
> only on the host system. There is also dual topic discussed - virtio
> support on Xen, and suffers from the same issue. Everyone says avoiding
> full guest memory access (and being able to have backend in another VM)
> is nice to have that no one is willing to work on :/

I am not familiar with virtio internals, but the protocol might be
inherently incompatible with a de-privileged backend.  If there is no
explicit setup of backend-writable memory mappings, it probably is.

It is almost certainly possible to implement Xen PV protocols on top
of KVM, but I wonder if it would be better to implement KVM-specific
protocols that map better to KVM’s primitives, in order to reduce
attack surface in the host.  Nevertheless, I believe that Xen is
likely to continue to be a better fit in the future.  Xen is focusing
on the security-critical embedded space, whereas KVM is mostly used
in datacenters.

>>> One thing to consider is also enabling memory deduplication in KVM
>>> (KSM). This should nicely save memory when running multiple similar VMs,
>>> but at the same time is risky in light of speculative execution and also
>>> rowhammer-style attacks.
> 
>> Honestly, I don’t think that deduplication is worth it, especially
>> in light of TRRespass.  It also makes side-channel attacks far, *far*
>> easier to exploit.
> 
>> What *might* be safe is mapping read-only data (such as dom0-provided
>> kernels) into multiple VMs 
> 
> I don't think the gain from just this worth the effort.

Agreed.

>>> Yes, no issue as stubdomains are not existing on KVM.
> 
>> This could be a nasty issue for HVMs,
> 
> You mean any VM. If not emulation, then PV backends.

No, I meant HVMs specifically.  PV backends can run in full domains,
as they do now.

>> as without stubdomains, all
>> emulation must be done in dom0.  Google and Amazon both solved this by
>> writing their own VMMs.  At some point, KVM might be able to move the
>> instruction emulation into userspace, which might be a significant win.
> 
>> (What I *really* want is a version of QubesOS based on seL4.
>> But seL4 didn’t support 64-bit VMs last I checked, and I am not
>> aware of any tooling for creating and destroying VMs at run-time.
>> Most of the userspace tooling around seL4 is based on CAmkES, which
>> requires that every component be statically known at compile-time.
>> Furthermore, getting seL4’s hypervisor and IOMMU support verified
>> would either require someone to fund the project, or someone who has
>> sufficient skill with the Isabelle proof assistant to do it themselves.
>> Without verification, the benefits of using seL4 are significantly
>> diminished.)
> 
> Well, seL4 kernel is still significantly smaller and delegate much more
> tasks to less trusted components. But I agree - for the current features
> of Qubes, the static nature of seL4 is quite limiting.

seL4 is actually fully dynamic ― it is the userspace tooling that
is static.  The seL4 developers have expressed interest in using seL4
in dynamic systems, and there are others who are working on building
dynamic systems on top of seL4, so I suspect this 

Re: [qubes-devel] WIP: Qubes on KVM

[Demi M. Obenour]

On 2020-08-01 11:32, Demi M. Obenour wrote:
> We could also reimplement the Xen netfront/netback protocols on top
> of KVM shared memory.  Future versions of KVM might even have direct
> support for Xen paravirtualized drivers.

To avoid any confusion, I am not talking about running Xen on top of
KVM, but rather implementing the Xen paravirtualized driver protocols
(or something similar) on top of KVM.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c4a07685-79ff-8e93-f20b-a6b8b9b4e911%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Linux UEFI IOMMU changes

[Demi M. Obenour]

Earlier this year, Linux changed its startup procedure on UEFI systems,
so that all PCI devices behind bridges are not able to DMA until Linux
has setup its IOMMU mappings.  This works because the UEFI drivers
also use the IOMMU, and Linux can disable bus mastering on PCI bridges
before telling the firmware to tear down its IOMMU mappings.

Would it be possible for Xen to do something similar?  This could
provide significant protection against DMA attacks.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/dde448d1-d984-a538-64cb-86d733a9c60a%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] WIP: Qubes on KVM

[Demi M. Obenour]

On 2020-08-01 07:59, Marek Marczykowski-Górecki wrote:
> On Fri, Jul 31, 2020 at 02:17:05PM -0700, Jason M wrote:
>> I then looked into alternatives to prevent my complete departure from 
>> Qubes.  Marek told me about DomB, which is now in its design stages.  It 
>> would allow me to statically partition my machine (like having 2 dom0 VMs 
> 
> Not really 2 dom0 in a sense you would need. What you'd need is a 2
> hardware domains (dom0 by default) and that can still be only one. One
> of domB proposal goals is to make it more meaningful to have hardware
> domain != dom0, by eliminating dom0.
> 
>> *GOALS*
>> The final goals would be to support all Qubes features and apps.
> 
> Yes!!
> 
>> *STAGE 1*
>> The initial goal is to get Qubes to be able to manage the virtual machines 
>> (start, stop, etc) using 'qvm-*' tools and *Qubes Manager*.  Seamless VM 
>> video or audio will not be implemented in stage 1 so either a GPU will need 
>> to be passed through to the VM (which will also be able to provide HDMI 
>> audio), or access using spice or vnc.  Stage 1 goals include the following:
> 
>>- Use same template system Qubes currently uses including settings like 
>>   *qvm-prefs*, *features*, *tags*, etc.
>>   - Obviously support PCI pass-through using Nvidia drivers for RTX GPU
>>   - Support qrexec communication from host <-> vm
>>   - Locking down KVM host
>>   - Securing the network - look into ability to enabling *sys-net* and 
>>  *sys-firewall*
> 
> One challenge with the last point is to have VM<->VM network connection
> (like sys-net - sys-firewall) without exposing the host to the traffic.
> Most (all?) of the traditional KVM setups assumes the host is responsible
> for routing network traffic.

In most KVM setups that I know of, the kernel network stack is
considered trusted.  That’s a reasonable assumption for production
servers, which have server-grade NICs and are behind enterprise
routers, but not for Qubes.

> One idea is to use netdev socket to connect two VMs directly, but I
> worry about the performance...

We could also reimplement the Xen netfront/netback protocols on top
of KVM shared memory.  Future versions of KVM might even have direct
support for Xen paravirtualized drivers.

> One thing to consider is also enabling memory deduplication in KVM
> (KSM). This should nicely save memory when running multiple similar VMs,
> but at the same time is risky in light of speculative execution and also
> rowhammer-style attacks.

Honestly, I don’t think that deduplication is worth it, especially
in light of TRRespass.  It also makes side-channel attacks far, *far*
easier to exploit.

What *might* be safe is mapping read-only data (such as dom0-provided
kernels) into multiple VMs 
> Yes, no issue as stubdomains are not existing on KVM.

This could be a nasty issue for HVMs, as without stubdomains, all
emulation must be done in dom0.  Google and Amazon both solved this by
writing their own VMMs.  At some point, KVM might be able to move the
instruction emulation into userspace, which might be a significant win.

(What I *really* want is a version of QubesOS based on seL4.
But seL4 didn’t support 64-bit VMs last I checked, and I am not
aware of any tooling for creating and destroying VMs at run-time.
Most of the userspace tooling around seL4 is based on CAmkES, which
requires that every component be statically known at compile-time.
Furthermore, getting seL4’s hypervisor and IOMMU support verified
would either require someone to fund the project, or someone who has
sufficient skill with the Isabelle proof assistant to do it themselves.
Without verification, the benefits of using seL4 are significantly
diminished.)

Sincerely,

Demi



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a0fa62fd-941b-c450-542c-59be6c7c238c%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Signed repository metadata and untrusted templates

[Demi M. Obenour]

On 2020-07-26 20:31, Marek Marczykowski-Górecki wrote:
> On Sun, Jul 26, 2020 at 06:59:02PM -0400, Demi M. Obenour wrote:
>> When looking at recent posts about template managers, two points came to 
>> mind:
> 
>> ### Metadata Signing
> 
>> Signing metadata would be awesome.  Control over the repo listing
>> allows delaying updates without being detected, and also allows for
>> social engineering attacks.  Debian manages to sign its metadata, so I
>> don’t see any fundamental reason we can’t either.  
> 
> Debian actually signs metadata _instead of_ packages. This means a
> debian package without matching signed metadata cannot be trusted[1]...
> 
>> My understanding
>> is that the metadata can be (deterministically) computed from the
>> packages in the repo, which are themselves signed.  Therefore, we
>> could have a trusted VM that accepts RPM packages as input, checks
>> the signatures, and then updates the metadata appropriately.
> 
> In theory, it could be even simpler - the build VM could generate
> repository metadata out of local repository copy, sign it and only then
> upload to the server (currently it upload packages and generate metadata
> on the remote host). One issue with that is that local copy would need
> to be a full copy - currently we keep only latest packages in that
> environment to save some disk space, but we keep all of them in the
> public server (to allow explicit downgrades and also reproducing build
> environment for specific package).
> 
> Signing repository metadata has one more issue: we try to have an audit
> trail what actually was signed (that's why all the build logs are
> published for example). When signing repo metadata, it's much harder,
> because besides the package you just built, you have a bunch of other
> packages you need to include too. Perhaps some solution would be logging
> difference between old and the new metadata? This is very similar issue
> to the one we have with signing Debian metatadata:
> https://github.com/QubesOS/qubes-issues/issues/2721

Logging the delta seems to be a good option.  If I recall correctly,
RPM metadata is stored as XML, so we can just do a textual diff.

How much disk space would be required?  Is it enough to actually
matter in practice?

> [1] Theoretically deb package format do support signatures, but Debian
> project do not use that and the tooling is in quite poor state.

If I recall correctly, they use signatures on *source* packages,
but not on *binary* packages.

>> ### Secure Installation of Untrusted Templates
> 
>> Currently, templates are packaged via RPM, which allows executing
>> arbitrary code on installation.  However, the Qubes Admin API already
>> allows importing a TemplateVM volume into dom0 without risking a dom0
>> compromise.  I see no reason why one needs to trust the packaging of a
>> template any more than the template itself.  If I publish a TemplateVM
>> package, and my packaging infrastructure is compromised, the attacker
>> will be able to compromise the TemplateVM packages I deliver, as
>> well as any VMs based on those templates.  They should not, however,
>> be able to compromise any other VMs, much less dom0.  Of course,
>> a compromised TemplateVM is still bad, but it is not Game Over.
> 
> This is one of the goals of the current template manager GSoC project.
> The templates are still packages as RPMs, but those are used just as a
> signed file containers - specifically, those packages will no longer be
> installed using rpm tool, no pre/post/etc scripts from the package are
> run, no package dependencies are handled etc. This makes it quite safe
> to install such package with the new qvm-template directly in dom0, but
> for added protection, it is also possible to use that tool outside of
> dom0 (given proper Admin API permissions).

What permissions will be needed?  I am worried that they will be
something like “allow RW to all”, which is almost as bad as dom0.
This is compounded by “ask” prompts for the Admin API being rather
unhelpful: instead of prompting for *the VM that will be affected by
the operation*, they prompt for the *VM the operation will be executed
on*, which for the admin API is always dom0.

Also, what is the advantage of RPMs over something like OpenBSD’s
signify(1)-signed gzipped tar files?  The RPM format seems rather
bloated for this use-case.

Sincerely,

Demi


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/06d4a859-3360-c370-8e3f-085e3eb47b14%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Signed repository metadata and untrusted templates

[Demi M. Obenour]

When looking at recent posts about template managers, two points came to mind:

### Metadata Signing

Signing metadata would be awesome.  Control over the repo listing
allows delaying updates without being detected, and also allows for
social engineering attacks.  Debian manages to sign its metadata, so I
don’t see any fundamental reason we can’t either.  My understanding
is that the metadata can be (deterministically) computed from the
packages in the repo, which are themselves signed.  Therefore, we
could have a trusted VM that accepts RPM packages as input, checks
the signatures, and then updates the metadata appropriately.

### Secure Installation of Untrusted Templates

Currently, templates are packaged via RPM, which allows executing
arbitrary code on installation.  However, the Qubes Admin API already
allows importing a TemplateVM volume into dom0 without risking a dom0
compromise.  I see no reason why one needs to trust the packaging of a
template any more than the template itself.  If I publish a TemplateVM
package, and my packaging infrastructure is compromised, the attacker
will be able to compromise the TemplateVM packages I deliver, as
well as any VMs based on those templates.  They should not, however,
be able to compromise any other VMs, much less dom0.  Of course,
a compromised TemplateVM is still bad, but it is not Game Over.

Sincerely,

Demi M. Obenour

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0d00289e-0dc3-8e09-43e4-647998e8ed80%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] WIP: Nvidia drivers and cuda within VM

[Demi M. Obenour]

On 2020-07-08 21:34, Jason M wrote:
> I am currently researching and working on getting the Nvidia RTX20x0 series 
> GPU working within a VM using the Nvidia drivers on Qubes 4.1 (master 
> branches).
> 
> I personally require access to the GPU Cuda cores for development 
> purposes.  I have been able to successfully install and run the Nvidia 
> drivers within dom0 and the Nouveau drivers within the VM using either 
> Seabios or OVMF UEFI bios.

You need to be careful to ensure that the drivers have not been
tampered with before installing them in dom0.

> Issues solved:
> 
>- Running Nvidia GPU in dom0 with either Nouveau or Nvidia and Cuda 
>drivers
>
>- Running Nvidia GPU in HVM with Nouveau driver
>
>- Setting OVMF UEFI to boot HVM without persistent bios data
>
>- Using a Qubes template to pass options to libvirt
>
> Some of the issues I am currently working on are:
> 
>- The big one; working on preventing Nvidia driver from failing due to 
>being run within a virtual environment.  I have completed research on this 
>and start testing some theories this weekend.  Most of the research tends 
>to support that the Nvidia drivers purposely fail to load and run within a 
>virtual environment.  I don't know if that still holds true for RTX20X0 
>cards, or even if the drivers fail to purposely load as that would be 
>illegal to do in many countries.  In any event, some on the experiments 
>will be 
>attempting to hide the hypervisor, and kernel options related to PCI, 
>IOMMU and memory options like disabling encrypted memory on AMD processors.

In which nations would it be illegal?  I know that Nvidia does support
server-grade GPUs in virtualized environments, but those are expensive.

>3. Nested virtualisation (Qubes in KVM).  Yuk.  Quickly tried and can't 
>get pass initial boot screen to login screen.  Maybe there are drivers 
>missing in initramfs disk as I can get nested Fedora Xen to boot.  May be 
> a 
>suitable stop-gap measure if proceeding with alternative #4 below.

I would prefer to avoid this, as KVM’s nested virtualization support
has a history of vulnerabilities.  Google is working on moving CPU
emulation out of the kernel, which should help substantially.

>4. KVM using Qubes frameworks.  @shawnanastasio 
> has been working on 
> qubes-core-vchan-kvm[5-6] 
>and libkvmchan[7], which is a good starting point for adapting Qubes 
>packages to KVM.  This would be a lot of work.  I am familiar enough with 
>Qubes to take on some of the tasks if this ends up being the only viable 
>option.

Why is KVM likely to work when Xen fails? 
 
> Regards,
> 
> Jason

Sincerely,

Demi


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/77c6115b-459c-8450-d291-6c4e2c41b0c7%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] "Qubes Architecture Next Steps: The New Qrexec Policy System" by Marek Marczykowski-Górecki & Marta Marczykowska-Górecka

[Demi M. Obenour]

On 2020-06-22 19:36, Andrew David Wong wrote:> You could also deny all calls 
from `work` except for calls to dom0:
> 
> ```
> * * work dom0 allow
> * * work * deny
> ```

This seems to allow *all* calls from work to dom0, which probably
isn’t wanted.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/29582d3f-ef8f-f222-8a49-e749664aba25%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Software Rowhammer mitigations

[Demi M. Obenour]

On 2020-06-19 00:14, Marek Marczykowski-Górecki wrote:> For extremely sensitive 
tasks you can shutdown/pause other VMs. But
> in practice a HVM/PVH VM have very few (if at all) ways of
> learning/probing physical memory layout to perform the attack.
> This is yet another reason to not use PV.
> If I'm not mistaken, the only demonstrated cross-VM rowhammer-based
> attack relies on memory-deduplication (across VMs), which we don't use.

That is good to know!

1. Does that mean that I can safely purchase hardware (such as the
   Insurgo PrivacyBeast) that is likely to be vulnerable to Rowhammer?
   Do you (personally) consider Rowhammer when purchasing hardware?

2. Will we be able to get rid of PV stubdomains at some point?

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/2898ebf1-5f82-e084-0899-31484b6dd405%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Software Rowhammer mitigations

[Demi M. Obenour]

On 2020-06-18 22:38, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 18, 2020 at 09:49:14PM -0400, Demi M. Obenour wrote:
>> Would it be possible to mitigate Rowhammer by ensuring that different VMs 
>> don’t use nearby rows?
> 
> I'm pretty sure no hypervisor supports such thing (such specific
> physical memory layout control). But also, it would be really hard to do
> in a dynamic environment, where you release memory and then possibly
> allocate to another VM. This would make memory allocator even more
> complex. I guess if this approach would be practical practical, someone
> would have implemented it already - yet, I see many research papers with
> similar ideas, some from many years ago, and exactly zero real-life
> working implementations.
> 
> Anyway, this is rather a question to relevant hypervisor developers (Xen
> in this case).
In the meantime, what does the Qubes Security Team recommend be done
to mitigate the risk of Rowhammer?  ECC RAM is not available on most
laptops, and even it is only a partial mitigation.  TRRespass showed
that TRR, at least as currently implemented, is not a complete
fix either.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f9f9bca8-314c-35d0-eb25-57c853b0cbab%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Software Rowhammer mitigations

[Demi M. Obenour]

Would it be possible to mitigate Rowhammer by ensuring that different VMs don’t 
use nearby rows?

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/756b939c-e1ec-17b3-7a26-03f5898f1135%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Qubes 4.1 upgraded to Fedora 32 in dom0

[Demi M. Obenour]

On 2020-05-27 09:57, Marek Marczykowski-Górecki wrote:
> Hi all,
> 
> We've mostly completed updating dom0 in Qubes 4.1 to Fedora 32[1]. For
> those already running Qubes 4.1, a manual upgrade is necessary:
> 
> cp /etc/yum.repos.d/qubes-dom0.repo /etc/yum.repos.d/qubes-dom0-fc32.repo
> sed -i s/fc31/fc32/g /etc/yum.repos.d/qubes-dom0-fc32.repo
> qubes-dom0-update --action=upgrade -y qubes-release
> # qubes-release 4.1-0.24 should be installed
> # now make sure all .rpmnew files are handled, especially those in
> # /etc/yum.repos.d/
> rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-primary
> qubes-dom0-update --action=distro-sync \
> --enablerepo=qubes-dom0-current-testing --clean
> reboot
> 
> There are a few changes and also some known issues:
> 1. Qrexec policy is migrated to the new format[2], not it lives in
>/etc/qubes/policy.d/. Old location still works.
> 2. Various software is updated
> 3. domains widget doesn't work (it crashes on startup, flashing)[3]
> 
> [1] https://github.com/QubesOS/qubes-issues/issues/5763
> [2] https://github.com/QubesOS/qubes-issues/issues/4370
> [3] https://github.com/QubesOS/qubes-issues/issues/5854

Is Qubes 4.1 suitable for use as a daily driver yet?  Just wondering.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/3dc559af-d7ad-6dba-b7bb-f32a401f6b9c%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] IPv6 setup for OpenBSD HVM

[Demi M. Obenour]

On 2020-05-26 00:54, Demi M. Obenour wrote:
> On 2020-05-25 23:30, Marek Marczykowski-Górecki wrote:
>> On Mon, May 25, 2020 at 02:00:00PM -0400, Demi M. Obenour wrote:
>>> What is the correct setup for IPv6 routing on an OpenBSD HVM?
>>> IPv4 works fine, but IPv6 does not, although I can ping the gateway
>>> over IPv6.  I suspect that the difference has something to do with
>>> proxy NDP vs proxy ARP, but I am not sure.
>>
>> This is likely. We do have enabled proxy ARP, but not proxy NDP. So,
>> setting any gateway on IPv4 should work, but not for IPv6.
>>
>> You can see expected configuration via qvm-prefs. Especially
>> "visible_gateway6" property is what you should set as the gateway.
>> But you can also play with proxy NDP, maybe more convenient solution
>> would be to just enable it (and keep an eye open for side effects).
> 
> Linux refuses to enable proxy NDP for a whole subnet, although this
> might be possible with a userspace daemon.  That said, I would be
> fine so long as I was able to rely on a single fixed gateway address.
> 
> (What I would really prefer is to avoid NDP and ARP entirely, and
> configure the corresponding tables statically.  This should be quite
> possible on Linux, for example.  This reduces both attack surface
> and the number of things that can go wrong.)

As it turns out, this is quite possible.  The following network hook
script in the NetVM does the job just fine, without affecting other
qubes that share the same NetVM as the OpenBSD qube:

#!/bin/bash --
set -eu
exec >> /rw/config/vif-route.log 2>&1
export LC_ALL=C
[ $# -eq 4 ]
[ ${#4} -gt 0 ]
perl -wT -Mstrict '-MSocket=:addrinfo' -e '
if ($ARGV[1] !~ /\Avif[0123456789]+\.0\z/s) { die "Invalid interface\n" }
(my $err, my @res) = getaddrinfo($ARGV[3], "1", { flags => AI_NUMERICHOST });
if ($err != 0 ) { die "$err\n"; }' -- "$@"
if [[ $1 = 'online' ]]; then
ip neighbor add to "$4" dev "$2" lladdr 00:16:3e:5e:6c:00 nud permanent 
||
ip neighbor change to "$4" dev "$2" lladdr 00:16:3e:5e:6c:00 nud 
permanent
elif [[ $1 = 'offline' ]]; then
ip neighbor delete to "$4" dev "$2" lladdr 00:16:3e:5e:6c:00 nud 
permanent
else
exit 1
fi

By also adding static neighbor entries in OpenBSD, I am able to
automatically set up both IPv4 and IPv6 connectivity without OpenBSD
having to know the actual IP address of its gateway.  I chose to
use the link-local address fe80::fcff::feff:%xnf0, as it is
guaranteed to be a valid address belonging to the NetVM.

If this was done for all qubes with network connections, ARP and NDP
could be blocked by firewall rules, significantly reducing attack
surface.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/077b846f-50ea-18b9-acfc-998f9958b99a%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] IPv6 setup for OpenBSD HVM

[Demi M. Obenour]

On 2020-05-25 23:30, Marek Marczykowski-Górecki wrote:
> On Mon, May 25, 2020 at 02:00:00PM -0400, Demi M. Obenour wrote:
>> What is the correct setup for IPv6 routing on an OpenBSD HVM?
>> IPv4 works fine, but IPv6 does not, although I can ping the gateway
>> over IPv6.  I suspect that the difference has something to do with
>> proxy NDP vs proxy ARP, but I am not sure.
> 
> This is likely. We do have enabled proxy ARP, but not proxy NDP. So,
> setting any gateway on IPv4 should work, but not for IPv6.
> 
> You can see expected configuration via qvm-prefs. Especially
> "visible_gateway6" property is what you should set as the gateway.
> But you can also play with proxy NDP, maybe more convenient solution
> would be to just enable it (and keep an eye open for side effects).

Linux refuses to enable proxy NDP for a whole subnet, although this
might be possible with a userspace daemon.  That said, I would be
fine so long as I was able to rely on a single fixed gateway address.

(What I would really prefer is to avoid NDP and ARP entirely, and
configure the corresponding tables statically.  This should be quite
possible on Linux, for example.  This reduces both attack surface
and the number of things that can go wrong.)

>> In case it matters, I would prefer to avoid hardcoding the default
>> gateway, but if that is necessary, I will.  The addresses for the Xen
>> network interfaces are already configured automatically by a script I
>> wrote that reads the information from XenStore, but OpenBSD doesn’t
>> seem to support userspace access to Xen grant tables or event channels,
>> so reading from QubesDB would require building a custom kernel.
>> I would prefer to avoid that.
> 
> That's a bummer. Are there any plans for userspace access to those
> interfaces? Without them, you won't have qrexec neither (if you'd like
> this to be some next step).

Not sure.  I doubt that they are planning on writing drivers to allow
this access themselves.  If it is possible to grant access to them
without allowing userspace to compromise the kernel, the OpenBSD team
might be willing to accept patches, provided that whoever submitted
the patches was willing and able to maintain them long-term.  On the
other hand, OpenBSD already has Xen netfront and blkfront drivers,
so much of the infrastructure is already present.

Another option is to use networking instead, but that is slow, ugly,
and requires every OpenBSD qube to have network access.  Furthermore,
OpenBSD does not have netback or blkback drivers, so the only way it
can serve as sys-net is if it is a frontend to the real sys-net.

I have already had to patch /etc/rc and replace /usr/sbin/sysupgrade
with my own version, so implementing deep integration with OpenBSD is
likely to be a significant amount of work.  Part of the difficulty is
that OpenBSD is quite minimal.  There are no loadable kernel modules,
so we cannot add our own drivers without a custom kernel, and there
are no bind mounts, so I had to resort to loopback NFS (which in turn
requires extra work to avoid deadlocking at shutdown).

Due to work commitments, I will not be able to work any further
on QubesOS for a while.  I hope what I have learned will be useful
for others who want to run other OSs under Qubes.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0a2b64b4-4b87-7dec-119a-0e451428207a%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] IPv6 setup for OpenBSD HVM

[Demi M. Obenour]

What is the correct setup for IPv6 routing on an OpenBSD HVM?
IPv4 works fine, but IPv6 does not, although I can ping the gateway
over IPv6.  I suspect that the difference has something to do with
proxy NDP vs proxy ARP, but I am not sure.

In case it matters, I would prefer to avoid hardcoding the default
gateway, but if that is necessary, I will.  The addresses for the Xen
network interfaces are already configured automatically by a script I
wrote that reads the information from XenStore, but OpenBSD doesn’t
seem to support userspace access to Xen grant tables or event channels,
so reading from QubesDB would require building a custom kernel.
I would prefer to avoid that.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8db065b4-2de1-047c-e9fe-71da803499a6%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Safe Arch install

[Demi M. Obenour]

On 2020-05-24 15:58, Marek Marczykowski-Górecki wrote:>> That makes sense.  
Writing to a qube’s root volume from dom0 is a
>> safe operation, since it doesn’t do anything that the qube could
>> not already do itself.  It would be nice if that could be done by
>> `qvm-block import`, though.
> 
> You can do that with `qvm-volume import`. And with some adjustments to
> the qrexec policy, you can do that even from your buildvm.

Something like

buildvm arch ask,target=dom0

in `/etc/qubes-rpc/policy/admin.vm.volume.Import+root`?

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/82ff499c-7c84-17e2-518d-b9d7de894cc6%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Safe Arch install

[Demi M. Obenour]

On 2020-05-24 15:13, dhorf-qriry.020b9...@hashmail.org wrote:
> On Sun, May 24, 2020 at 03:01:50PM -0400, Demi M. Obenour wrote:
> 
>>> https://github.com/xaki23/rzqubes/blob/master/misc/installtemplate.sh
>>>
>>> can be run in either dom0 or (with a lot of policy adjustments
>>> or a bazillion manual approvals and minor changes) an adminapi-vm.
>>>
>>> it is also mostly trivial to install the template-root right
>>> from the buildvm. (skipping the "rpm" part entirely)
>>
>> How does one do that?  That sounds promising.
> 
> 
> see above shellscript for the general basic outline of "how to turn
> a template rpm into a template vm".
> 
> most of the qvm-something steps are also avail in appvms through
> the adminapi these days. (== can be called from a buildvm)
> 
> for "skipping the rpm part" prototype see 
> https://github.com/QubesOS/qubes-builder/pull/87
> and related PRs/diffs.
> 
> both the shellscript and builder integration are fully functional,
> but need cleanup before they can be merged.
> the main open issue is how to integrate a template-specific
> settings-file (the "tplspec" parts) with the build process.
> this is mostly needed for the mirage templates.

That makes sense.  Writing to a qube’s root volume from dom0 is a
safe operation, since it doesn’t do anything that the qube could
not already do itself.  It would be nice if that could be done by
`qvm-block import`, though.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ec021f93-d6f9-61d2-5713-455307de6cdf%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Safe Arch install

[Demi M. Obenour]

On 2020-05-24 14:49, dhorf-qriry.020b9...@hashmail.org wrote:
> On Sun, May 24, 2020 at 02:36:00PM -0400, Demi M. Obenour wrote:
>> Is it possible to build an Arch install ISO in addition to the
>> TemplateVM RPMs?  I would prefer to avoid copying the RPMs into
>> my dom0, whereas installing from an ISO has no such problems.
> 
> that is actualy worse than copying a rpm to dom0.

I meant installing a qube from an ISO image in another qube.
 
>> Alternatively, is it possible to extract a root filesystem image
>> from an RPM and safely (without compromising dom0) import it into a
>> fresh TemplateVM?
> 
> https://github.com/xaki23/rzqubes/blob/master/misc/installtemplate.sh
> 
> can be run in either dom0 or (with a lot of policy adjustments
> or a bazillion manual approvals and minor changes) an adminapi-vm.
> 
> it is also mostly trivial to install the template-root right
> from the buildvm. (skipping the "rpm" part entirely)

How does one do that?  That sounds promising.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/2231e506-421c-6b85-33d7-f40e0b9ae76e%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Safe Arch install

[Demi M. Obenour]

Is it possible to build an Arch install ISO in addition to the
TemplateVM RPMs?  I would prefer to avoid copying the RPMs into
my dom0, whereas installing from an ISO has no such problems.
Alternatively, is it possible to extract a root filesystem image
from an RPM and safely (without compromising dom0) import it into a
fresh TemplateVM?

Alternatively, does ITL distribute Arch template packages?  I could
not find them in the repositories.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1e29c88b-c143-a3b5-5f58-2b2577dd2f51%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing

[Demi M. Obenour]

On 2020-04-30 10:00, Andrew David Wong wrote:
> Dear Qubes Community,
> 
> This announcement includes several updates regarding Fedora TemplateVMs.
> 
> Fedora 30 approaching EOL
> =
> 
> With the release of Fedora 32 on April 28, Fedora 30 is expected to
> reach EOL (end-of-life) [1] on May 26, 2020.

When I used dnf system-upgrade on one of my templates, the result was a broken 
template.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8543a6e4-4542-d2f5-f2c4-32227bf24f20%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Rowhammer, hardware choice, and QubesOS

[Demi M. Obenour]

Dear Qubes Community:

I am considering purchasing a new laptop for various reasons,
including both security and wanting additional memory.  However,
I am worried about rowhammer attacks.  Is there a list of laptops
that come with RAM that has been found not vulnerable to Rowhammer?
If not, is there a list of RAM models that are not vulnerable, and
which I could replace the RAM with afterwards?

Additionally, would it be possible to implement anti-Rowhammer defenses
in Xen?  This could include arranging page tables such that rows of
RAM belonging to different qubes are separated by a gap, which would
prevent the attack from breaking Qubes-provided isolation.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d542860c-913c-a3c5-086a-a453dc9ad101%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Qubes Canary #23

[Demi M. Obenour]

On 2020-04-15 05:32, Andrew David Wong wrote:
> Dear Qubes Community,
> 
> We have published Qubes Canary #23. The text of this canary is
> reproduced below. This canary and its accompanying signatures will
> always be available in the Qubes Security Pack (qubes-secpack).
> 
> View Qubes Canary #23 in the qubes-secpack:
> 
> https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-023-2020.txt
> 
> Learn about the qubes-secpack, including how to obtain, verify, and read
> it:
> 
> https://www.qubes-os.org/security/pack/
> 
> View all past canaries:
> 
> https://www.qubes-os.org/security/canaries/
> 
> ```
> 
> 
> ---===[ Qubes Canary #23 ]===---
> 
> 
> Statements
> ---
> 
> The Qubes core developers who have digitally signed this file [1]
> state the following:
> 
> 1. The date of issue of this canary is April 9, 2020.
> 
> 2. There have been 56 Qubes Security Bulletins published so far.
> 
> 3. The Qubes Master Signing Key fingerprint is:
> 
> 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
> 
> 4. No warrants have ever been served to us with regard to the Qubes OS
> Project (e.g. to hand out the private signing keys or to introduce
> backdoors).
> 
> 5. We plan to publish the next of these canary statements in the first
> two weeks of September 2020. Special note should be taken if no new canary
> is published by that time or if the list of statements changes without
> plausible explanation.
> 
> Special announcements
> --
> 
> None.
> 
> Disclaimers and notes
> --
> 
> We would like to remind you that Qubes OS has been designed under the
> assumption that all relevant infrastructure is permanently
> compromised.  This means that we assume NO trust in any of the servers
> or services which host or provide any Qubes-related data, in
> particular, software updates, source code repositories, and Qubes ISO
> downloads.
> 
> This canary scheme is not infallible. Although signing the declaration
> makes it very difficult for a third party to produce arbitrary
> declarations, it does not prevent them from using force or other
> means, like blackmail or compromising the signers' laptops, to coerce
> us to produce false declarations.
> 
> The news feeds quoted below (Proof of freshness) serves to demonstrate
> that this canary could not have been created prior to the date stated.
> It shows that a series of canaries was not created in advance.
> 
> This declaration is merely a best effort and is provided without any
> guarantee or warranty. It is not legally binding in any way to
> anybody. None of the signers should be ever held legally responsible
> for any of the statements made here.
> 
> Proof of freshness
> ---
> 
> Thu, 09 Apr 2020 01:16:49 +
> 
> Source: DER SPIEGEL - International 
> (https://www.spiegel.de/international/index.rss)
> Politicians Call for Fewer Climate Protections During Coronavirus Crisis
> Coronavirus: En refusant les eurobonds, l’Allemagne fait preuve d’égoïsme, 
> d’obstination et de lâcheté
> Coronavirus: El rechazo alemán de los eurobonos es insolidario, mezquino y 
> cobarde
> New York City: Eight Days in the New Capital of Corona
> Coronavirus: Il rifiuto tedesco degli Eurobond è non solidale, gretto e 
> vigliacco
> 
> Source: NYT > World News 
> (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
> Saudi Arabia, Hit by Coronavirus, Declares Cease-Fire in Yemen: Live Updates
> Saudi Arabia Declares Cease-Fire in Yemen, Citing Fears of Coronavirus
> Eight U.K. Doctors Died From Coronavirus. All Were Immigrants.
> Some of Europe, ‘Walking a Tightrope,’ Will Loosen Coronavirus Restrictions
> China’s Coronavirus Battle Is Waning. Its Propaganda Fight Is Not.
> 
> Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
> Coronavirus: WHO chief urges end to 'politicisation' of virus
> Bernie Sanders suspends presidential campaign
> Yemen: Saudi-led coalition announces ceasefire
> Woman who revealed Clinton-Lewinsky scandal dies
> Coronavirus: How Russia's ballet wasn't shut down despite lockdown
> 
> Source: Reuters: World News (http://feeds.reuters.com/reuters/worldnews)
> WHO head defends handling of coronavirus pandemic against Trump criticism
> Brazil turns to local industry to build ventilators as China orders fall 
> through
> Ecuador's Moreno calls for probe into handling of corpses in coronavirus 
> outbreak
> Australian police take 'black box' off cruise ship in coronavirus homicide 
> probe
> Mexico registers 3,181 cases of coronavirus and 174 deaths
> 
> Source: Blockchain.info
> 000d88e12aee57e8aa90ceea6b74b962a39427c5f2fdb6d0
> 
> 
> Footnotes
> --
> 
> [1] This file should be signed in two ways: (1) via detached PGP
> signatures by each of the signers, distributed together with this
> canary in the qubes-secpack.git repo, and (2) via digital signatures
> on the corresponding qubes-secpack.git repo tags. [2]
> 
> [2] Don't 

Re: [qubes-devel] Re: Refactoring PDF Converter (and other scripts)

[Demi M. Obenour]

On 2020-04-02 22:39, Jason Phan wrote:
> On Apr 02, Demi M. Obenour wrote:
>>>> I had a problem where a converted PDF didn’t print properly,
>>>> probably due to missing DPI information.
>> Original converter
> 
> I'll print some stuff tomorrow and see what's what.

Thank you.

>> Xen is the main sandboxing, but additional sandboxing is definitely 
>> worthwhile.
> 
> I think general security mechanisms like that should probably be implemented 
> outside of qvm-convert-pdf though. Can't say whether we should though, 
> hardening a DispVM seems unecessary to me given how they're typically used.
> 
>    Jason Phan

More than anything else, it is a matter of making an attacker’s
life as hard as possible.  Adding a seccomp filter and namespacing
(via bubblewrap) is cheap.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b3e27ff7-059e-5370-cd6d-84158f86137d%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Refactoring PDF Converter (and other scripts)

[Demi M. Obenour]

On 2020-04-02 21:48, Jason Phan wrote:
> On Apr 02, Demi M. Obenour wrote:
>> I had a problem where a converted PDF didn’t print properly,
>> probably due to missing DPI information.
> 
> :O Is this with the Python port or the original converter?

Original converter

>> Another suggestion would be to jail the server in a sandbox using seccomp 
>> and namespaces, to make it harder for the server to attack Linux (and then 
>> Xen).
> 
> I thought the server being in a DispVM was our sandboxing. Or are you saying 
> in addition to that we should use seccomp/namespaces.
> 
>    Jason Phan

Xen is the main sandboxing, but additional sandboxing is definitely
worthwhile.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/640bd552-695b-28ec-942f-7309de5f5ed8%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Refactoring PDF Converter (and other scripts)

[Demi M. Obenour]

On 2020-04-02 21:46, Marek Marczykowski-Górecki wrote:>> Marek: is OCR on a 
converted PDF safe? Being able to reconstruct the
>> text is very much useful. 
> 
> That's a tricky question. qpdf-convert-server have significant control
> over input for such OCR (within realm of valid image data). So, given
> complexity of OCR software, I think nothing can be completely ruled out. 
> But also, I think (because of guaranteed proper input format) some
> catastrophic failure is unlikely.
> 
> In fact, I consider another method for preserving text data. Enhanced
> "simpler representation", which besides pure image, contains also text
> annotations. Thing like series of (coordinates, text) pairs. This needs
> careful design, to be reasonably safe (for example defining what "text"
> could contain, to not risk re-interpreting it as something else in the
> PDF, or some intermediate tool).

That would be absolutely awesome.  The biggest problem with
qvm-convert-pdf is the loss of text, and keeping the text would make
it far more usable.
 
>> Also, could this be integrated into CUPS?
> 
> I don't see why not.

Given how insecure printers are, this would be a very good idea.
Perhaps similar technology (possibly based on something like seL4
instead of Xen) could be incorporated into printers themselves.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c9c61ca0-3d6f-6694-39de-9382ea27f98f%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Refactoring PDF Converter (and other scripts)

[Demi M. Obenour]

On 2020-04-02 21:34, Jason Phan wrote:
> On Apr 02, Demi M. Obenour wrote:
>> A converted PDF should print just as well as the original.
> 
> Overall, the resulting PDF is just a tad bit lower quality than the original, 
> but still perfectly readable on screen/paper imo. I've tried messing around 
> with ImageMagick's parameters but someone with more knowledge about images 
> will have to step in if a significant improvement in quality is expected.
I had a problem where a converted PDF didn’t print properly,
probably due to missing DPI information.

>> OCR
> 
> Ooh! I wanted to do this too.
> 
>    Jason Phan

That sounds awesome!

Another suggestion would be to jail the server in a sandbox using
seccomp and namespaces, to make it harder for the server to attack
Linux (and then Xen).

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e0a4f1d1-a863-4df6-a892-02efc9866e28%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Refactoring PDF Converter (and other scripts)

[Demi M. Obenour]

On 2020-04-02 21:12, Jason Phan wrote:
> On Apr 03, Marek Marczykowski-Górecki wrote:
>> The idea is to verify if they are non-malicious, not necessary "correct". 
>> So, as soon you verify they conform to the expected format, you can drop 
>> "untrusted_" prefix.
> 
> Ah, gotcha.
>> Also, be careful about things like server sending too much or too little 
>> data.
> 
> Oof, my brain is blanking. Could you give some examples of what could happen 
> if a server sent too much/little?
> 
> Thanks btw for all the help!
> 
>    Jason Phan
> 

Also, don’t forget about other use-cases, like printing or OCR.
A converted PDF should print just as well as the original.

Marek: is OCR on a converted PDF safe?  Being able to reconstruct the
text is very much useful.  Also, could this be integrated into CUPS?

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/daafcd3c-d34f-67b1-8a5e-79393e1e8917%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Has Xen’s security posture improved over the years?

[Demi M. Obenour]

The Qubes project has criticized
Xen’s approach to security in the past
(https://lists.xen.org/archives/html/xen-devel/2015-11/msg00601.html).
Has the Xen project made improvements since then?

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/315b400e-bd61-4c5a-b2c1-88384c4de067%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Intel microcode update

[Demi M. Obenour]

On 2020-02-04 22:26, Marek Marczykowski-Górecki wrote:
> On Tue, Feb 04, 2020 at 09:46:10PM -0500, Demi M. Obenour wrote:
>> What is the status of the Intel microcode update?  It has already
>> been released for Windows.
> 
> Can you give some source for this information?
> There is no update in the Intel advisory[1], and also there is no new
> content in microcode repository[2].
> 
> [1] 
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00329.html
> [2] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-File
There was a recent Microsoft security advisory for Windows, if I recall 
correctly.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/29516d1a-1934-8952-389f-199f03f07c40%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Intel microcode update

[Demi M. Obenour]

What is the status of the Intel microcode update?  It has already
been released for Windows.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/979f9309-4b60-8f69-05cb-b9f33b22872c%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: GVT-g Discussion

[Demi M. Obenour]

On 2020-01-02 15:33, Kardykov Ivan wrote:
> Sorry for that bumping, but looks like my posts from work domain (tabit.pro) 
> stucked at moderate or
> spam checks.. So my message was about GVT-g.
> 
> We have some success with adaptation Intel gtv-g technology to Qubes OS.
> At now it is rather proof of concept state, but it probably could help
> to test guivm features and discuss of applicability in practice.
> 
> In this [1] repository we placed specs and patches to build core Qubes
> components with ability to run and work with GPU accelerated VM. We
> oriented to Fedora 29 dom0 and Xen 4.12 versions with plans of 4.1
> compatibility. Now it is up to Fedora 31 and Xen 4.13 and we will get to
> this versions in some time.
> 
> We made and adapted patches to xen, kernel, libvirt, qemu to dom0 and
> xorg dummy driver to guest environment. Our work mostly based on Intel
> [2][3] and XenServer [4] public repositories.
> 
> The most controversial question is probably running qemu without any
> restrictions, but there are several ways to improve it.

As Marek has stated before, this is a non-starter.  QEMU is not
considered trusted.  Xen’s attack surface is already too high.

The approach I would like to see is a paravirtualized approach
similar to Genode’s: a small (<10K SLOC), auditable (ideally
formally verified) driver running in dom0 and/or its own domain that
communicates with a paravirtualized driver in the VMs.  Any needed
emulation is done in the stubdomain.  This is likely to be difficult
for many reasons, but is the only way that I see can hardware
accelerated graphics being secure enough for Qubes with commodity
hardware.  If you are willing to pay literally thousands of dollars
for server-grade GPUs, then SR-IOV and friends become options, which
make secure hardware acceleration much easier.  However, those are
far too expensive for virtually all Qubes users.  In particular,
they are far more expensive than just buying another computer for
graphics-intensive activities.

The main activities I know of that need hardware-accelerated graphics,
and which a Qubes user is likely to want to partake in, are gaming
and GPGPU.  Video games, in particular, should be considered completely
untrusted, and so need to be walled off as tightly as possible.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/430e381e-7118-5660-38b5-9db65399b02d%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Attaching files with qvm-block: is there a security problem with this workaround?

[Demi M. Obenour]

On 2019-12-25 03:33, Marek Marczykowski-Górecki wrote:
> On Wed, Dec 25, 2019 at 03:00:36AM +, 'heombeeh' via qubes-devel wrote:
>> Thanks a lot for these clarifications.
> 
>> Based on your recommendation against handling filesystem images within dom0, 
>> I'm thinking that I can instead create a "light storage" AppVM. This VM can 
>> simply have a directory of sparse files together with associated loop 
>> devices, and I can then attach them to other AppVMs normally using qvm-block.
> 
> Sounds good.
> 
>> However, just as in dom0, it will be good to protect this "light storage" VM 
>> from those client VMs that utilize its filesystem blocks. Can I protect this 
>> VM similarly to how dom0 is protected by using similar udev rules?
> 
>> For example, suppose I keep my sparse files in 
>> `/home/user/myimages/{name}/disk.img`, and then add the following udev rule:
> 
>> $ cat /etc/udev/rules.d/00-qubes-ignore-devices.rules
>> ACTION!="remove", SUBSYSTEM=="block", KERNEL=="loop*", 
>> ATTR{loop/backing_file}=="*/myimages/*/*.img*", 
>> ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1", 
>> ENV{UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG}="1"
> 
> That should do.
> It is a bit fragile, because newer udev version could ship rules
> ignoring those settings (yet another reason why updating dom0 isn't
> straightforward), but in the current version it is still effective.
> 
>> With this active, it seems to work:
> 
>> $ sudo losetup --find --show ./myimages/blah/disk.img
>> /dev/loop0
>> $ lsblk -f /dev/loop?
>> NAME  FSTYPE LABEL UUID MOUNTPOINT
>> loop0
> 
> 
>> Is this enough to protect this "light storage" VM from the other VMs that 
>> attach to the filesystem images?
>> Are there any other precautions that I should configure for this VM?
> 
>> As I encountered with dom0, using the rule above prevents Qubes from 
>> detecting the loop devices associated with the disk image file. Using 
>> similar commands as shown in the docs you linked, I fixed this with:
> 
>> $ qubesdb-write /qubes-block-devices/loop0/desc 'disk.img'
>> $ qubesdb-write /qubes-block-devices/loop0/size 536870912
>> $ qubesdb-write /qubes-block-devices/loop0/mode w
> 
>> After doing this `qvm-block ls` detects the new disk, but the Qubes GUI 
>> (i.e. the widget in the top right corner of the window manager) does not 
>> detect the change. How can I trigger a "refresh" so that the GUI sees my 
>> changes to qubesdb?
> 
> Do empty write to /qubes-block-devices:
> 
> qubesdb-write /qubes-block-devices ''
> 
> 

Is it safe to use the hotplug scripts built in to QubesOS?  I am
thinking of writing a udev rule that prevents the loop device from
being parsed, but still runs the Qubes hotplug scripts so that the
device shows up in the GUI.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/a88cbd80-e6e8-4831-5f25-d1857b991816%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Next major release of Qubes OS

[Demi M. Obenour]

On 2019-12-05 21:25, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 05, 2019 at 04:27:33PM -0800, John Smiley wrote:
>> I've read various things that hint at some major changes coming to Qubes OS
>> and so I have been holding off continuing to invest my time in diving deep
>> into the current implementation.  In particular, I've seen indications that
>> Qubes is migrating away from Xen and toward KVM.
> 
> This is very much not true. We are considering adding support for KVM,
> but Xen isn't going away anytime soon.
> 
>> Xen seems to be "mostly
>> dead" as Billy Crystal would say and many services either already have or
>> are well on their way to replacing it with KVM.
> 
> Well, yes and no, mostly no. There are some services that are starting
> to use KVM, but the same applies to Xen. I think you mostly have Amazon in
> mind, which indeed started to have some VMs on KVM. On the other
> hand, this year their contributions to open source Xen have very much
> intensified, including development of many new features. Besides that,
> Xen is getting popularity in automotive sector, and there are ongoing
> efforts for safety certification. Yet another thing that is totally
> unrealistic with KVM architecture.

Sadly, the safety certification is focused on ARM, but I would love
to see this on x86 as well.
 
> You may want to look at Xen Summit recap:
> https://xenproject.org/2019/07/29/xen-project-developer-and-design-summit-recap/
> 
>> There also seems to be
>> movement toward more lightweight solutions for isolating processes than
>> virtual machines, as seen in Subgraph/Citadel/Oz (which oddly have not seen
>> much attention in recent years if GitHub is anything to go by).
> 
> Well, people are using containers for a long time already. While indeed
> it is much more lightweight, this approach have also severe limits -
> everything running on the same (huge, monolithic) kernel. Leaving alone
> much bigger attack surface of all the syscalls (which you can slightly
> mitigate with seccomp and similar techniques), this makes it impossible
> to isolate kernel components from each other. Including drivers, network
> stack etc.

Agreed.  In some cases, one can get very strong isolation because
only a very small number of syscalls are required, but those cases
are rare for general-purpose software.

>> I'm sure I'm not alone when I say I would like to hear from the Qubes
>> developers what the roadmap looks like in this regard.  Some of us would
>> probably be more inclined to devote our time to assisting you if we knew
>> such projects were in the works.
> 
> The current plan for major features of Qubes OS 4.1 is:
>  - experimental GUI VM and Audio VM (very limited and not yet ready for
>daily usage)
>  - new qrexec policy format and significant qrexec performance
>improvements
>  - major improvement for UEFI compatibility (grub2-efi is back, some
>changes in Xen to make it more uniform with Linux)
>  - as usual, updated templates and dom0 (but still Fedora)

Will UEFI compatibility also include providing UEFI to VMs?

I will work on my socket-based qrexec PR this weekend.

> You can also see draft release notes:
> https://github.com/QubesOS/qubes-doc/pull/828/files
> 
> I'd say the above is 80-90% done. There is a possibility the first
> release candidate will be already this month.
> 
> In the meantime we're also working on a reliable GPU passthrough with
> focus on Intel, without sacrificing security much (specifically, without
> running unsandboxed qemu), but it's not going to be part of R4.1 yet.
> Having that, and more tested and improved GUI VM integration would allow
> to make it default and greatly reduce size of dom0.
> 
> With such reduced dom0, we can consider another distribution there. It
> hasn't been decided on a specific one yet, but I'm strongly considering
> Yocto/OpenEmbedded - for its ability to build small system. Maybe even
> small enough to fit in RAM, which would allow running dom0 disk-less,
> opening a path to many cool features like storage domain. But it would
> also allow easier code sharing with OpenXT project.
> Anyway, at this point, user would not directly interact with dom0, so it
> will be very much transparent (i.e. even if that would be Debian - which
> is another option - you won't have a chance to call apt-get there). What
> user will interact with, is a GUI VM, which would be much more flexible
> in distribution choice (basically - whatever template we currently
> support).

How will debugging of dom0 work?  Obviously, nobody who is not working
on Qubes itself will need to do this, but you probably will.

> But also, with GUI VM separated from all-powerful dom0, we can consider
> some options for video acceleration access for selected VMs. There are
> various paths here to be explored, with different hardware requirements,
> and different security properties. But that's for late 2020 at the earliest.

That is very exciting!  I understand that that will take a 

Re: [qubes-devel] QSB #52: Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)

[Demi M. Obenour]

On 2019-11-19 03:51, Andrew David Wong wrote:
> On 2019-11-18 8:07 AM, Demi M. Obenour wrote:
>> On 2019-10-31 12:12, Marek Marczykowski-Górecki wrote:
>>> Dear Qubes Community,
>>>
>>> We have just published Qubes Security Bulletin (QSB) #052: Xen issues 
>>> affecting PCI passthrough and PV domains
>>>  (XSA-299, XSA-302). 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 #052 in the qubes-secpack:
>>>
>>> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-2019.txt
>>>
>>> Learn about the qubes-secpack, including how to obtain, verify, and read
>>> it:
>>>
>>> https://www.qubes-os.org/security/pack/
>>>
>>> View all past QSBs:
>>>
>>> https://www.qubes-os.org/security/bulletins/
>>>
>>> View the Xen Security Advisory (XSA) Tracker:
>>>
>>> https://www.qubes-os.org/security/xsa/
>>>
>>> [...]
>>>
> 
>> Enigmail reports that this message has a bad signature.  Is this
>> because I am using an incorrect key to verify it?
> 
>> Sincerely,
> 
>> Demi
> 
> 
> It verifies correctly for me via Enigmail 2.1.2 on Thunderbird 68.1.1.
> As a reminder, you can always verify QSBs via the Qubes Security Pack:
> 
> https://www.qubes-os.org/security/pack/
> 
> 
> 

Thanks Andrew.  The problem was that I had not trusted the specific
signing key Marek used.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b17d7787-b5fb-f7b5-0af0-68bccd847be5%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] QSB #52: Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)

[Demi M. Obenour]

On 2019-10-31 12:12, Marek Marczykowski-Górecki wrote:
> Dear Qubes Community,
> 
> We have just published Qubes Security Bulletin (QSB) #052: Xen issues 
> affecting PCI passthrough and PV domains
>  (XSA-299, XSA-302). 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 #052 in the qubes-secpack:
> 
> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-2019.txt
> 
> Learn about the qubes-secpack, including how to obtain, verify, and read
> it:
> 
> https://www.qubes-os.org/security/pack/
> 
> View all past QSBs:
> 
> https://www.qubes-os.org/security/bulletins/
> 
> View the Xen Security Advisory (XSA) Tracker:
> 
> https://www.qubes-os.org/security/xsa/
> 
> ```
> 
> 
>  ---===[ Qubes Security Bulletin #52 ]===---
> 
>  2019-10-31
> 
> 
> Xen issues affecting PCI passthrough and PV domains (XSA-299, XSA-302)
> 
> Summary
> 
> 
> On 2019-10-31, the Xen Security Team published the following Xen
> Security Advisories (XSAs):
> 
> 
> XSA-299 [1] "Issues with restartable PV type change operations":
> | To avoid using shadow pagetables for PV guests, Xen exposes the actual
> | hardware pagetables to the guest.  In order to prevent the guest from
> | modifying these page tables directly, Xen keeps track of how pages are
> | used using a type system; pages must be "promoted" before being used
> | as a pagetable, and "demoted" before being used for any other type.
> | Xen also allows for "recursive" promotions: i.e., an operating system
> | promoting a page to an L4 pagetable may end up causing pages to be
> | promoted to L3s, which may in turn cause pages to be promoted to L2s,
> | and so on.  These operations may take an arbitrarily large amount of
> | time, and so must be re-startable.
> |
> | Unfortunately, making recursive pagetable promotion and demotion
> | operations restartable is incredibly complicated, and the code
> | contains several races which, if triggered, can cause Xen to drop or
> | retain extra type counts, potentially allowing guests to get write
> | access to in-use pagetables.
> |
> | A malicious PV guest administrator may be able to escalate their
> | privilege to that of the host.
> 
> XSA-302 [2] "passed through PCI devices may corrupt host memory after
> deassignment":
> | When a PCI device is assigned to an untrusted domain, it is possible
> | for that domain to program the device to DMA to an arbitrary address.
> | The IOMMU is used to protect the host from malicious DMA by making
> | sure that the device addresses can only target memory assigned to the
> | guest. However, when the guest domain is torn down the device is
> | assigned back to dom0, thus allowing any in-flight DMA to potentially
> | target critical host data.
> |
> | An untrusted domain with access to a physical device can DMA into host
> | memory, leading to privilege escalation.
> 
> 
> Impact
> ===
> 
> XSA-299 applies only to PV domains. Most of the domains in Qubes 4.0 are
> PVH or HVM domains and are therefore not affected by XSA-299. However,
> PV domains are still supported in Qubes 4.0, and they are specifically
> used to host Qemu-instance-supporting HVM domains.
> 
> In the default Qubes 4.0 setup, several attacks would have to be chained
> together in order to exploit this vulnerability. Specifically, an
> attacker would have to:
> 
> 1. Take control of an HVM domain, e.g., sys-usb, sys-net, or a
>user-created HVM domain. (Most user domains are PVH and are therefore
>not affected.)
> 
> 2. Successfully attack a Qemu instance running in an associated PV
>stubdomain.
> 
> 3. Finally, find some way to exploit the vulnerability described in
>XSA-299.
> 
> Moreover, since this vulnerability is a race condition, it is an
> unreliable attack vector in real world scenarios.
> 
> XSA-302 also affects a limited set of domains in Qubes, namely, only
> those with PCI devices assigned (sys-net and sys-usb in the default
> configuration).
> 
> In order to exploit this vulnerability, an attacker would have to
> control a cooperating device that could be programmed to perform a DMA
> (direct memory access) attack with a sufficient delay (on the order of
> seconds) such that the device had been reassigned to dom0 by the time
> the attack occured.
> 
> Depending on internal connections, it may be also necessary for the
> cooperating device to lack proper support for Function Level Reset
> (FLR). (Most USB controllers do, in fact, lack proper support for FLR.)
> 
> While XSA-299 is unreliable to exploit in practice, XSA-302 can be
> reliably exploited so long as all the aforementioned conditions are met.
> 
> 
> Discussion
> ===
> 
> The patches below isolate PCI devices out of dom0 using IOMMU, even
> after those devices have been de-assigned from other domains (typically
> less trusted domains like sys-net and 

Re: [qubes-devel] libusb and QubesOS USB pass through don’t work together

[Demi M. Obenour]

On 2019-11-09 19:45, Marek Marczykowski-Górecki wrote:
> On Sat, Nov 09, 2019 at 07:18:40PM -0500, Demi M. Obenour wrote:
>> I was trying to use adb with QubesOS’s USB passthrough, and I was
>> not able to get it to work.
> 
> From what I remember from my experiments with adb and qvm-usb, USBIP
> don't pass through device reset requests. And even when device is reset
> externally, qvm-usb won't assign it back automatically. The later thing
> may be actually a good thing, to prevent device suddenly changing its
> identification - like you think you attach some harmless device, but it
> switches to some exotic device with a known bug in its driver. But it
> breaks this use case.
> 
>> According to a post on LKML, the USBIP driver (used by QubesOS
>> USB passthrough) and libusb are not meant to work together.
>> One alternative would be to use qemu in the stubdomain to present an
>> emulated PCI USB device, instead of requiring USBIP support in the
>> guest kernel.  This would also allow USB passthrough to work to VMs
>> that do not support USBIP, or indeed even qrexec.
> 
> This is interesting idea and indeed something we consider for non-Linux
> VMs. It won't help you for PVH domains though, as there is no qemu
> involved. Anyway, we'd be very welcome in a contributed patches in this
> area.

I would love to send them, but right now I am rather short on time.
I still have the socket-based qrexec patch to finish first.

> 
>> Right now, I plan on using adb in sys-usb itself, after blacklisting
>> drivers for USB devices not in use.  There ought to be a better way.
>> IMO, sys-usb should *only* support USBIP, with the real protocol
>> handling done in other domains, and the resulting devices (be they
>> block devices or others) attached to yet other domains.
> 
> Given performance and complexity of USB vs block protocols, IMO handling
> mass-storage directly in sys-usb and connecting it further as block
> device is a better idea. But otherwise I agree.
> 
> Also, disposable sys-usb is a good idea when you use more complex
> devices directly in sys-usb:
> https://www.qubes-os.org/doc/disposablevm-customization/#using-static-disposablevms-for-sys-
> 
> Using intermediate DisposableVM for "unpacking" USB protocol to
> something simpler would work in a principle, but has two major usability
> issues:
>  - DisposableVM (or more specifically: Linux VM) takes some precious
>memory
>  - USBIP is slow

That is a very good point.  Both would be averted if we ran on a
microkernel, such as seL4, and had drivers that ran directly on the
microkernel.  Alas, we are stuck with Xen and Linux for the time being.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/2e7d9b97-1795-9eda-cc2d-5737609052d7%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] libusb and QubesOS USB pass through don’t work together

[Demi M. Obenour]

I was trying to use adb with QubesOS’s USB passthrough, and I was
not able to get it to work.

According to a post on LKML, the USBIP driver (used by QubesOS
USB passthrough) and libusb are not meant to work together.
One alternative would be to use qemu in the stubdomain to present an
emulated PCI USB device, instead of requiring USBIP support in the
guest kernel.  This would also allow USB passthrough to work to VMs
that do not support USBIP, or indeed even qrexec.

Right now, I plan on using adb in sys-usb itself, after blacklisting
drivers for USB devices not in use.  There ought to be a better way.
IMO, sys-usb should *only* support USBIP, with the real protocol
handling done in other domains, and the resulting devices (be they
block devices or others) attached to yet other domains.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/356ba859-0456-38a0-631c-77266e3865f0%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Gigantic kernel updates taking 25+minutes to dl

[Demi M. Obenour]

On 2019-09-10 20:36, Chris Laprise wrote:
> On 9/10/19 8:22 PM, Chris Laprise wrote:
>> On 9/10/19 6:43 PM, Marek Marczykowski-Górecki wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On Tue, Sep 10, 2019 at 06:33:28PM -0400, Chris Laprise wrote:
 4.19.36 = 253MB
 4.19.43 (vm) = 513MB
 4.19.67 (vm) taking >25min to download at 120kBytes / sec.

 What is going on?
>>>
>>> The sizes are about uncompressed data, rpm packages are much smaller
>>> (60-80MB). As for the download speed, are you using Tor/Whonix? Or
>>> otherwise slow network?
>>
>> I'm using a fast VPN connection, as I always have. Right now the repo 
>> updates are topping out at 320kBytes/sec and data is 1100kBytes/sec, so 
>> something was slowing me down.
>>
>> dnf showed qubes-kernel-vm accumulated download size at about 220MB and 75% 
>> before I aborted it. I believe that is the compressed rpm size. Even at the 
>> fast dl rate, its a long time (and much disk space) if there are multiple 
>> versions coming down.
>>
> 
> For context, even when my link appeared to be slow, I had FIVE templates 
> update completely (with kernels) before dom0 was half done.
> 
What are your memory settings for sys-firewall (or whatever your updatevm is)?  
If it is too low, it will swap, which makes it very slow.

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ddbe7fcd-e9a1-dffd-a5a2-43fac1b137b4%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Announcement: Insurgo PrivacyBeast X230 Laptop meets and exceeds Qubes 4.0 hardware certification

[Demi M. Obenour]

On 7/19/19 12:19 AM, Andrew David Wong wrote:
>   - Coreboot [6] initialization for the x230 is binary-blob-free,
> including native graphic initialization. Built with the
> Heads [7] payload, it delivers an Anti Evil Maid (AEM) [8]-like
> solution built into the firmware. (Even though our requirements [4]
> provide an exception for CPU-vendor-provided blobs for silicon and
> memory initialization, Insurgo exceeds our requirements by insisting
> that these be absent from its machines.)
> 
Is the RAM vulnerable to Rowhammer attacks?  My understanding is that
recent motherboards mitigate these attacks by increasing the refresh
rate, but I am not sure if this one can.

Sincerely,

Demi

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/2468447f-b6ca-8496-f2ea-330a680f52a8%40gmail.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] QubesOS 4.1 status

[Demi M. Obenour]

On 6/5/19 9:47 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Jun 05, 2019 at 05:28:44AM -0700, sagar acharya wrote:
>> Dear Marek, it would be fantastic if PCI passthrough becomes trivial in 
>> qubes R4.1. Using graphic cards is so central in games and computation 
>> intensive things on GPU. Having it in dom0 and not contained in other VMs 
>> made me switch back to another OS.
> 
> Simple PCI passthrough works well. The problematic case if for GPU,
> which in practice are very non-standard PCI devices, with a lot of
> vendor-specific quirks. Anyway yes, making it work reliably is on the
> roadmap, but may not be fully ready in R4.1.
> 
> 

What is the security status of GPU pass-through?  It would be amazing
if GPU pass-through could be a fully security-supported feature,
although I understand it might not be practical.  Most uses for GPU
pass-through are for games, which are not trusted at all.

If the security risks of (secondary) GPU pass-through could be
eliminated, it would be possible to have an “Allow this VM to use
hardware-accelerated graphics” checkbox in the GUI, which would be
awesome.  Obviously, I am only referring to GPUs that do *not* have
control over the monitor.

Sincerely,

Demi

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


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Intergrating NVIDIA or AMD 3D Acceleration into Qubes-GUI

[Demi M. Obenour]

On 4/28/19 11:39 PM, Jean-Philippe Ouellet wrote:
> On Sun, Apr 28, 2019 at 10:37 AM Dylanger Daly  wrote:
>> On Saturday, April 27, 2019 at 11:10:50 AM UTC+1, Marek Marczykowski-Górecki 
>> wrote:
>>> On Thu, Apr 25, 2019 at 08:59:14AM -0700, Dylanger Daly wrote:
 On Thursday, April 25, 2019 at 4:11:28 PM UTC+1, Dylanger Daly wrote:
> On Thursday, April 25, 2019 at 2:31:24 PM UTC+1, Dylanger Daly wrote:
>> On Thursday, April 25, 2019 at 11:34:18 AM UTC+1, Dylanger Daly wrote:
>>> On Tuesday, April 23, 2019 at 12:08:14 PM UTC+1, Dylanger Daly wrote:
 Hey Guys,

 I've managed to successfully pass my MUXless (No Output) NVIDIA MX150 
 into a Fedora HVM - with the Proprietary NVIDIA Driver.

 [user@fedora-standalone ~]$ sudo nvidia-smi
 Tue Apr 23 11:28:54 2019
 +-+
 | NVIDIA-SMI 418.56   Driver Version: 418.56   CUDA Version: 
 10.1 |
 |---+--+--+
 | GPU  NamePersistence-M| Bus-IdDisp.A | Volatile 
 Uncorr. ECC |
 | Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util  
 Compute M. |
 |===+==+==|
 |   0  GeForce MX150   Off  | :00:05.0 Off |   
N/A |
 | N/A   50CP0N/A /  N/A |  0MiB /  2002MiB |  0%  
 Default |
 +---+--+--+

 +-+
 | Processes:   GPU 
 Memory |
 |  GPU   PID   Type   Process name 
 Usage  |
 |=|
 |  No running processes found  
|
 +-+


 However when attempting to add the dGPU into the appVM's Xorg Server, 
 via adding

 Section "Device"
 Identifier "Device0"
 Driver "nvidia"
 BusID  "PCI:0:5:0"
 VendorName "NVIDIA Corporation"
 EndSection

 (Confirmed BusID)

 I get the following error in Xorg:


 [ 8.444] (II) LoadModule: "nvidia"
 [ 8.444] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
 [ 8.454] (II) Module nvidia: vendor="NVIDIA Corporation"
 [ 8.454]compiled for 4.0.2, module version = 1.0.0
 [ 8.454]Module class: X.Org Video Driver
 [ 8.455] (II) LoadModule: "qubes"
 [ 8.455] (II) Loading /usr/lib64/xorg/modules/drivers/qubes_drv.so
 [ 8.456] (II) Module qubes: vendor="X.Org Foundation"
 [ 8.456]compiled for 1.20.4, module version = 0.0.1
 [ 8.456]Module class: X.Org XInput Driver
 [ 8.456]ABI class: X.Org XInput driver, version 24.1
 [ 8.456] (II) DUMMYQBS: Driver for Dummy chipsets: dummy
 [ 8.457] (II) NVIDIA dlloader X Driver  418.56  Fri Mar 15 
 12:37:35 CDT 2019
 [ 8.457] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
 [ 8.458] (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not 
 permitted
 [ 8.458] (EE)
 Fatal server error:
 [ 8.458] (EE) xf86OpenConsole: Switching VT failed
 [ 8.458] (EE)
 [ 8.458] (EE)
 Please consult the Fedora Project support
  at http://wiki.x.org
  for help.
 [ 8.458] (EE) Please also check the log file at 
 "/home/user/.local/share/xorg/Xorg.0.log" for additional information.
 [ 8.458] (EE)
 [ 8.458] (WW) xf86CloseConsole: KDSETMODE failed: Operation not 
 permitted
 [ 8.458] (WW) xf86CloseConsole: VT_SETMODE failed: Operation not 
 permitted
 [ 8.458] (WW) xf86CloseConsole: VT_ACTIVATE failed: Operation not 
 permitted
 [ 8.459] (EE) Server terminated with error (1). Closing log file.




 When the NVIDIA Device isn't present:


 [11.096] (II) LoadModule: "dummyqbs"
 [11.096] (II) Loading 
 /usr/lib64/xorg/modules/drivers/dummyqbs_drv.so
 [11.097] (II) Module dummyqbs: vendor="X.Org Foundation"
 [11.097]compiled for 1.20.4, module version = 

Re: [qubes-devel] What happened to the tagging of unsafe files?

[Demi M. Obenour]

On 4/17/19 1:57 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Apr 17, 2019 at 12:50:23PM +0100, unman wrote:
>> On Mon, Apr 01, 2019 at 11:55:42PM -0700, Elias Mårtenson wrote:
>>> I'm referring to the feature that was developed as part of GSOC about a 
>>> year and a half ago. It involved tagging some files as being unsafe, and 
>>> would cause them to be opened in a dispvm by default.
>>>
>>> Was that work ever merged? I've been looking forward to this feature for 
>>> the last year or so.
>>>
>>> Regards,
>>> Elias
>>>
>>> -- 
> 
>> I think you mean this - https://blog.amorgan.xyz
> 
>> I think the last update was in October 2017, but it seemed to stall with
>> developing patches for Dolphin and improving nautilus extensions. So,
>> afaik, never reached stage that it could be merged.
> 
> Yes, that's exactly the case. There were problems with getting
> nautilus/Dolphin extensions in a shape acceptable to upstream project.
> 
> 

Would it be possible for QubesOS to merge the patches into its own
branch, or would that require resources that ITL doesn’t have?

Sincerely,

Demi

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


signature.asc
Description: OpenPGP digital signature

[qubes-devel] QubesOS 4.1 status

[Demi M. Obenour]

What is the status of QubesOS 4.1?  I see some commits on GitHub, but nothing 
on the website.

Demi


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


signature.asc
Description: OpenPGP digital signature