- Edited
Hey everyone,
As many of you know, there is currently a series of vulnerabilities called Boothole that have been found by researchers and patched for GRUB2, which is used by many operating systems for booting.
While Solus uses GRUB2 for legacy BIOS, we do not use it for UEFI support (unlike the likes of Ubuntu) but rather use a utility called clr-boot-manager that is responsible for EFI loader creation, which are stored in a EFI System Partition (ESP) and used by systemd-boot. Additionally, we do not support Secure Boot.
So vulnerabilities related to UEFI support and Secure Boot do not affect Solus. However, there are some heap-based buffer overflow vulnerabilities such as CVE-2020-14309 and CVE-2020-14310 which could technically affect Solus, however given the tooling used to generate the grub configuration (clr-boot-manager does this), the process to both provide a vulnerable kernel, modules, etc. in addition to knowing you're specifically on Solus to run CBM, and more, I am fairly confident that the ability for somebody to exploit these vulnerabilities is extremely small and would likely require physical access.
That being said, obviously we want to exercise caution and ensure that an update to grub2 is delivered in a timely manner. These vulnerabilities were not disclosed to Solus and other operating systems (such as Arch Linux) which do not used trusted paths to shims and so we found out on the 29th like everyone else. Here is a quote on what the process was regarding disclosure:
Disclosures were done to a subset of binary distributions that have a trust path to shims signed with Microsoft UEFI CA 2011 db key. Arch Linux does not provide shim-signed with keys controlled by Arch Linux and it doesn't provide pre-signed secureboot kernels.
Source: https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00048.html
I spent some time yesterday working out a series of patches based on grub2's source tree, however given its vulnerability patches also apply changes on top of code that didn't exist in the 2.04 release in the first place (some LVM changes, JSON support, etc.) I needed to scrap that idea and opted to move us to git based builds instead.
This was done today, which is the day of sync. Given I don't have any remotely up-to-date system that uses legacy BIOS, I opted to exercise caution and hold off the update to GRUB2 until after the sync was complete, which happened while I was at the store about 30 minutes ago (about 2020-07-31T16:30:00+03:00). The update is in the unstable repository and both @Girtablulu and @Staudey were kind enough to test it.
Of course, I don't want anybody to have a broken system, and want to ensure that a reasonable amount of test coverage is done before I can sync this to the stable / shannon repository, which will be an out-of-band sync and occur as soon as sufficient testing is provided (in other words, no you're not going to be waiting until next Friday).
If you are on Legacy BIOS (easiest way is to see if you have a /etc/grub.d/10_com.solus-project file) and want to help test this update, please do the following:
- Install the update:
sudo eopkg install https://mirrors.rit.edu/solus/packages/unstable/g/grub2/grub2-2.04-27-1-x86_64.eopkg - Run:
sudo clr-boot-manager update - Reboot
If you see any warnings related to not being able to connect to lvmetad, you're probably not using LVM / Full Disk Encryption. It's a warning and can typically be ignored.
Information I would like
- Did you successfully boot into Solus?
- Are you using LVM?
- Are you using Full Disk Encryption? (If so, answer to #2 is yes as well)
Please do not run this update and provide feedback if you are using an EFI-based system. While I appreciate the willingness to update, it'll just create more noise. Additionally, if you are having unrelated issues (like "omg this one specific sound device doesn't work"), please don't post them here. It'll get deleted and I'll be grumpy. The more focused this is, the more testing that is done, the sooner I can get this out to everyone.
Thanks <3
