2020-04-08
Why you want a Linux bootloader even on UEFI systems
One of the reactions to my entry on the complexity of Linux bootloaders is to say that all of this is unnecessary on modern UEFI systems. On a UEFI system, you can just put all of your Linux kernel environments in the EFI system partition and give them (U)EFI boot menu entries to let the user choose between them. Unfortunately there are a number of problems with this on anything except the simplest systems, both in practice and in general.
On the practical level, many systems have a very limited number of UEFI boot menu entries, which means that you can only support a handful of kernels and boot environments (for things like a recovery option); how many you can support also goes down if you need a dual-boot system. Often people want to keep a decent number of kernels available, although arguably this is mostly historical at this point. More importantly, UEFI BIOSes have historically been not very happy to have boot entries updated all of the time. Boot entries are EFI variables, and UEFI BIOSes have traditionally assumed that EFI variables wouldn't be updated very often. In addition to the problem of constantly changing the NVRAM, BIOSes have had bugs and problems here, simply because churning through lots of changes is unusual behavior that Windows doesn't do.
One general issue is that you are putting things that change and that you need to be available into the EFI system partition, which is a FAT32 filesystem on a single disk. If you want to have a server with redundant disks that can survive (and reboot) after the total failure of one disk, you need to keep your two (or more) EFI system partitions in sync with each other, and also insure that the UEFI boot menu can use both of them somehow. Some people will tell you that you can use Linux software RAID mirroring here with the right magic; in practice, this is reportedly rather fragile (there are many exciting ways for the sides of the mirror to get out of sync with each other, since sometimes they are accessed outside of the software RAID) and may not work with any particular UEFI BIOS. Certainly it's not likely to be something that UEFI BIOS vendors either support or test.
Another issue is that UEFI boot menu entries don't necessarily support Linux specific features like modifying the kernel command line, which can be necessary in special circumstances. In addition to kernel parameters, a variety of Linux initramfs and init systems assume that you can modify kernel command line parameters to control their behavior, to turn on extra debugging messages or to start the system in single user mode or the like. You could do this with additional UEFI boot menu entries, but then you run into practical limits on how many a UEFI BIOS will support and how many people can sort through.
So while you can directly load Linux through UEFI with the kernel's EFISTUB support (also), the result is not up to the standards that people want and expect from a Linux boot environment, at least on servers. It might be okay for a Linux machine with a single disk where the user will only ever boot the most recent kernel or the second most recent one (in case the most recent one doesn't work), and if that doesn't work they'll boot from some alternate Linux live media or recovery media.
There can be differences in what malware variants anti-spam systems distinguish
For reasons beyond the scope of this entry, we're currently using ClamAV in parallel with our current commercial filter, running incoming email past both of them. In keeping an eye on our logs, one of the interesting things I've noticed is that sometimes, one system will report that several messages are all malware X while the other system thinks that the messages have different malware in them.
That's abstract, so let me make it concrete. Recently, PureMessage recognized what it called 'CXmail/OleDl-BI' in five messages. Meanwhile, ClamAV recognized 'SecuriteInfo.com Malware XML.Autoload-1' in two and 'Porcupine Win32 Exploit CVE-2017-11882 C 84612' in three. All five messages had .xlsx attachments; in the emails where ClamAV recognized XML.Autoload we could determine file extension information in the ZIP archives, but in the other three we could not.
ClamAV's signature formats are documented, so it's possible to examine ClamAV's signature database and determine that the CVE-2017-11882 match is based on a specific MD5 hash (I believe of a 471040 byte object), while the XML.Autoload-1 match is based on finding certain text near the end of a 'text' file or object (I suspect that this includes individual files in a ZIP archive, but I don't know for sure). PureMessage's matching is a black box.
This difference doesn't mean that one system is better and one is worse here; we don't have anywhere near enough information to say either way. This could be one single sort of malware, which PureMessage is recognizing some deep characteristic of while ClamAV is recognizing two different superficial signs, depending on how the malware has packed itself. Alternately, it could be two somewhat different types of malware, which ClamAV is distinguishing apart while PureMessage is matching on some common feature.
(Sophos's information page on CXmail/OleDl-BI says that it occurs in both password protected Microsoft Office 2007 documents and regular Office ones.)
I find all of this interesting, and it's a useful reminder to me that no two malware filtering systems are going to behave exactly the same even when they both recognize that something has malware.