[qubes-devel] Update for QSB-101: Register File Data Sampling (XSA-452) and Intel Processor Return Predictions Advisory (INTEL-SA-00982)

2024-03-25 Thread Andrew David Wong 
Dear Qubes Community,

*Update*: Marek Marczykowski-Górecki’s PGP signature is now available (see 
below).

We have updated [Qubes Security Bulletin (QSB) 101: Register File Data Sampling 
(XSA-452) and Intel Processor Return Predictions Advisory 
(INTEL-SA-00982)](https://github.com/QubesOS/qubes-secpack/blob/345734de68d6994d99f461f26e63a09043d4c09c/QSBs/qsb-101-2024.txt).
 The text of this updated QSB (including a changelog) and its accompanying 
cryptographic signatures are reproduced below, followed by a general 
explanation of this announcement and authentication instructions.

## Qubes Security Bulletin 101

```

 ---===[ Qubes Security Bulletin 101 ]===---

  2024-03-12

  Register File Data Sampling (XSA-452) and
 Intel Processor Return Predictions Advisory (INTEL-SA-00982)

Changelog
--

2024-03-12: Original QSB
2024-03-17: Add information about INTEL-SA-00982

User action


Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary


On 2024-03-12, the Xen Project published XSA-452, "x86: Register File
Data Sampling" [3]:

| Intel have disclosed RFDS, Register File Data Sampling, affecting some
| Atom cores.
|
| This came from internal validation work.  There is no information
| provided about how an attacker might go about inferring data from the
| register files.

For more information, see Intel's security advisory. [4]

In addition, Intel published INTEL-SA-00982/CVE-2023-38575 [6] on the
same day:

| Non-transparent sharing of return predictor targets between contexts
| in some Intel® Processors may allow an authorized user to potentially
| enable information disclosure via local access.

Information about this vulnerability is very sparse.

Impact
---

On systems affected by Register File Data Sampling (RFDS), an attacker
might be able to infer the contents of data previously held in floating
point, vector, and/or integer register files on the same core, including
data from a more privileged context.

On systems affected by INTEL-SA-00982, an attacker might be able to leak
information from other security contexts, but the precise impact is
unclear.

Affected systems
-

At present, Register File Data Sampling (RFDS) is known to affect only
certain Atom cores from Intel. Other Intel CPUs and CPUs from other
hardware vendors are not known to be affected. RFDS affects Atom cores
between the Goldmont and Gracemont microarchitectures. This includes
Alder Lake and Raptor Lake hybrid client systems that have a mix of
Gracemont and other types of cores.

At the time of this writing, Intel has not published information about
which systems INTEL-SA-00982 affects. Systems that are still receiving
microcode updates from Intel [7] and that received a microcode update as
part of the microcode release on 2024-03-12 [5] may be affected, even if
they are not affected by RFDS.

Patching
-

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

  For Qubes 4.1, in dom0:
  - Xen packages version 4.14.6-7
  - microcode_ctl 2.1-57.qubes1

  For Qubes 4.2, in dom0:
  - Xen packages version 4.17.3-4
  - microcode_ctl 2.1-57.qubes1

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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [1]

Dom0 must be restarted afterward in order for the updates to take
effect.

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.

Credits


See the original Xen Security Advisory.

References
---

[1] https://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-452.html
[4] 
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html
[5] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20240312
[6] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00982.html
[7] 
https://www.intel.com/content/www/us/en/support/articles/22396/processors.html

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

```

*Source*: 


## [Marek 
Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s
 PGP signature

```
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmYAyxAACgkQ1lWk8hgw

Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?

2024-03-25 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Mar 25, 2024 at 12:34:18PM -, qubist wrote:
> On Mon, 25 Mar 2024 12:45:17 +0100 Marek Marczykowski-Górecki wrote:
> 
> > IMO the main advantage of the single table approach is purely
> > port-based rules (UDP or TCP), but the default firewall doesn't have
> > many of them. They may be relevant for custom-input chain (but not
> > always - sometimes you might want to use IP address in those too),
> > and rarely for custom-forward.
> 
> What do you mean? Using an IP address is possible in inet table too.

Yes, but you need separate rules for IPv4 and IPv6 anyway, so the
benefit of combined table is minimal.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBcogACgkQ24/THMrX
1ywrjAf/Uc7SvayVEarHjEKQ9bZDqCPp0+5bOYDFVhSgvLYzVjchku/teYehAtVJ
Pe1LMrdeawIDUk2va3VCldS5zpjEoABDG68a2e4AR3QSFbw3pT4QlpH/0FiTOD1j
aDjs2INgChAFi0hinw7oDt2H89IFc0ZQcFZhYhYR/3R8oZEJDoMAhazP4cAZnkI+
gaHCuptr0BP8nNVRsj6pjPLm779PD2821uF/jIKZIW+hTuG5xvmIQ9/d0XPvC6th
APbkUUzFOeII+D0sHO7F6/SlrBxMV6iqdoUwOG7sWKGUTW5FdgA92/OOOl6vGj8C
xllZmVSwKkMedB41HnMkS5eLHiB+IA==
=LcEW
-END PGP SIGNATURE-

-- 
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/ZgFyiPSajbxi2wxL%40mail-itl.

Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?

2024-03-25 Thread qubist 
On Mon, 25 Mar 2024 12:45:17 +0100 Marek Marczykowski-Górecki wrote:

> IMO the main advantage of the single table approach is purely
> port-based rules (UDP or TCP), but the default firewall doesn't have
> many of them. They may be relevant for custom-input chain (but not
> always - sometimes you might want to use IP address in those too),
> and rarely for custom-forward.

What do you mean? Using an IP address is possible in inet table too.

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

Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?

2024-03-25 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Mar 23, 2024 at 07:55:17PM -, qubist wrote:
> On Sat, 23 Mar 2024 13:05:39 + 'unman' via qubes-devel wrote:
> 
> > However, the 4 and 6 rulesets are distinct and although they could be
> > merged to a single table, the result would not be any cleaner. While
> > there is some duplication, there are also distinctions.
> > Sometimes keeping separate tables allows for greater clarity.
> 
> I am not quite sure what you mean by cleaner and greater clarity.
> Compare the 2 files I am attaching.
> 
> separate.nft - as it is currently in Qubes
> single.nft - a quick attempt to merge them into a single inet table
> 
> separate - 133 lines
> single - 82 lines
> 
> I have not made any performance comparison but in regards to
> simplicity, single.nft looks simpler to me. Perhaps it can be optimized
> even more, e.g. dropping invalid packets in early in prerouting hook
> instead of letting them to input.
> 
> What do you think? Has any optimization been considered?

A single table is surely shorter, but TBH I'm not sure if it's clearer.
Some rules needs to be duplicated for v4 and v6, some don't. IMO the main
advantage of the single table approach is purely port-based rules (UDP
or TCP), but the default firewall doesn't have many of them. They may be
relevant for custom-input chain (but not always - sometimes you might
want to use IP address in those too), and rarely for custom-forward. 

In any case, changing it now is not an option. It would mean changing
the API for custom rules, which was a huge pain for users migrating to
R4.2, and we are not going to do that _again_ now.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBY80ACgkQ24/THMrX
1yzebgf/dkFXbsl7FYfgeqPEJTZ/HMPWieXum7vI06FpuLlHncPMhbJ833prtAvK
CIZF/iEEOsngyiGT0VaH45NO3H4QBDftikwDQ3eB91+qJ792zcmaiuOj9LYStka4
XdsMhCbZsH8PeVfU36z7DGlZZ0lay1dAgqH4lVYu+LAA55mNFB6CqHLKq/APnrk9
Iopuz8m7AA8yEQ4lrAvYtFY3OpKQpKv0VZhDTtrILj0io7JdTzWNAbD0EFJmr7po
YW3j+kuRCTEUK0c4wD00mU5ZAytEdjgZuKQSTnfbEbrzOxSOvY+6E5a4B+SnqA0D
BciowS1par9BQDTZUsKnYPUIa0qySg==
=CtoI
-END PGP SIGNATURE-

-- 
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/ZgFjzUYGEWwhdevV%40mail-itl.