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

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

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

View QSB #37 in the qubes-secpack:

<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.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 XSA-254 in the XSA Tracker:

<https://www.qubes-os.org/security/xsa/#254>

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

January 11, 2018


Information leaks due to processor speculative execution bugs

Summary
========

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

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

Practical impact and limiting factors for Qubes users
======================================================

## Fully virtualized VMs offer significant protection against Meltdown

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

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

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

## All attacks are read-only

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

## Only running VMs are vulnerable

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

## PGP and other cryptographic keys are at risk

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

## Disk encryption and screenlocker passwords are at risk

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

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

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

Additional remedies available to Qubes users
=============================================

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

Additionally, for some of the VMs that must run anyway (e.g. networking
and USB qubes), it is possible to recreate the VM each time the user
suspects it may have been compromised, e.g. after disconnecting from a
less trusted Wi-Fi network, or unplugging an untrusted USB device. In
Qubes 4.0, this is even easier, since Disposable VMs can now be used for
the networking and USB VMs (see [10]).

The Qubes firewalling and networking systems also make it easy to limit
the networking resources VMs can reach, including making VMs completely
offline. While firewalling in Qubes is not intended to be a
leak-prevention mechanism, it likely has this effect in a broad class
class of attack scenarios. Moreover, making a VM completely offline
(i.e. setting its NetVM to "none") is a more robust way to limit the
ability of an attacker to leak secrets stolen from memory to the outside
world. While this mechanism should not be considered bullet-proof -- it
is still possible to mount a specialized attack that exploits a covert
channel to leak the data -- it could be considered as an additional
layer of defense.

Finally, Qubes offers mechanisms to allow for additional protection of
user secrets, especially cryptographic keys, such as PGP keys used for
encryption and signing. Qubes Split GPG [6] allows the user to keep
these keys in an isolated VM. So, for example, the user might be running
her "development" qube in parallel with a compromised qube, while
keeping the GPG backend VM (where she keeps the signing key that she
uses to sign her software releases) shut down most of the time (because
it's only needed when a release is being made). This way, the software
signing keys will be protected from the attack.

The user could take this further by using Qubes Split GPG with a backend
qube running on a physically separate computer, as has been demonstrated
with the Qubes USB Armory project [7].

(Proper) patching
==================

Mitigations against the CPU bugs discussed here are in development but
have not yet been released. The Xen Project is working on a set of
patches (see XSA 254 [5] for updates). At the same time, we are working
on similar mitigations where feasible.

## Qubes 4.0

As explained above, almost all the VMs in Qubes 4.0 are
fully-virtualized by default (specifically, they are HVMs), which
mitigates the most severe issue, Meltdown. The only PV domains in
Qubes 4.0 are stub domains, which we plan to eliminate by switching to
PVH where possible. This will be done in Qubes 4.0-rc4 and also
released as a normal update for existing Qubes 4.0 installations. The
only remaining PV stub domains will be those used for VMs with PCI
devices. (In the default configuration, these are sys-net and
sys-usb.) The Xen Project has not yet provided any solution for this
[9].

## Qubes 3.2

For Qubes 3.2, we plan to release an update that will make almost all
VMs run in a fully-virtualized mode. Specifically, we plan to backport
PVH support from Qubes 4.0 and enable it for all VMs without PCI
devices. After this update, all VMs that previously ran in PV mode (and
that do not have PCI devices) will subsequently run in PVH mode, with
the exception of stub domains. Any HVMs will continue to run in HVM
mode.

There are two important points regarding the Qubes 3.2 update. First,
this update will work only when the hardware supports VT-x or equivalent
technology. Qubes 3.2 will continue to work on systems without VT-x, but
there will be no mitigation against Meltdown on such systems. Users on
systems that do not support VT-x are advised to take this into
consideration when assessing the trustworthiness of their systems.

Second, the Qubes 3.2 update will also switch any VMs that use a custom
kernel to PVH mode, which will temporarily prevent them from working.
This is a deliberate security choice to protect the system as a whole
(rather than leaving VMs with custom kernels in PV mode, which would
allow attackers to use them to mount Meltdown attacks). In order to use
a VM with a custom kernel after the update (whether the custom kernel
was installed in dom0 or inside the VM), users must either manually
change the VM back to PV or change the kernel that the VM uses. (Kernel
>=4.11 is required, and booting an in-VM kernel is not supported in PVH
mode.)

We'll update this bulletin and issue a separate announcement once
patches are available.

Suggested actions after patching
=================================

While the potential attacks discussed in this bulletin are severe,
recovering from these potential attacks should be easier than in the
case of an exploit that allows the attacker to perform arbitrary code
execution, resulting in a full system compromise. Specifically, we don't
believe it is necessary to use Qubes Paranoid Backup Restore Mode to
address these vulnerabilities because of the strict read-only character
of the attacks discussed. Instead, users who believe they are affected
should consider taking the following actions:

1. Changing the screenlocker passphrase.

2. Changing the disk encryption (LUKS) passphrase.

3. Re-encrypting the disk to force a change of the disk encryption
_key_. (In practice, this can be done by reinstalling Qubes and
restoring from a backup.)

4. Evaluating the odds that other secrets have been compromised,
such as other passwords and cryptographic keys (e.g. private
PGP, SSH, or TLS keys), and generate new secrets. It is unclear
how easy it might be for attackers to steal such data in a
real world Qubes environment.

Technical discussion
=====================

- From a (high-level) architecture point of view, the attacks discussed in
this bulletin should not concern Qubes OS much. This is because,
architecture-wise, there should be no secrets or other sensitive data in
the hypervisor memory. This is in stark contrast to traditional
monolithic systems, where there is an abundance of sensitive information
living in the kernel (supervisor).

Unfortunately, for rather accidental reasons, the implementation of the
particular hypervisor we happen to be using to implement isolation for
Qubes, i.e. the Xen hypervisor, undermines this clean architecture by
internally mapping all physical memory pages into its address space. Of
course, under normal circumstances, this isn't a security problem,
because no one is able to read the hypervisor memory. However, the bugs
we're discussing today might allow an attacker to do just that. This is
a great example of how difficult it can be to analyze the security
impact of a feature when limiting oneself to only one layer of
abstraction, especially a high-level one (also known as the "PowerPoint
level").

At the same time, we should point out that the use of full
virtualization prevents at least one of the attacks, and incidentally
the most powerful one, i.e. the Meltdown attack.

However, we should also point out that, in Qubes 3.2, even HVMs still
rely on PV stub domains to provide I/O emulation (qemu). In the case of
an additional vulnerability within qemu, an attacker might compromise
the PV stub domain and attempt to perform the Meltdown attack from
there.

This limitation also applies to HVMs in release candidates 1-3 of Qubes
4.0. Qubes 4.0-rc4, which we plan to release next week, should be using
PVH instead of HVM for almost all VMs without PCI devices by default,
thus eliminating this avenue of attack. As discussed in the Patching
section, VMs with PCI devices will be the exception, which means that
the Meltdown attack could in theory still be conducted if the attacker
compromises a VM with PCI devices and afterward compromises the
corresponding stub domain via a hypothetical qemu exploit.
Unfortunately, there is not much we can do about this without
cooperation from the Xen project [9][11].

Here is an overview of the VM modes that correspond to each Qubes OS
version:

VM type \ Qubes OS version | 3.2 | 3.2+ | 4.0-rc1-3 | 4.0-rc4 |
- ---------------------------------- | --- | ---- | --------- | ------- |
Default VMs without PCI devices | PV | PVH | HVM | PVH |
Default VMs with PCI devices | PV | PV | HVM | HVM |
Stub domains - VMs w/o PCI devices | PV | N/A | PV | N/A |
Stub domains - VMs w/ PCI devices | PV | PV | PV | PV |

("3.2+" denotes Qubes 3.2 after applying the update discussed above,
which will result in most VMs running in PVH mode. "N/A" means "not
applicable," since PVH VMs do not require stub domains.)

Credits
========

See the original Xen Security Advisory.

References
===========

[1] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
[2] https://meltdownattack.com/
[3] https://meltdownattack.com/meltdown.pdf
[4] https://spectreattack.com/spectre.pdf
[5] https://xenbits.xen.org/xsa/advisory-254.html
[6] https://www.qubes-os.org/doc/split-gpg/
[7] https://github.com/inversepath/qubes-qrexec-to-tcp
[8] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
[9] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00403.html
[10] https://www.qubes-os.org/news/2017/10/03/core3/
[11] https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/

- --
The Qubes Security Team
https://www.qubes-os.org/security/
```

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpXe0cACgkQ203TvDlQ
MDDtmxAAwyTkRWQm2HWcQtcNog4ni/KcR1fVUS/iI/GTe9NE3ikbljQ2HKoGhMWF
C9/R14FyIYdSnRXWAP4FGb8tH0Pf4WFyQNegD3sDLPOxUIaSoaclLKWLLcWWpkJS
+zyomfsalpuHQ4AZZtd2PDTqpeslHy9GHvmTDDw8Pqq1Ih1d0ij4LtnRsyHWDt1B
kP6A9dC0zAsXFQnu2dSJNQcCltAdKTdD1myJ+08ot7+f1hiaWU2sllqJEO+QM/Jh
68TXEBB82XeBB4ad2nuKmTCyaYKJQB9oWi6yHVFknOM/QcNdhmAEB2YkQCNplGyD
QLfoQWJGidhu7wLzsqhtoZJC+vVg+wN1+i8h54jPwNMGnqnhhgiy4gf2QghOsZ7q
5/McepdncZ0tRuXzE4FkDhyl2h5v2rZhrPDQxcyfWLon22uW0xws5vJsyJy7xMRY
Fp4J4j+jSJjq61Hd9oCiCvFzs08y/p6vVHThcV6iy+MYJTS4QiTqf7w1JqR/GYxh
jMzTJyEUhUUVKUV/rlJTPg6CxUiC5V441iEShfRqS/LSHXNUvj2l+7TPhe8U93yU
L74qJysYcZsPJxEoAois6j8AKjcP1WCqhoDaxdFjkEBHjEm40JMzJJDCJk9eaFSL
oz9uCLCvB1IGRvYKYfbiU16NwIZ4vRFax/HRtOBicq/p1wad2X4=
=pAsX
-----END PGP SIGNATURE-----

[Foppe de Haan]

One question in response to your plan to backport PVH support to R3.2: iirc, the original reason to continue supporting R3.2 for 1 year after R4.0 is released, was that the updated hardware requirements would make R4.x impossible to use for some users who can run R3.2. If so, which subset of R3.2 users is helped by this backporting who couldn't already just move to R4.0 anyway? Or is the underlying issue that you think that it'll still take a while for R4.0 to mature bug/feature-wise, and this is a stop-gap measure?

[Tom Zander]

On Friday, 12 January 2018 10:02:07 GMT Foppe de Haan wrote:
> iirc, the original reason to continue supporting R3.2 for 1 year after
> R4.0 is released, was that the updated hardware requirements would make
> R4.x impossible to use for some users who can run R3.2. If so, which
> subset of R3.2 users is helped by this backporting who couldn't already
> just move to R4.0 anyway? Or is the underlying issue that you think that
> it'll still take a while for R4.0 to mature bug/feature-wise, and this is
> a stop-gap measure?

I'm not a Qubes dev, just anwering on experience.

3.2 is the stable version, 4.0 still has a lists of known issues and
naturlaly a lot of unknown issues that will become more known when companies
or individuals start using it for their specific usecases.

You always give people time to keep using the known stable version in order
to avoid bad surprises about regressions (those unknown issues) leaving
people in a bad situation.

Calling it a 'stop-gap measure' is not doing this approach justice, it is
just responsible management of releases.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[awokd]

On Thu, January 11, 2018 2:57 pm, Andrew David Wong wrote:

Some random questions:

> The Xen Security Team did _not_
> previously share information about these problems via their (non-public)
> security pre-disclosure list, of which the Qubes Security Team is a
> member.

What good is a pre-disclosure list if vulnerabilities aren't
pre-disclosed? Is this how the industry is going to operate from now on?

> Meltdown, the most reliable attack of the three discussed, cannot be
> exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM.

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

It's good to see Qubes' design choices validated like this.

> This is because any pages from shutdown VMs will
> typically very quickly get allocated to other, running VMs and get wiped
> as part of this procedure.

Aren't the pages scrubbed in balloon.c on a decrease_reservation, i.e.
when they are freed versus allocated?

> There are two important points regarding the Qubes 3.2 update. First,
> this update will work only when the hardware supports VT-x or equivalent
> technology. Qubes 3.2 will continue to work on systems without VT-x, but
> there will be no mitigation against Meltdown on such systems. Users on
> systems that do not support VT-x are advised to take this into
> consideration when assessing the trustworthiness of their systems.
>
> Second, the Qubes 3.2 update will also switch any VMs that use a custom
> kernel to PVH mode

Does PVH (v2/lite) also require SLAT? I'm thinking here of first
generation Intel virtualization that supports VT-x but not SLAT.

> Xen hypervisor, undermines this clean architecture by
> internally mapping all physical memory pages into its address space. Of
> course, under normal circumstances, this isn't a security problem, because
> no one is able to read the hypervisor memory. However, the bugs we're
> discussing today might allow an attacker to do just that.

I think I understand how full virtualization blocks Meltdown from doing
this, but why doesn't it also apply to Spectre? I know it's a hardware
level exploit, but virtualization instructions are hardware level too. Is
it considered a security check and therefore ignored during speculation?

> Qubes 4.0-rc4, which we plan to release next week

Looking forward to it. Please ignore my questions until a build is running
or something, or if anyone else has answers that would be good too.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jan 12, 2018 at 02:02:07AM -0800, Foppe de Haan wrote:
> One question in response to your plan to backport PVH support to R3.2: iirc, the original reason to continue supporting R3.2 for 1 year after R4.0 is released, was that the updated hardware requirements would make R4.x impossible to use for some users who can run R3.2. If so, which subset of R3.2 users is helped by this backporting who couldn't already just move to R4.0 anyway? Or is the underlying issue that you think that it'll still take a while for R4.0 to mature bug/feature-wise, and this is a stop-gap measure?

For R3.2 we're going to implement best effort approach - if VT-x is
supported, it will be used. But if not, the system will remain
functional (but vulnerable to the Meltdown issue). Since there is no
mitigation against Meltdown that do not use VT-x (at least yet), that's
all what we can do.
Also, patches for R3.2 are not going to require VT-d by default. Lack of
VT-d is the most common reason of hardware incompatibility with R4.0.

Besides the above, as Tom already said, stable R4.0 still haven't been
released, so it isn't an option for many users yet.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpYx0AACgkQ24/THMrX
1yyLVQf/WkQ8P96nd6GzLmtd/e1AWiN4mBn2gMRTQuOd+9K2FK80QYWUGbJoG7t1
LbuFFQ9N1XdozJYWd6T+omdEOoNHwStpuuzZZc5bgIU8N8vxt1iAPoQgG+TKhhPG
lh03AQlwGfMdT+r6g0H6us0OpiSQvD6GGQouGCk3EOQsvR64AevgaF9abkkJi3De
NTwUwUgqzKGghwE6ALqs0XcGtjK425/MRjcBJKfQ11BkZj6pvIW3ZzmDlt9F7M9w
fDY1YtYuLB1AA3cgrjTg8euoXSYFrypV/TgmjV3eYhahPaAEYA2uzxz/9Eopf9XZ
UKH6zZcxqGKz94hnx7nG55ASUL8t4w==
=6bvT
-----END PGP SIGNATURE-----

[Tai...@gmx.com]

On 01/12/2018 09:33 AM, Marek Marczykowski-Górecki wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Fri, Jan 12, 2018 at 02:02:07AM -0800, Foppe de Haan wrote:
>> One question in response to your plan to backport PVH support to R3.2: iirc, the original reason to continue supporting R3.2 for 1 year after R4.0 is released, was that the updated hardware requirements would make R4.x impossible to use for some users who can run R3.2. If so, which subset of R3.2 users is helped by this backporting who couldn't already just move to R4.0 anyway? Or is the underlying issue that you think that it'll still take a while for R4.0 to mature bug/feature-wise, and this is a stop-gap measure?
> For R3.2 we're going to implement best effort approach - if VT-x is
> supported, it will be used.

Will there be a warning box or some type of verification that HVM and
IOMMU are enabled and functional?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

We have just updated Qubes Security Bulletin (QSB) #37:

Information leaks due to processor speculative execution bugs.

The text of the main changes are reproduced below. For the full
text, please see the complete QSB in the qubes-secpack:

<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.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 XSA-254 in the XSA Tracker:

<https://www.qubes-os.org/security/xsa/#254>

```

Changelog
==========

2018-01-11: Original QSB published
2018-01-23: Updated mitigation plan to XPTI; added Xen package versions

[...]

(Proper) patching
==================

## Qubes 4.0

As explained above, almost all the VMs in Qubes 4.0 are
fully-virtualized by default (specifically, they are HVMs), which
mitigates the most severe issue, Meltdown. The only PV domains in Qubes
4.0 are stub domains, which we plan to eliminate by switching to PVH
where possible. This will be done in Qubes 4.0-rc4 and also released as
a normal update for existing Qubes 4.0 installations. The only remaining
PV stub domains will be those used for VMs with PCI devices. (In the

default configuration, these are sys-net and sys-usb.) To protect those
domains, we will provide the Xen page-table isolation (XPTI) patch, as
described in the following section on Qubes 3.2.

## Qubes 3.2

Previously, we had planned to release an update for Qubes 3.2 that would
have made almost all VMs run in PVH mode by backporting support for this
mode from Qubes 4.0. However, a much less drastic option has become
available sooner than we and the Xen Security Team anticipated: what the
Xen Security Team refers to as a "stage 1" implementation of the Xen
page-table isolation (XPTI) mitigation strategy [5]. This mitigation
will make the most sensitive memory regions (including all of physical
memory mapped into Xen address space) immune to the Meltdown attack. In
addition, this mitigation will work on systems that lack VT-x support.
(By contrast, our original plan to backport PVH would have worked only
when the hardware supported VT-x or equivalent technology.)

Please note that this mitigation is expected to have a noticeable
performance impact. While there will be an option to disable the
mitigation (and thereby avoid the performance impact), doing so will
return the system to a vulnerable state.

The following packages contain the patches described above:

- Xen packages, version 4.6.6-36

[...]

Here is an overview of the VM modes that correspond to each Qubes OS
version:

VM type \ Qubes OS version | 3.2 | 4.0-rc1-3 | 4.0-rc4 |
- ---------------------------------- | --- | --------- | ------- |
Default VMs without PCI devices | PV | HVM | PVH |
Default VMs with PCI devices | PV | HVM | HVM |
Stub domains - Default VMs w/o PCI | N/A | PV | N/A |
Stub domains - Default VMs w/ PCI | N/A | PV | PV |
Stub domains - HVMs | PV | PV | PV |

```

> ---------------------------------- | --- | ---- | --------- | ------- |
> Default VMs without PCI devices | PV | PVH | HVM | PVH |
> Default VMs with PCI devices | PV | PV | HVM | HVM |
> Stub domains - VMs w/o PCI devices | PV | N/A | PV | N/A |
> Stub domains - VMs w/ PCI devices | PV | PV | PV | PV |
>
> ("3.2+" denotes Qubes 3.2 after applying the update discussed above,
> which will result in most VMs running in PVH mode. "N/A" means "not
> applicable," since PVH VMs do not require stub domains.)
>
> Credits
> ========
>
> See the original Xen Security Advisory.
>
> References
> ===========
>
> [1] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
> [2] https://meltdownattack.com/
> [3] https://meltdownattack.com/meltdown.pdf
> [4] https://spectreattack.com/spectre.pdf
> [5] https://xenbits.xen.org/xsa/advisory-254.html
> [6] https://www.qubes-os.org/doc/split-gpg/
> [7] https://github.com/inversepath/qubes-qrexec-to-tcp
> [8] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
> [9] https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00403.html
> [10] https://www.qubes-os.org/news/2017/10/03/core3/
> [11] https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>

> --
> The Qubes Security Team
> https://www.qubes-os.org/security/
> ```

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpoUcIACgkQ203TvDlQ
MDBAAxAAn2mtJMs44kCMKVWmuTEunqOy/mbOLnWnSvCN4e1pT8RnujvErUrVk7OO
j7lARLXX9GoNQZcmr3ex+7qWXxN/FWarU8/C8yGDWBEhZYl6kB4B53LtgWB1Ggbn
J+3q1nzoyBtohXmuUECMciHTnTnmGSboawts33yH8+ayxgJcWHF0x+XZl2Cnh2cT
bftJBtX57nVQaNSyWN2tPMe9toceX2kd/M9HGYpib9M8tDatrK/SB6H7hL/ZjaTM
wpmJOvzwLCwRLA7f0jWP7OBMua400bd7xmSgJS+yvOGZLKUF40RrEnSoylT91kHj
3zMTvvjycPH59Qy4NGtrbTKBro1I7uzvxXt01aRstaGRYPebn6IckV99ORx/aWx9
RxFlnzDKOoY9j0DEGzuCe9xHgWGVR6WpmKbofN8Kl9c0DAa29ZVVA3T/OF5uDkuk
SXGT1RRFIGbTKt8NQxXzmbYq07uK05X5yy16yoD1h9nPpXvXR/GmXuEC+xyErhMw
FmpixIYIy596xhKrws64xZpB5563krYe9A7yZVbR118v7dJzG7CdJpQ9erotqEio
xQLnZVPva8LoYDrLvVm33o6VkZW4fi6fpeI3kkQIBmYCfptVx7walbGgREeZOoLa
FIGnKlKpvolgse6f2WdFIySwM8ecNcfh6gHmJWrswpSRwpWExOw=
=JtlX
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Jan 24, 2018 at 12:15:25PM -0700, Reg Tiangha wrote:
> On 01/24/2018 07:51 AM, Ed wrote:

> > On 01/24/2018 04:29 AM, Andrew David Wong wrote:
> >
> >> ## Qubes 3.2
> >>
> >> Previously, we had planned to release an update for Qubes 3.2 that would
> >> have made almost all VMs run in PVH mode by backporting support for this
> >> mode from Qubes 4.0.
> >

> > Out of curiosity, is this still going to happen? 

Not unless forced otherwise to do so.

> > I would love to see
> > this if possible, not only helping mitigate Meltdown without the
> > performance penalty (I believe), but also would give a nice general
> > security boost to 3.2
> >
> > Thanks,
> > Ed
> >
>
> The thing is, if Qubes intends on sticking with Xen 4.6 on Qubes R3.2,
> then the promise of 1 year extended support after R4.0 is officially
> released may be hard to meet since Xen will discontinue security support
> in Oct 2018 (Source:
> https://wiki.xenproject.org/wiki/Xen_Project_Release_Features ). That
> means there could be a 3-4+ month period where the Qubes devs would need
> to manually backport from newer versions of Xen any security fixes found
> in Xen during that time frame (in essence, the Qubes project would need
> to take over maintenance of the Xen 4.6 branch for that time period).
> That could increase the support/maintenance burden for the Qubes devs by
> a lot, depending on how complex the security issues are (worse case
> would be another thing like Meltdown/Spectre happening again during that
> time frame after official Xen support ends).

We've tested backported Xen 4.8 with PVH on various machines well
supported by R3.2 and there are some cases where it breaks badly. The
most extreme is hardware lacking EPT, where PVH is like 16x slower than
PV. I'm sure "just" upgrading Xen (without switching to PVH) will also
bring some compatibility problems, maybe for small minority of users,
but still. Similar to major kernel upgrade, as we've seen multiple times.
We promised Qubes 3.2 to be stable, supported release.

See "Upgrade instructions for R3.2 and QSB37 patches" thread on
xen-devel for some examples, and also comments here:
https://github.com/QubesOS/qubes-core-admin/pull/178
https://github.com/QubesOS/qubes-vmm-xen/pull/24

So yes, this means we'll need to support Xen 4.6 ourself for a few
months. It may happen that yet another bug will be found, requiring very
hard to backport changes. But I think it is quite unlikely event. And
even if that happen, we can decide to upgrade Xen then. We already have
part of this work done.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlppFeMACgkQ24/THMrX
1yxmGQgAk/LLxD5LywTDpZi+Ii7XDHPRT7rkTvbQv6K79S7WfdXvNoXpyCoBOO0/
iR+L4RMzF6OIu861aBiUZo8WiTfoE6dgDu4X/5MNPcewbtGhaOnq6DOiBCMRTW8+
mXtSepu/XVtMqZnAI7vZyBVijVh7UI2CfUfOJnk1Z3zhU9phAGePh7ywSRskrOVI
qOEVb70f9qaB9BV81MjtOjn+nz4IiTid2CQEL2CFPhEWoXqbd1dtQLnemH8j1f1a
uwlNIf76foiJLr0I8iei/SLjLG5YHOtKWNUtBf1jRtTbpZCbu96o9MCMQSjn5ZG8
SR8McukKMgRCYPOCvAA+GJ1DxVWE6w==
=qfqr
-----END PGP SIGNATURE-----

[Rich Persaud]

This OpenXT wiki page aggregates evolving info from upstream projects and vendor disclosures on Spectre/Meltdown:

https://openxt.atlassian.net/wiki/spaces/DC/pages/397967361/Meltdown+and+Spectre+mitigations+for+Xen+Linux+and+Windows

It links to an exportable spreadsheet that tracks guest exposure and mitigations, with reference URLs for each mitigation:

https://docs.google.com/spreadsheets/d/1h9z98xW5COh2YuH7nOeTsjLGZ-k_Cl2FmLEiXOyeyZQ/htmlview

Feedback welcome, there's a lot of combinations to track, as mitigations evolve.

Rich

[Tai...@gmx.com]

Ironic that it requires javascript, I suppose no one can safely view
these then.

[Ed]

On 01/24/2018 04:29 AM, Andrew David Wong wrote:

> ## Qubes 3.2
>
> Previously, we had planned to release an update for Qubes 3.2 that would
> have made almost all VMs run in PVH mode by backporting support for this
> mode from Qubes 4.0.

Out of curiosity, is this still going to happen? I would love to see

[Reg Tiangha]

I've noticed that Xen has updated the XSA-254 advisory with Spectre v2
mitigations for Xen 4.6-4.10. I know we'd have to figure out how to
backport Retpoline compatible compilers to these various build
environments in order to get the full protection (Debian has backported
that support to the gcc versions in jessie and stretch so that implies
that at least the backported gcc patches are now available), but is
there any chance that these Xen patches will be incorporated into the
Qubes versions soon?

https://xenbits.xen.org/xsa/advisory-254.html

And a side question about qubes-builder: Does it build in a chroot? I'd
like to attempt to backport a build environment that has a
retpoline-enabled version of gcc, and I'm wondering if I could just
bypass qubes-builder entirely and run make rpms-dom0 in a build
environment where I've manually upgraded the gcc version to be
Retpoline-compatible in an FC23 or FC25 template like I do when I
compile my own kernels.

Also: Are there any dangers in compiling the Xen rpms in an FC25
template and then installing them in R3.2 dom0's FC23 environment? Or
should I just build it in an FC23 environment to be safe? I haven't
encountered any issues in doing that with kernels (although I don't
compile third-party out-of-tree kernel drivers either), but I don't know
what Xen would link against during compilation to know if that's safe to
do or not.

[awokd]

On Fri, February 23, 2018 10:27 pm, Reg Tiangha wrote:

> And a side question about qubes-builder: Does it build in a chroot? I'd
> like to attempt to backport a build environment that has a
> retpoline-enabled version of gcc, and I'm wondering if I could just bypass
> qubes-builder entirely and run make rpms-dom0 in a build environment where
> I've manually upgraded the gcc version to be
> Retpoline-compatible in an FC23 or FC25 template like I do when I
> compile my own kernels.
>
> Also: Are there any dangers in compiling the Xen rpms in an FC25
> template and then installing them in R3.2 dom0's FC23 environment? Or
> should I just build it in an FC23 environment to be safe? I haven't
> encountered any issues in doing that with kernels (although I don't
> compile third-party out-of-tree kernel drivers either), but I don't know
> what Xen would link against during compilation to know if that's safe to
> do or not.

qubes-builder builds Xen etc. inside a Fedora 25 chroot. So you can do:

sudo chroot chroot-fc25
cd /home/user
su -c 'make -C rpmbuild/BUILD/xen-4.8.2/xen menuconfig' - user
su -c 'make -C rpmbuild/BUILD/xen-4.8.2/xen' - user

Then get compiled Xen binary from
chroot-fc25/home/user/rpmbuild/BUILD/xen-4.8.2/xen/xen.{gz,efi}

(Credit to Marek). That's for 4.0, 3.2 is an fc23 chroot. Not sure if that
answers all your questions.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Feb 23, 2018 at 03:27:38PM -0700, Reg Tiangha wrote:
> I've noticed that Xen has updated the XSA-254 advisory with Spectre v2
> mitigations for Xen 4.6-4.10. I know we'd have to figure out how to
> backport Retpoline compatible compilers to these various build
> environments in order to get the full protection (Debian has backported
> that support to the gcc versions in jessie and stretch so that implies
> that at least the backported gcc patches are now available), but is
> there any chance that these Xen patches will be incorporated into the
> Qubes versions soon?
>
> https://xenbits.xen.org/xsa/advisory-254.html

Simon, can you take a look at it? We'll probably need to put patched gcc
to linux-dom0-updates repository (if newer Fedora has patched gcc and
it's possible to build that src.rpm on older Fedora), or add separate
repository with patched gcc - then probably indeed based on patches from
Debian.

> And a side question about qubes-builder: Does it build in a chroot?

Yes.

> I'd
> like to attempt to backport a build environment that has a
> retpoline-enabled version of gcc, and I'm wondering if I could just
> bypass qubes-builder entirely and run make rpms-dom0 in a build
> environment where I've manually upgraded the gcc version to be
> Retpoline-compatible in an FC23 or FC25 template like I do when I
> compile my own kernels.

In theory - yes. In practice, no one have tried that for a long time.

> Also: Are there any dangers in compiling the Xen rpms in an FC25
> template and then installing them in R3.2 dom0's FC23 environment?

For xen-hypervisor package it should be ok. And this is the only one
you should care about here.
For other packages, especially xen-libs and xen-runtime, resulting
binaries most likely will not work in older environment (linked
libraries versions etc).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqQnwgACgkQ24/THMrX
1yw9DAgAmhydEgfCb/A0xzVAHVXzjMi18kWMmgU54IVOjjuBfE3oIFyXKna1jSb2
Y7OdrA91yc2F87bsiBrXlDaqJlM1HHs3vvjsnq4KZ1+LI8DhEWaEkki2govzmkSi
w21+QZ4IC5BIwUFO7HF3beTlxnI3p+/3vfVg+956bsmvQDYSjLVi3t5TiMBrtsmI
Hfizzl2sjH5Y5LYlbM5vUTYGQ0BdIk2ZF7EQeSZ4PjoBAzKy5DAUlWa429eZzT9R
7GzAR1E/t+eAJhZT1tCo0CPvehboMsTVj0xgRZi9BfEVDdYwcbI6t09nAy0SauWc
0RR1n1pHJFgwaExyMo5HNEQteuDMoQ==
=O1Qg
-----END PGP SIGNATURE-----

[Reg Tiangha]

On 02/23/2018 04:08 PM, Marek Marczykowski-Górecki wrote:
> Simon, can you take a look at it? We'll probably need to put patched gcc
> to linux-dom0-updates repository (if newer Fedora has patched gcc and
> it's possible to build that src.rpm on older Fedora), or add separate
> repository with patched gcc - then probably indeed based on patches from
> Debian.

Just chiming in, but I believe that the Fedora 26 and 27 Updates
repositories has gcc 7.3 now, which has Retpoline support. But if
backporting to FC23/25, I *think* glibc would also need to be upgraded,
if 7.3 won't compile against the stock glibc found in FC23 and 25.
Backporting gcc 7.3 to FC23 may also need a few more additional packages
to be upgraded in the toolchain, although I haven't tried it myself.

I don't know if this helps, but I *have* tried installing FC27 Updates
rpms in an FC25 AppVM and it works fine, at least for compiling kernels.
There may be some extra packages here that don't absolutely need to be
there, but this is what I installed in an FC25 template cleanly, and if
there were additional dependencies needed by these rpms, the FC25
versions of those packages worked fine:

cpp-7.3.1-2.fc27.x86_64.rpm
gcc-7.3.1-2.fc27.x86_64.rpm
gcc-c++-7.3.1-2.fc27.x86_64.rpm
gcc-gdb-plugin-7.3.1-2.fc27.x86_64.rpm
gcc-gfortran-7.3.1-2.fc27.x86_64.rpm
gcc-gnat-7.3.1-2.fc27.x86_64.rpm
gcc-go-7.3.1-2.fc27.x86_64.rpm
gcc-objc-7.3.1-2.fc27.x86_64.rpm
gcc-objc++-7.3.1-2.fc27.x86_64.rpm
gcc-plugin-devel-7.3.1-2.fc27.x86_64.rpm
glibc-2.26-24.fc27.x86_64.rpm
glibc-all-langpacks-2.26-24.fc27.x86_64.rpm
glibc-common-2.26-24.fc27.x86_64.rpm
glibc-headers-2.26-24.fc27.x86_64.rpm
isl-0.16.1-3.fc27.x86_64.rpm
libasan-7.3.1-2.fc27.x86_64.rpm
libasan-static-7.3.1-2.fc27.x86_64.rpm
libatomic-7.3.1-2.fc27.x86_64.rpm
libatomic-static-7.3.1-2.fc27.x86_64.rpm
libcilkrts-7.3.1-2.fc27.x86_64.rpm
libcilkrts-static-7.3.1-2.fc27.x86_64.rpm
libgcc-7.3.1-2.fc27.x86_64.rpm
libgccjit-7.3.1-2.fc27.x86_64.rpm
libgccjit-devel-7.3.1-2.fc27.x86_64.rpm
libgfortran-7.3.1-2.fc27.x86_64.rpm
libgfortran-static-7.3.1-2.fc27.x86_64.rpm
libgnat-7.3.1-2.fc27.x86_64.rpm
libgnat-devel-7.3.1-2.fc27.x86_64.rpm
libgnat-static-7.3.1-2.fc27.x86_64.rpm
libgo-7.3.1-2.fc27.x86_64.rpm
libgo-devel-7.3.1-2.fc27.x86_64.rpm
libgomp-7.3.1-2.fc27.x86_64.rpm
libgomp-offload-nvptx-7.3.1-2.fc27.x86_64.rpm
libgo-static-7.3.1-2.fc27.x86_64.rpm
libitm-7.3.1-2.fc27.x86_64.rpm
libitm-devel-7.3.1-2.fc27.x86_64.rpm
libitm-static-7.3.1-2.fc27.x86_64.rpm
liblsan-7.3.1-2.fc27.x86_64.rpm
liblsan-static-7.3.1-2.fc27.x86_64.rpm
libobjc-7.3.1-2.fc27.x86_64.rpm
libquadmath-7.3.1-2.fc27.x86_64.rpm
libquadmath-devel-7.3.1-2.fc27.x86_64.rpm
libquadmath-static-7.3.1-2.fc27.x86_64.rpm
libstdc++-7.3.1-2.fc27.x86_64.rpm
libstdc++-devel-7.3.1-2.fc27.x86_64.rpm
libstdc++-docs-7.3.1-2.fc27.x86_64.rpm
libstdc++-static-7.3.1-2.fc27.x86_64.rpm
libtsan-7.3.1-2.fc27.x86_64.rpm
libtsan-static-7.3.1-2.fc27.x86_64.rpm
libubsan-7.3.1-2.fc27.x86_64.rpm
libubsan-static-7.3.1-2.fc27.x86_64.rpm

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> On Fri, Feb 23, 2018 at 03:27:38PM -0700, Reg Tiangha wrote:
>> I've noticed that Xen has updated the XSA-254 advisory with Spectre v2
>> mitigations for Xen 4.6-4.10. I know we'd have to figure out how to
>> backport Retpoline compatible compilers to these various build
>> environments in order to get the full protection (Debian has backported
>> that support to the gcc versions in jessie and stretch so that implies
>> that at least the backported gcc patches are now available), but is
>> there any chance that these Xen patches will be incorporated into the
>> Qubes versions soon?
>
>> https://xenbits.xen.org/xsa/advisory-254.html
>
> Simon, can you take a look at it? We'll probably need to put patched gcc
> to linux-dom0-updates repository (if newer Fedora has patched gcc and
> it's possible to build that src.rpm on older Fedora), or add separate
> repository with patched gcc - then probably indeed based on patches from
> Debian.

It seems to be working for me, but the gcc part is a bit tricky.

Building a newer gcc src.rpm doesn't sounds like a good idea since the
package contains a lot of stuff which probably breaks on a version jump
(like libgcc, libstdc++, libasan, ...).

My original plan (i.e. before the XSA got updated) was to build an extra
gcc just for vmm-xen (and probably linux-kernel). But now I noticed that
Debian published backports for gcc-6 and gcc-5, so R3.2 is also covered.
So I decided to add those backports to the Fedora gcc package. I got
this working now, but it has some caveats:

- The Fedora gcc package build seems to be flacky. It failed twice for
me with different errors (both verry likely unrelated to the backport
patches). Assigning a lot of memory to the build VM got it working
... And I noticed that a bunch of tests are failing but apparently
that's not a reason to break the package build ...

- Installing the patched gcc required manual intervention in my chroot
(didn't tried a fresh chroot yet). For some reasons it only wanted to
install it when I told dnf explicitly to install the updated gcc and
libgcc. Then dnf was happy (i.e. no more error about dependency
problems)

- Updating gcc is "all or nothing". So should the (probably unlikely)
case occure that the new gcc cases problems with other packages we
can't keep using it for vmm-xen but not for other components.

Other options:

Build an extra package with a current gcc (i.e. 7.3.0). This package
would be much smaller (since only C support is needed), so debugging
build problems is much easier (if they happen at all). We can switch on
a per package base if we want to use the patched gcc (CC=gcc-7). Since
this was my plan before knowing about the backports I already done some
of the work for this (one search patch issue is not resolved yet). The
downside is that the version jump (gcc-6 (or gcc-5 in R3.2) to gcc-7)
might create problems with vmm-xen and linux-kernel.

Build an extra package with the gcc version as used by Fedora (as above
C only). This would avoid the gcc version jump, but it might be trickier
to get two variants of gcc with the same version to co-install without
path conflicts.

What do you think?


My current state (variant 1 (i.e. patch main gcc package)):

https://github.com/HW42/qubes-vmm-xen/tree/hw42/sp2
https://github.com/HW42/qubes-gcc
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqTIkkACgkQkO9xfO/x
ly8aLhAAyUFDvZEpScH8zgYa5sO+1tRrB1YGlsRkcSyUtodcGqEBRL6ZOc0Vwuu9
oKOabryweo+By7AAnehFXdAv5aaI6BZ7pWZs9EPcvCJIphQiX8KSIyzQFRkfg8LL
uIBdH60udqsZGZIsZ3vr9hDFxvM2mIeeF9rNJhahvSYHUl438eOmAMEglVTKuU0R
OB2ffmtluatXlZdoAapY7+uAkkGCvVpS6zg87y0iWUVGC/EoPxQyrY3qn5uRGeKa
3iB7xb5Hf1THsj4NuDIWHGf2xLWYLkg/N8LoAJG4X8HUGvISlbollA+h0Qw3v/5C
EtvvIInTGYkBo8+LXdAka7U3AjUpkGVbYRqNaoB1Si0iCFbCN13jTXT2AUnkRfWd
vSbNV3qramZr+TRK75K+b4+M7SxdEFDDc8vjBt3K1WGWwRDl14hxN8Sjh4pyjE8Y
ORLt2bQ4COkIaVZutenpRRxWIkuQY4CHvdPGiXTd50i5C0fk8E0fbiYUYndlSUHO
f+gmeIaXcOfDnobeUpVOE9kdpqrapqSvsVWYzKnkw94/xMkJCH20V5f0PdJO5iTK
nFUqjLua9MP4NyU+QOfYgyaoq8AcU4diUeAh8j1BQ+j6wzPF8VYmgCevpUJihTnD
0nUoBhfspxUsmvMPq2Nb5t8rUXGlisRx6xLvCnikvUSjcZuuZbQ=
=IWk8
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

That's a little worrying. Fortunately in practice (I hope) we need to do
that only once (thanks to fc23 and fc25 being EOL).

Have you tried building it on Travis-CI? That could be also a way to
stress-test this build.

> - Installing the patched gcc required manual intervention in my chroot
> (didn't tried a fresh chroot yet). For some reasons it only wanted to
> install it when I told dnf explicitly to install the updated gcc and
> libgcc. Then dnf was happy (i.e. no more error about dependency
> problems)

That's strange. Are you sure the version is greater? Is dnf reporting
this as an update?

> - Updating gcc is "all or nothing". So should the (probably unlikely)
> case occure that the new gcc cases problems with other packages we
> can't keep using it for vmm-xen but not for other components.

Actually, if we _really_ want, we can. I can setup separate
qubes-builder instance (with separate chroots etc) just for vmm-xen.
But that would be cumbersome, and IMO very unlikely needed.

> Other options:
>
> Build an extra package with a current gcc (i.e. 7.3.0). This package
> would be much smaller (since only C support is needed), so debugging
> build problems is much easier (if they happen at all). We can switch on
> a per package base if we want to use the patched gcc (CC=gcc-7). Since
> this was my plan before knowing about the backports I already done some
> of the work for this (one search patch issue is not resolved yet). The
> downside is that the version jump (gcc-6 (or gcc-5 in R3.2) to gcc-7)
> might create problems with vmm-xen and linux-kernel.
>
> Build an extra package with the gcc version as used by Fedora (as above
> C only). This would avoid the gcc version jump, but it might be trickier
> to get two variants of gcc with the same version to co-install without
> path conflicts.
>
> What do you think?

I'd go with backporting patches to original Fedora's gcc.

> My current state (variant 1 (i.e. patch main gcc package)):
>
> https://github.com/HW42/qubes-vmm-xen/tree/hw42/sp2

I've just merged xen.spec rework, sorry...

> https://github.com/HW42/qubes-gcc

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqTW8EACgkQ24/THMrX
1yzicgf+NhVdSI/rngU0RC24N21JZGqS9mDf+WTC91cmLeht0V07Prook2eDURan
KQVyeVFLm9UxfIWksKLCfq0oEqhM0na1SAHzp/OycykhND4jg0ZtDU5JAW4jYyok
Tu0YVlXIOe2Bs51Hqj2aECeRs56UoPVG7yz+eJ8yIUUppmBoH+l9P7zeWnJkAalh
slscWo0pi2St0rkRnAfBvCJF8h6dXQjD0e1q/DMYx1DUssggSpXpIyyGA6ifqG/k
tKYe6hWG3EOLG/s415bG0OaqzUrhQlbwnR1cCetTE+bmiJQE7Pkp+3VW/kloTWji
/weTdW8+1we4R7Zw6rE+GCNUdlADWw==
=zv9B
-----END PGP SIGNATURE-----

[Reg Tiangha]

On 02/25/2018 01:53 PM, Simon Gaiser wrote:
> - The Fedora gcc package build seems to be flacky. It failed twice for
> me with different errors (both verry likely unrelated to the backport
> patches). Assigning a lot of memory to the build VM got it working
> ... And I noticed that a bunch of tests are failing but apparently
> that's not a reason to break the package build ...

I don't know if this will help, but if you're going to recompile gcc-6
anyway, perhaps it's worthwhile updating the snapshot the src rpm is
using too (the latest is gcc-6-20180221.tar.xz)? gcc-6 is still
maintained by upstream and the instructions on how to do so are in the
spec file itself (the revision code you'd want is 257883, or you could
download the tar ball directly):

https://gcc.gnu.org/ml/gcc/2018-02/msg00162.html

It could be that the retpoline patches are already included, in which
case, there'd be no manual patching needed and there'd be the benefit of
having all the bug and security fixes since FC25 went EOL be included too.

If it works, gcc-6 should also build in FC23 with no additional upgrades
to libraries, so maybe it'd be worthwhile doing since gcc-5 is no longer
maintained by upstream gcc.

If wanting to backport gcc-7.3 to FC23 and FC25, the only other library
that would absolutely be needed to be upgraded is isl and isl-devel. You
could use the FC26 src rpms for both isl/isl-devel and gcc for that.

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

No. I decided to not track down the build failures I observed since that
probably requires a lot of time for such a big packages (it outputs 49
packages including stuff like gnat gcc-go, gfortran, ...). I'm not sure
why Travis-CI would help here. I already have strange errors when
building locally.

What we could try is disabling parallel builds. But then the build time
is even longer. I will test if I still see build failures without extra
RAM.

>> - Installing the patched gcc required manual intervention in my chroot
>> (didn't tried a fresh chroot yet). For some reasons it only wanted to
>> install it when I told dnf explicitly to install the updated gcc and
>> libgcc. Then dnf was happy (i.e. no more error about dependency
>> problems)
>
> That's strange. Are you sure the version is greater? Is dnf reporting
> this as an update?

Yes it reports it as update. Below is reconstructed based on dnf.log
(The log part I cut out for brevity didn't include helpful messages,
AFAICS):

$ dnf --refresh -y update
================================================================================
Package Arch Version Repository Size
================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
cpp x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 9.0 M
libgcc x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 95 k
libgnat x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.0 M
libgnat-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 2.7 M
libgomp x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 197 k
libstdc++ x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 459 k
libstdc++-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.8 M
Skipping packages with broken dependencies:
gcc x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 20 M
gcc-c++ x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 11 M
gcc-gdb-plugin x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 91 k
gcc-gnat x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 18 M
gcc-plugin-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.3 M

Transaction Summary
================================================================================
Skip 12 Packages

$ dnf update --best --allowerasing
===================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================
Upgrading:
cpp x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 9.0 M
libgcc x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 95 k
libgnat x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.0 M
libgnat-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 2.7 M
libgomp x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 197 k
libstdc++ x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 459 k
libstdc++-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.8 M
Removing:
dkms noarch 2.4.0-1.20170926git959bd74.fc25 @updates 217 k
gcc x86_64 6.4.1-1.fc25 @updates 49 M
gcc-c++ x86_64 6.4.1-1.fc25 @updates 26 M
gcc-gdb-plugin x86_64 6.4.1-1.fc25 @updates 147 k
gcc-gnat x86_64 6.4.1-1.fc25 @updates 51 M
gcc-plugin-devel x86_64 6.4.1-1.fc25 @updates 7.0 M
glibc-devel i686 2.24-10.fc25 @updates 1.0 M
gobject-introspection-devel x86_64 1.50.0-1.fc25 @fedora 10 M
libgcc i686 6.4.1-1.fc25 @updates 202 k
libtool x86_64 2.4.6-14.fc25 @updates 2.6 M
qubes-kernel-vm-support x86_64 4.0.9.test1-1.fc25 @qubes-builder-pkgs 15 k
systemtap x86_64 3.2-2.fc25 @updates 199 k
systemtap-devel x86_64 3.2-2.fc25 @updates 7.3 M
xorg-x11-server-devel x86_64 1.19.3-1.fc25 @updates 1.2 M
xorg-x11-util-macros noarch 1.19.0-5.fc24 @fedora 159 k
Skipping packages with broken dependencies:
gcc x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 20 M
gcc-c++ x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 11 M
gcc-gdb-plugin x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 91 k
gcc-gnat x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 18 M
gcc-plugin-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.3 M

Transaction Summary
===================================================================================================================================================
Upgrade 7 Packages
Remove 15 Packages
Skip 5 Packages


$ dnf install gcc-6.4.1-1.qubes1.fc25.x86_64
Error: package gcc-6.4.1-1.qubes1.fc25.x86_64 requires libgcc >= 6.4.1-1.qubes1.fc25, but none of the providers can be installed

$ dnf install --allowerasing gcc-6.4.1-1.qubes1.fc25.x86_64
Error: package gcc-6.4.1-1.qubes1.fc25.x86_64 requires libgcc >= 6.4.1-1.qubes1.fc25, but none of the providers can be installed

$ dnf install --allowerasing gcc-6.4.1-1.qubes1.fc25.x86_64 libgcc-6.4.1-1.qubes1.fc25.x86_64
===================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================
Upgrading:
cpp x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 9.0 M
gcc x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 20 M
gcc-c++ x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 11 M
gcc-gdb-plugin x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 91 k
gcc-gnat x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 18 M
gcc-plugin-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.3 M
libgcc x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 95 k
libgnat x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.0 M
libgnat-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 2.7 M
libgomp x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 197 k
libstdc++ x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 459 k
libstdc++-devel x86_64 6.4.1-1.qubes1.fc25 qubes-builder-pkgs 1.8 M

Transaction Summary
===================================================================================================================================================
Upgrade 12 Packages

>> - Updating gcc is "all or nothing". So should the (probably unlikely)
>> case occure that the new gcc cases problems with other packages we
>> can't keep using it for vmm-xen but not for other components.
>
> Actually, if we _really_ want, we can. I can setup separate
> qubes-builder instance (with separate chroots etc) just for vmm-xen.
> But that would be cumbersome, and IMO very unlikely needed.
>
>> Other options:
>
>> Build an extra package with a current gcc (i.e. 7.3.0). This package
>> would be much smaller (since only C support is needed), so debugging
>> build problems is much easier (if they happen at all). We can switch on
>> a per package base if we want to use the patched gcc (CC=gcc-7). Since
>> this was my plan before knowing about the backports I already done some
>> of the work for this (one search patch issue is not resolved yet). The
>> downside is that the version jump (gcc-6 (or gcc-5 in R3.2) to gcc-7)
>> might create problems with vmm-xen and linux-kernel.
>
>> Build an extra package with the gcc version as used by Fedora (as above
>> C only). This would avoid the gcc version jump, but it might be trickier
>> to get two variants of gcc with the same version to co-install without
>> path conflicts.
>
>> What do you think?
>
> I'd go with backporting patches to original Fedora's gcc.

Ok.

So, what I still need to do:

- Try if non-parallel builds are more stable.
- Test on a "Skylake or later" machine (if I find one with available
updates)
- R3.2
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqUBPcACgkQkO9xfO/x
ly9aHA//Tpa0TurW5545bqKGKeq67Mqizc0x6fUiPATQrS7c5LxTGPzAA11coPFn
wLccVU4KX1LTjxIiCXrBAOHx0PFyM7A6NkGObG279CYJdxEzBP1EUTfHqJYa8+x8
0W67ruoB6SnmprEW6/x0XqkXkG+dRCaY8wDjD/yUoTZGOv/1zpro1fN1VyNvcd7T
ZgOMtmGd+Zr8bxvGEnz9b/IpGOCAqGrg/QHe0pwolm0zoOAZEtaUBMqueedz42DK
q08zPWv+SsnHMRuvNeCVI0jBdTQy8qN0osCw1AvkJvDsMc8moCRIOsuoRG4mwnMf
QlwncDfBQfAvZs+De/MjAaP73dkl1cRVkTxYU519wt+RH7+CfN3hPDMBhEeOzGJy
krNqo5yVKAz1srRZbyJ9YP3iskYX7kc+NKBDiEByClwf3Ggy9s3irnJFFYoDPdEm
85EsJirYaosaYrL0VcQtVXprVIH4FngjCUcX6suO+mjAwdvI/OozeO0AlEZAn4EK
PETYQJrBMnGeoDtaAF6K3VIOIvErJ2KbPQU2U72FRwfm0mFI6gho9tQlc/g+mLhq
N3qGRf5AQkOcxtg9AB1PR23A+OUiR0JhEcuIdfR3nUu/mvoOW9NO3m22JTG4dLEi
0zHGszMx/2bkqeBPriPAUUhgS+6nVVY2R1IcF+8Vh8oPSjBNhE0=
=dUZ+
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Reg Tiangha:

> On 02/25/2018 01:53 PM, Simon Gaiser wrote:
>> - The Fedora gcc package build seems to be flacky. It failed twice for
>> me with different errors (both verry likely unrelated to the backport
>> patches). Assigning a lot of memory to the build VM got it working
>> ... And I noticed that a bunch of tests are failing but apparently
>> that's not a reason to break the package build ...
>
> I don't know if this will help, but if you're going to recompile gcc-6
> anyway, perhaps it's worthwhile updating the snapshot the src rpm is
> using too (the latest is gcc-6-20180221.tar.xz)? gcc-6 is still
> maintained by upstream and the instructions on how to do so are in the
> spec file itself (the revision code you'd want is 257883, or you could
> download the tar ball directly):
>
> https://gcc.gnu.org/ml/gcc/2018-02/msg00162.html
>
> It could be that the retpoline patches are already included,

They aren't.

> in which case, there'd be no manual patching

The patching was very easy since Debian has already backports for the
used version and they apply cleanly.

> needed and there'd be the benefit of
> having all the bug and security fixes since FC25 went EOL be included too.

Given that gcc (should) never touch untrusted input in our use case I'm
unconvinced that updating it proactively is a good time investment. Or
are there any concrete bugs you are thinking about?

> If it works, gcc-6 should also build in FC23 with no additional upgrades
> to libraries, so maybe it'd be worthwhile doing since gcc-5 is no longer
> maintained by upstream gcc.

As I already wrote that's not so easy. The gcc source package includes a
bunch of libraries which are potentially used by a lot of packages (for
example libstdc++). So a version jump there isn't a good idea.

> If wanting to backport gcc-7.3 to FC23 and FC25, the only other library
> that would absolutely be needed to be upgraded is isl and isl-devel. You
> could use the FC26 src rpms for both isl/isl-devel and gcc for that.

FWIW, gcc 7.3 built fine for me without updating isl in Fedora 25.
Anyway we are not going this way (see other mail).

PS: Please keep me in CC.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqUCuwACgkQkO9xfO/x
ly/eSg//QceZYl7AJbxr+W+MIIAUzQgi+PzozuqUEo4+Uwfb3N1OGAFYQ9MHOKqf
xI1SD6VJ4SiVm1XEEXQ8cv43aZW8PhuMIEx9rVIh3NO3euqcKPZNOAPH5J8bt2PG
k0v1cGZjsyfg39xmuumNqgbe+q78xPI+XKtaZj3HxGtVcwRknYznPMBQTXa1wXBq
zyp2Et8uachRq7Mc2IctTlK76XLDZ0BpSuGZOQcq5lhJ81ZyyQJRrmBoGmmlZk+I
CGjhHvW1gU2NueWzI+ZbnbukfTTIKVmh4If3QPoN4WgTutadDgeZsk07Db81+8L2
uUVeAagvB8Vk8lYeU8UrLaU+aHdS+aM/PyavH9qDnEDCZtmNKh0bL5Yv3UhD4ExL
4lbWKsmeFJ1+XdN9vkU265n1eqNq8FSSJGlWoDWYJ0jcYReRAIt2Odr8qsBaIqrW
uU0tp89vKDvetGEyZ9uRuGaS5rX7ziN8CDrW/rlqsOm6UYxcjF/LwT0M91AzcH+y
qNNt/2F1lxu5RnatqsQx55G5XmhNy1ftJQQSLIjPEAMg6C4RTzE0dDO/aqXIcVoV
RDje98q+tHQ5OXVyhTAArzl9Krh5lgLVI+nTXHf313rlV1mVBVVT/yM/HZ9XaPf0
x400NGU3waii2FyE4uDF0GcFtb2JePMa6b6hVn1SlooWRracjxA=
=n7za
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:
[...]

> I'd go with backporting patches to original Fedora's gcc.

Fedora uses their own gcc snapshot in their package (i.e. not an
upstream tarball). AFAICS Fedora does not host it directly anywhere.
Where should qubes-builder downloads it from? Host it on
ftp.qubes-os.org, Download the src.rpm or something else?
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqUDH8ACgkQkO9xfO/x
ly/nnQ//Rhf5oArpG6s+32uInptY1aIGwO+ymXS9na857WKarJPOAvPxfs7nUHgo
HSnPaCohmBXdlniinmJi0g3Lxmh72xEVpbBM8Q1t8w7scRbmOUNEPg7+nq6yToeZ
6WQYhduaVkDrtH+lekDeMP9niLtSwDUPb0c7TV1tHL9eyJuYrOlOHROmNQ6LZ7eW
0WVaq1ao0BDiTAs6JMvXl4krYaSQpnNjlDkMCd356cIL5+TmmV64JmdR0IG7pilB
ulO3P7VzXHHcQKJruQNNKNRK5RYN98QsAHVfdPXxj1wCIPZwmxd8/vI0zdqUunL1
3N6pvCE+Hm1lYDJic/0j9OwFjcvhUqU471PyiRCfybmnW2hrl48wC3YyJGdunf6I
4LkstT77YLc/MY3kW994F1cBsQzT5ga4DZPElxNEdAewOZGRwjgLTdliVbyqAs9m
XG/woc4LaZUMbzITy9JpVAMQSuDbmN6czHx4DsfvfpahzCSSIgo5dNt6+FV7tEy0
LmLO4OJQj1ldyqkoYaBs3P+r85ZDFkoOjxO4/w/nYldQF33ckgeLOjUDG/Yj/Nwa
M/nuVibG3I1M2e8dks6U3UzImsO066pFK7zQU/rnKncC4qYIeWQ8dwaxvrdotKlg
6iZhP6dyoOZtl3as6G3+TPeHdZWlvgBPF7CuJFYCgPis5GAfLic=
=w756
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Feb 26, 2018 at 01:32:00PM +0000, Simon Gaiser wrote:
> Marek Marczykowski-Górecki:
> [...]
> > I'd go with backporting patches to original Fedora's gcc.
>
> Fedora uses their own gcc snapshot in their package (i.e. not an
> upstream tarball). AFAICS Fedora does not host it directly anywhere.
> Where should qubes-builder downloads it from? Host it on
> ftp.qubes-os.org, Download the src.rpm or something else?

I'd host it on ftp.qubes-os.org, as we do with others not directly
reachable tarballs (see vmm-xen). Which exactly tarball should I upload?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqUb3YACgkQ24/THMrX
1yxHrgf/XYv6JR+VuEqJjHdrmiISGx4+q8nw0HSVbKys160I6JpPT+fp4zQYIZa8
HcWYulsRHJvSoyYw6MeYVqbPkvgi8x4R31q4gIPO1JKL+WaFj/UD6mvvZTtX0gQc
GsMdSnxW7GkSPGJNE7vKaAQC5ew3h1Bv1mbPGYVMd9mKlj366phbmKkb8hJ83F6G
lC8U3c7GkWQFKhIVCC5UmLmDLRJQ6M8mvuL59t81J2HUU0qeDhCrv6w75iWzB5u6
zFd6EWI5NMe/BRHUrEi24HKcr5a3qzO/elfLt80azefo9fbFK7/Gph6dRUjtgSIA
exK1Cjv4tfLa3aE9zE3p13RyosuVvA==
=se07
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> On Mon, Feb 26, 2018 at 01:32:00PM +0000, Simon Gaiser wrote:
>> Marek Marczykowski-Górecki:
>> [...]
>>> I'd go with backporting patches to original Fedora's gcc.
>
>> Fedora uses their own gcc snapshot in their package (i.e. not an
>> upstream tarball). AFAICS Fedora does not host it directly anywhere.
>> Where should qubes-builder downloads it from? Host it on
>> ftp.qubes-os.org, Download the src.rpm or something else?
>
> I'd host it on ftp.qubes-os.org, as we do with others not directly
> reachable tarballs (see vmm-xen). Which exactly tarball should I upload?

gcc-6.4.1-20170727.tar.bz2 from gcc-6.4.1-1.fc25.src.rpm

And for R3.2 we will need:

gcc-5.3.1-20160406.tar.bz2 from gcc-5.3.1-6.fc23.src.rpm
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqUcn8ACgkQkO9xfO/x
ly+A3xAAuUMPTj3fPazBTBONJtKHDQVxXc9maB5nB0ksw3vCzsE1zXC5vru9y4uc
k2GypoWRmSPVvSMHxcc2GQmpXEfvEZX4PN3sddm/kHlsg7kLtGwjk2UIpKs/rB7X
eHN/XGlf6mEXlaAAXrqY1OqA6nibr/AiZG5tumbQnjAnwkdUdRn4TPoXbjvcQdbU
3zFE55XZttoj0WCs5aDFJYgY/YI7XNFvbsqBoC8Gn2I4+VvJ2uS5oSGSQtpgIs0a
yiz0lOKFbhvUzYe8kIDDRSmx3f1epsuYXDe4WLK/wDiQwjCoBdXlwhujsPd0fusA
RouIDSFOlt4KglG1dxiL0hQmJzk+L0emCpLXgoYHZlG8HdrgDqakssIF0LsDMG7C
5Zdo/veZtGnUY346Rr8KV1tkWRmV4BjRuiibwVzEVM4NSdukGjxXCzg/jBUAnitn
TD4wqItoz7n4eH3kLf+i1F3Q0sH33zta3GdR7rgiqG35su0xA15XoeYBSeK81R3M
etGcBusBG9wM2pACJBR8ghgrxWajAdSHCkjhzZAkVuMoMRpYSAyoYRA338ouGXDl
Y0+lMVfO44g1H9RCULxFdN7j0ZaksukEhlPHoBcTxBv+M+4ty9lo/5cwPL5nvQW+
Yl9bTy1M9TpuE0RPg64TpitK+qal9PkvBaPznu3/f50xFrKfUVg=
=yqdg
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Feb 26, 2018 at 08:48:00PM +0000, Simon Gaiser wrote:
> Marek Marczykowski-Górecki:
> > On Mon, Feb 26, 2018 at 01:32:00PM +0000, Simon Gaiser wrote:
> >> Marek Marczykowski-Górecki:
> >> [...]
> >>> I'd go with backporting patches to original Fedora's gcc.
> >
> >> Fedora uses their own gcc snapshot in their package (i.e. not an
> >> upstream tarball). AFAICS Fedora does not host it directly anywhere.
> >> Where should qubes-builder downloads it from? Host it on
> >> ftp.qubes-os.org, Download the src.rpm or something else?
> >
> > I'd host it on ftp.qubes-os.org, as we do with others not directly
> > reachable tarballs (see vmm-xen). Which exactly tarball should I upload?
>
> gcc-6.4.1-20170727.tar.bz2 from gcc-6.4.1-1.fc25.src.rpm
>
> And for R3.2 we will need:
>
> gcc-5.3.1-20160406.tar.bz2 from gcc-5.3.1-6.fc23.src.rpm

Done: https://ftp.qubes-os.org/distfiles/

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqUjLYACgkQ24/THMrX
1yyDXQgAjlB2+49SWRh7jqH/I9wBmlRvu4/Idpa8FS1OOW/i3hO6qsal7Siq5LOZ
vP6Ub06d9YmG7qRmM5YaOtiHsP7U03dPnjVtAAMoHEM4nfcRtMkN2JRHJ6d2DsWn
z5PlZK9JEIZ2yV+ysPfGnm0RyT4nEdud2bRzaS3ws4wai31AglviSMIlofp7vi+k
oU88QWGiOwiQAVSqEM55HVSZ1TUajY89SME6ukS1MN6br3l1UZlTPrHL1ItJxwL2
9aHZZ/tglxRNB7TdCiar2FBNSrBXqEVQmuLRqY7auDsOBnziJX1QLktYcU8ASgiu
Idqc+tBq2XbmSaROzbDkGvV6hpYPRg==
=MeHW
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Simon Gaiser:
[...]

Ok, I think I know now where the problem comes from. In the Fedora 25
chroot libgcc-6.4.1-1.fc25.i686 is installed (notice the i686). We build
only for x86_64 so there's no update for the i686 variant. But I don't
understand why dnf install it when specified explicitly without removing
anything.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqWEBYACgkQkO9xfO/x
ly+4Bw//UhB8NygMaJFkAfZGQBAeBSvrghEHwkWaKQvyXJnyysdqGcfED8tSNhFh
7/Xsu1U8uDq0TFWLA+UQ6wEPMUhHOxq6aEMAiqB5XpNnclHz/gUIOWfCNKul2x7l
K2AHbBtRlLHXx5k7Wssrz92P5Z/sDomVOejK1y9kIc/jVfbyWv96lrAgOH+INI0G
ygJmEsZnEwhG+HGOxlPJwzdYAmE5d+zeFiTjDzpsw+/0e3JY8bi6yCM08luQdQ5N
lpMAJQ2tCOUgezutoWABbcGS+uMplYE8hf2Jk2ZrBGq6y8OiQE4R8BsvSgaTiJtL
IMrS1DRwiOjV2nGLWqYTqUkO8PCZS5vpt9lonjOxhzrjeAvKvROytAblIvs3Eg4b
PLXE/Dln+M8UYDWesSyScBQqJOVkaOHEcDxVk0ZOJTyyCEJBKVtI7CGAJKl0CT6s
dhehw/Ptby+mSy6Id7YwHDQAVzsRP7rxNQa9pupXXQKu/AymMOYlTLqEq9ixA/kT
jWf5cmeRmKueAg+KtSB7aJcc931eLqxJwf5/jBFU9a+UEhpfsod+uVqYYoJiF16o
nKkTuHWU2vbC+cT0zCnktXlXpxPskJlXvieu59XFJ48zI2lvk7S08sR5OuQxnDSn
2TlMBawTUZuePaloJzEWz5KR9pw7S3d70hS4g6nFA137l80EqmM=
=8/lh
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

We have just updated Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.

The text of the main changes are reproduced below. For the full
text, please see the complete QSB in the qubes-secpack:

<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.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 XSA-254 in the XSA Tracker:

<https://www.qubes-os.org/security/xsa/#254>

```
Changelog
==========

2018-01-11: Original QSB published
2018-01-23: Updated mitigation plan to XPTI; added Xen package versions

2018-03-14: Updated package versions with Spectre SP2 mitigations

[...]

(Proper) patching
==================

## Qubes 4.0

[...]

Additionally, Xen provided patches to mitigate Spectre variant 2. While
we don't believe this variant is reliably exploitable to obtain
sensitive information from other domains, it is possible to use it
for help with other attacks inside a domain (like escaping a sandbox
of web browser). This mitigation to be fully effective require
updated microcode - refer to your BIOS vendor for updates.

The specific packages that contain the XPTI and Spectre variant 2
patches for Qubes 4.0 are as follows:

- Xen packages, version 4.8.3-3

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update

For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.

## Qubes 3.2

[...]

Additionally, Xen provided patches to mitigate Spectre variant 2. While
we don't believe this variant is reliably exploitable to obtain
sensitive information from other domains, it is possible to use it
for help with other attacks inside a domain (like escaping a sandbox
of web browser). This mitigation to be fully effective require updated
microcode - refer to your BIOS vendor for updates.

The specific packages that contain the XPTI and Spectre variant 2
patches for Qubes 3.2 are as follows:

- Xen packages, version 4.6.6-37

[...]

```

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/03/15/qsb-37-update/

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqrE18ACgkQ203TvDlQ
MDApFw/8DZdF/WhE31coNPbW7tbroScuADS08kWhWG7QkiYqtzoERCq1TIxNfEiU
KEMlpw28NJc+/NlesPEM/lB9W21eyR9VcIUea9aO98gwX938iTVT2MTMD0lwinnb
Qg+K/jmAW8LMnJ2kDHZ93+GhAuLU9NOUZVdsmnF5tNsmW7NIKDgk7Fx8pGb32u9c
nVL5HVd0SX1QLEanFZ7Jgapstt+6nVfkayCSZEp4gFpzF+drWRdJL/0Z0Qi6EJYr
x29UKFuU+WPqNutxcL88usCwBthOuOgpdh0D+LxnIMaZfjkT002403Vcgqd3DrAw
Jclwh+VOg+e5S4/fA3fFxeRhPrSJuuSvQ2Ik8WUhaE5p10gS6TAoP+fR0z7zBSZ9
7teiZQMORoTWWj02TmoUuf3sL9sEsec6IC+obTKtGr6qU5ntW2RDhMGiQetQO3zU
jyro7p2cGVc8B6SSEZ//bUOpGTujppTAsrK/KAMZQ8Plu/KWOzuCdgIrnFRcoSsW
NPONF8BASlFLUg/hjPbuO0NQwyWYOnejwhaaEcCP4eU9/dudLAvUWb9oTWGevwq5
o29TalXxx7+ZqJXeYt3MECv0pYv/GzeZtX50vaknJjmBYMtoF5l7s8AjiwtgvJep
85j4sMIH/8R/VmqqdpH/HZUkjB7R1/hRpp144mLqvOelvd8OP5Q=
=Z2TQ
-----END PGP SIGNATURE-----