XSAs released on 2021-11-23

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)
----------------------------------------------------------------

The following XSAs *do affect* the security of Qubes OS:

- XSA-388
- XSA-389

Please see *QSB-074* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:

<https://www.qubes-os.org/news/2021/11/24/qsb-074/>


XSAs that do not affect the security of Qubes OS (no user action required)
--------------------------------------------------------------------------

The following XSAs *do not affect* the security of Qubes OS, and no
user action is necessary:

- XSA-385 (DoS only; Qubes has BIGMEM disabled)
- XSA-387 (Qubes has grant tables v2 disabled)


Related links
-------------

- Xen XSA list: <https://xenbits.xen.org/xsa/>
- Qubes XSA tracker: <https://www.qubes-os.org/security/xsa/>
- Qubes security pack (qubes-secpack):
<https://www.qubes-os.org/security/pack/>
- Qubes security bulletins (QSBs): <https://www.qubes-os.org/security/qsb/>


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/11/24/xsas-released-on-2021-11-23/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

[Qubes]

Andrew David Wong wrote:
> Dear Qubes Community,
>
> The Xen Project has released one or more Xen Security Advisories (XSAs).
> The security of Qubes OS *is affected*.
> Therefore, *user action is required*.
>

When I run update using the orange sun icon the dom0 update finishes
with the following text

"Updating dom0

local:
----------"

And that is it. When I run update from CLI I get this,

"Error Summary
-------------
Disk Requirements:
At least 33MB more space needed on the /boot filesystem."

Is that normal behavior? The disk /boot lives on is not full, the
complaint is with /boot specific.

[awokd]

Qubes:

> And that is it. When I run update from CLI I get this,
>
> "Error Summary
> -------------
> Disk Requirements:
>    At least 33MB more space needed on the /boot filesystem."
>
> Is that normal behavior? The disk /boot lives on is not full, the
> complaint is with /boot specific.

What does "df -h" say about /boot? If it's full and you've been updating
the system for a while, check for old EFI images that haven't been
cleaned up.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[Qubes]

'awokd' via qubes-users wrote:
> Qubes:
>
>> And that is it. When I run update from CLI I get this,
>>
>> "Error Summary
>> -------------
>> Disk Requirements:
>>     At least 33MB more space needed on the /boot filesystem."
>>
>> Is that normal behavior? The disk /boot lives on is not full, the
>> complaint is with /boot specific.
>
> What does "df -h" say about /boot? If it's full and you've been updating
> the system for a while, check for old EFI images that haven't been
> cleaned up.
>

df -h shows /boot is full, 100% used.

I am not sure how to fix this, can you please give me advice?

Looking at ls -l for /boot I can see a lot of old images, but I guess
that is because I have set my system to keep 15 kernels. However, I have
been on the 5.xxx kernel now since it was launched so I can safely
remove the 4.xxxx kernels. How does one clean this up properly. If I
just delete the files from /boot the system may still think they are
there, is there a built-in process/procedure to follow for this?

[awokd]

Qubes:

> df -h shows /boot is full, 100% used.
>
> I am not sure how to fix this, can you please give me advice?
>
> Looking at ls -l for /boot I can see a lot of old images, but I guess
> that is because I have set my system to keep 15 kernels. However, I have
> been on the 5.xxx kernel now since it was launched so I can safely
> remove the 4.xxxx kernels. How does one clean this up properly. If I
> just delete the files from /boot the system may still think they are
> there, is there a built-in process/procedure to follow for this?
>

The steps in
https://linuxconfig.org/how-to-remove-old-unused-kernels-on-centos-linux
should work, except the one about package-cleanup command. It's OK to
skip that step as removing one by one will work.

[Qubes]

'awokd' via qubes-users wrote:
> The steps in
> https://linuxconfig.org/how-to-remove-old-unused-kernels-on-centos-linux
> should work, except the one about package-cleanup command. It's OK to
> skip that step as removing one by one will work.
>

Thank you. I didn't know you do it through the package manager, that was
painless.

Is there Qubes documentation outlining the steps to increase the size of
/boot, or does one follow general disk management, with tools like using
GParted for example. Although the disk is a LUKS encrypted volume. Can
one decrypt, use GParted to resize, and then encrypt again?

[awokd]

Qubes:

> Is there Qubes documentation outlining the steps to increase the size of
> /boot, or does one follow general disk management, with tools like using
> GParted for example. Although the disk is a LUKS encrypted volume. Can
> one decrypt, use GParted to resize, and then encrypt again?
>

Note that /boot itself is not encrypted, but you're right, you would
have to decrypt the rest to resize it. No Qubes specific docs. Procedure
you describe should work, but might be further ahead by backing up your
VMs to a removable encrypted drive, doing a fresh install of R4.1 (rc2
last I saw) and adjusting the boot partition size on the installer
screen, then restoring?

[Qubes]

'awokd' via qubes-users wrote:
> Qubes:
>
>> Is there Qubes documentation outlining the steps to increase the size
>> of /boot, or does one follow general disk management, with tools like
>> using GParted for example. Although the disk is a LUKS encrypted
>> volume. Can one decrypt, use GParted to resize, and then encrypt again?
>>
> Note that /boot itself is not encrypted, but you're right, you would
> have to decrypt the rest to resize it. No Qubes specific docs. Procedure
> you describe should work, but might be further ahead by backing up your
> VMs to a removable encrypted drive, doing a fresh install of R4.1 (rc2
> last I saw) and adjusting the boot partition size on the installer
> screen, then restoring?
>

To be honest right after my last post I had exactly the same thought.
Thank you for making the suggestion as well, I think I will go this
route. I was very excited when the GUI domain was announced and have
been waiting for it like a kid getting an ice cream.

Are you currently running it, can you give any feedback?

[awokd]

Qubes:

> Are you currently running it, can you give any feedback?

Yes, running 4.1. Haven't tried gui or audio domains yet, but so far
everything works fine. Think a couple people have run into no QWT being
available for 4.1, but it's not something I need.

[Qubes]

'awokd' via qubes-users wrote:
> Qubes:
>
>> Are you currently running it, can you give any feedback?
>
> Yes, running 4.1. Haven't tried gui or audio domains yet, but so far
> everything works fine. Think a couple people have run into no QWT being
> available for 4.1, but it's not something I need.
>

A couple of things I am not sure of doing a backup, fresh install of 4.1
rc2, and then restoring, is for example current templates, like Debian
10 as well as all the clones of this template for example and the
customizations done to each. Is it possible to directly 'transfer'
Templates via backup/restore method to 4.1 rc2. Does one need to perhaps
install new qubes-specific-packages for new
features/integration/or-the-like things to work. Or should everything
pretty much work out the 'box'?

[Frédéric Pierret]

Le 11/28/21 à 10:10, Qubes a écrit :

It does not work out of the box. Migrating your template from R4.0 to R4.1 need manual steps like adding Qubes R4.1 repositories and upgrade your templates. As you will not be able to have GUI once your template from R4.0 are restored into R4.1, you will need to use "virsh console" into dom0 to access your templates.

Best regards,
Frédéric

[awokd]

Frédéric Pierret:

Most (but not all, now that you mention it) of my Debian 10 templates &
AppVMs restored to 4.1 as is and remained usable. I ended up having to
mount the private volume of one that wouldn't and copying the data out.
I'm taking advantage of the re-install to rebuild the templates I use as
fresh Debian 11 versions, and switching AppVMs over to them as I go.

[Ulrich Windl]

On 11/26/21 3:47 PM, Qubes wrote:
> 'awokd' via qubes-users wrote:
>> Qubes:
>>
>>> And that is it. When I run update from CLI I get this,
>>>
>>> "Error Summary
>>> -------------
>>> Disk Requirements:
>>>     At least 33MB more space needed on the /boot filesystem."
>>>
>>> Is that normal behavior? The disk /boot lives on is not full, the
>>> complaint is with /boot specific.
>>
>> What does "df -h" say about /boot? If it's full and you've been
>> updating the system for a while, check for old EFI images that haven't
>> been cleaned up.
>>
>
> df -h shows /boot is full, 100% used.
>
> I am not sure how to fix this, can you please give me advice?
>
> Looking at ls -l for /boot I can see a lot of old images, but I guess
> that is because I have set my system to keep 15 kernels. However, I have

Interestingly I see three kernels (and corresponding initramfs) here,
but only one Xen version. So it seems kernels have versioning, but not Xen.
Of my 700MB /boot 41% (283MB) are used.

[Ulrich Windl]

On 11/27/21 11:03 AM, 'awokd' via qubes-users wrote:
> Qubes:
>
>> Is there Qubes documentation outlining the steps to increase the size
>> of /boot, or does one follow general disk management, with tools like
>> using GParted for example. Although the disk is a LUKS encrypted
>> volume. Can one decrypt, use GParted to resize, and then encrypt again?
>>
> Note that /boot itself is not encrypted, but you're right, you would

Since GRUB can load LUKS-encrypted /boot, one could even encrypt /boot,
but a part of GRUB is also encrypted then, it seems. At least there
isn't much GRUB functionality until the LUKS volume is unlocked.
And it seems you only have one attempt to enter the passphrase
correctly. Also GRUB decryption seems much slower than kernel decryption...

[Qubes]

Following on from this conversation i have upgraded all of my templates
on Qubes 4.0 to Debian-11 and Fedora-35 (i will upgrade to Fedora-36 on
4.1). My question is now if someone can be more specific about what i
would need to do to my Debian-11 and Fedora-35 templates on 4.1 if i do
a backup on 4.0 which i restore to 4.1.

I may have overlooked it but is there documentation that covers this? I
don't know off the cuff how to change the repos in my templates to 4.1.
Then, if i change the repos in the templates to 4.1 do i just need to
perform a regular update using the update widget and the update process
will take care of the rest? Or(And)?

Looking at it at from a one to one perspective, how do i make a template
restored from 4.0 to 4.1 work exactly like the same template created on 4.1.