Live data from Hacker News

A warning about 5.12-rc1

lwn.net

41–50 of 115 posts

Re: A warning about 5.12-rc1

#41

> And, as far as I know, all the normal distributions set things up with swap partitions, not files I guess Ubuntu is not a "normal" distribution then? Because it uses a swap file by default.

Not always I guess. The 20.04 and 20.10 installer with LUKS enabled created a swap partition for me.

Re: A warning about 5.12-rc1

#42
post #30

> it didn't even show up in normal testing, exactly because swapfiles just aren't normal. Uhh, does it mean swapfiles are undertested in the Linux kernel? Or is there some "non-normal" extra testing that is being run for non-rc releases, but not for rc ones? (!?)

I fear you grossly overestimate how detailed the kernel's testing is. (Do please note that the word "detailed" above was carefully chosen.)

While the Kernel team directly may not be as involved in testing the Linux Kernel to the extent that dedicated QA team would be, there are multiple billion dollar organizations like IBM (Red Hat), Oracle, etc that do a lot of automated testing. Given the amount of issues with Windows as well, especially for Insider builds, it doesn't make me lose trust in the Linux kernel anymore than I'd trust a Windows operating system. In fact, because it was caught before it would regular distro users it gives me more trust.

Re: A warning about 5.12-rc1

#43
post #11

Earlier quoted context omitted.

Swapfiles are quite common when you use FDE (say, LUKS) and you don't want your swap to be in plaintext on disk. (Although, you could just have an entire LUKS-encrypted swap volume instead of a swapfile...)

While maybe not the most performant my favorite is LVM2 on top of a single large LUKS-encrypted partition (+no boot partition and a single (custom platform key) signed EFI bootable kernel blob containing the initram fs in the EFI partition). This: - Allows a encrypted swap partition (on in lvm2 on top of luks, sure not perfect but I don't really use swap) - Allows hibernation (which I don't really use tbh.) - Fully e…

You still need an unencrypted EFI partition given what you describe, and the signed unified kernel image lives there, which means that you do in fact have a boot partition. My /boot mount is my EFI partition.

However, an alternative is having your EFI partition reside on a USB drive that in turn boots into your encrypted partition.

Re: A warning about 5.12-rc1

#44
post #11
post #6

this is unlikely to hurt you unless you use a swap file , rather than a dedicated swap partition. for performance reasons most any modern linux installation would be using a dedicated swap partition, that is defined as swap-only during the install process with mkswap In my experience some of the reasons for using a swap file were more common maybe 10 or 15 years ago. Nowadays with disk space being less costly and rar…

Swapfiles are quite common when you use FDE (say, LUKS) and you don't want your swap to be in plaintext on disk. (Although, you could just have an entire LUKS-encrypted swap volume instead of a swapfile...)

In the most recent Debian installer, if you want to do FDE, it does:

partition > LUKS > LVM > swap volume

That way you get encrypted swap without having swap be a file in your filesystem.

Re: A warning about 5.12-rc1

#45
post #32

Earlier quoted context omitted.

It is a lot more uncommon for MBR-based boot partitions these days. It is no longer the default for Windows. With EFI and GPT, it is a lot simpler. Linux can use a Windows EFI boot partition, or vice-versa. Additionally, in my specific case I have a separate EFI partition saved on a USB stick for booting my encrypted root partition. It adds plausible deniability.

> It adds plausible deniability. How so?

Because the disk drive has a Windows-styled layout and EFI partition. The encrypted partition just looks like random data. Since the bootloader for my encrypted disk isn't on there, it is harder to determine that it even exists.

There is no requirement on what type of partition type you use for your LUKS2 encrypted partition, so ideally you'd use something that isn't going to be apparent.

Then, as long as knowledge of a tiny USB drive or micro SD card existing isn't known (which is a lot easier to hide) it is more difficult to discover that an encrypted partition even exists.

Re: A warning about 5.12-rc1

#46
post #37

Earlier quoted context omitted.

The email mentions that normal testing didn't catch it as it's not a typical use-case for the devs apparently.

Which is exactly why automated testing exists, to catch cases like this.

Automated testing is not magic. it only tests things you make it test.

And since kernel is basically involved into everything that computer does, you would have to test everything, to find every error. Linux kernel is also extremely customizable, so that it can run from watches, to mars rowers, to HPC and cloud.

Linux kernels are continuously heavily tested on various different hardware architectures, by various organizations (RH, IBM, Oracle, Google).

So there are automated tests done. It's just seems nobody tested this.

Re: A warning about 5.12-rc1

#47
post #6

this is unlikely to hurt you unless you use a swap file , rather than a dedicated swap partition. for performance reasons most any modern linux installation would be using a dedicated swap partition, that is defined as swap-only during the install process with mkswap In my experience some of the reasons for using a swap file were more common maybe 10 or 15 years ago. Nowadays with disk space being less costly and rar…

If you are using budget vps, it is likely you will want to enable it. Because vps tend to not setup a swap partition at all. And you are unlikly to reformat a vps to add a swap partition.

Re: A warning about 5.12-rc1

#48
post #20

Earlier quoted context omitted.

But if you suddenly need it and don't have it, you'll get segfaults (I assume). Sounds a bit too dangerous for me :p

You'll get OOM killed as if you ran out of RAM. This doesn't happen unless the program is buggy. Moreover, if your working set is larger than RAM, you're screwed regardless. So don't do that. Swap exists so you can use more RAM for the disk cache. It's doesn't exist so that buggy programs can crawl instead of dying

> if your working set is larger than RAM, you're screwed regardless.

I mean, this is patently false. I've used 1TB swapfiles to get out of a sticky situation with some terrible research software that used a ton of memory to solve really valuable problems.

There's nothing wrong with an absolute shit ton of swap when the alternative is OOM.

Re: A warning about 5.12-rc1

#49
post #30

> it didn't even show up in normal testing, exactly because swapfiles just aren't normal. Uhh, does it mean swapfiles are undertested in the Linux kernel? Or is there some "non-normal" extra testing that is being run for non-rc releases, but not for rc ones? (!?)

> Uhh, does it mean swapfiles are undertested in the Linux kernel? Or is there some "non-normal" extra testing that is being run for non-rc releases, but not for rc ones? (!?)

My understanding is that is the point of RC builds, they are the builds used for testing before a stable release.

Re: A warning about 5.12-rc1

#50
post #5

I was interested to see the code. Linus's message doesn't provide commit IDs, so you have to go looking yourself. I believe this is the commit which introduces the bug: https://github.com/torvalds/linux/commit/48d15436fde6feebcde... And I believe this is the commit which fixes it: https://github.com/torvalds/linux/commit/caf6912f3f4af723234...

The fix makes me feel a little uneasy.

It changes the behaviour of swap_page_sector() to take into account the offset. But swap_page_sector() was already used before the bug was introduced, a few lines earlier in the bdev_write_page() fast path, as introduced by this commit from 2014: https://github.com/torvalds/linux/commit/dd6bd0d9c7dbb395100...

So either:

1. The bdev_write_page() call was also broken, and has been for years, or

2. The bdev_write_page() uses the sector value differently, worked fine with the old swap_page_sector(), but is now broken with the new version, or

3. The change in swap_page_sector() somehow doesn't affect bdev_write_page(); maybe it's a noop when using swap files?

Post reply on HN