Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A warning about 5.12-rc1

lwn.net

Post reply on HN
Print view View original

101–110 of 115 posts

Re: A warning about 5.12-rc1

#101

Post by dale_glass »

londons_explore wrote: post #83
dale_glass wrote: post #71

Earlier quoted context omitted.

It could get very messy. Think of it: 1. Something asks for memory from the kernel. 2. Kernel doesn't have enough free memory, goes to offload something old to swap. 3. Swap file is too small, needs to be extended. This calls the "extend file size" filesystem code. 4. Filesystem code tries to allocate memory for keeping track of filesystem data. 5. Goto 1. As far as I understand, the "swap file on filesystem" system…

A simple solution to this would be for a filesystem to say "I guarantee that if RAM allocation fails, I will still be able to extend a swapfile". In most filesystems, extending an already open file is fairly straightforward - it's usually a matter of writing just a single block. Since this is an incredibly rare case, there is no strict performance requirement. It could use an approach to filesystems like grub which i…

Such guarantees aren't easy.

And come on, "writing a single block"? No, that's what it looks like on the user side of things. In the kernel it's going to be a good deal more complicated, because how does anything know anything about this block you just added? You need to keep track of it somehow.

Inside the kernel you need to go find some free space to use for this extra block, and to update whatever metadata is needed to make things consistent. It might well turn out that the block you're using to keep track of what blocks belong to this file is just full, so now you have to allocate another block for filesystem metadata. Then there's issues like journalling. And doing all that while providing the guarantee that you won't need to allocate memory is likely tricky.

Re: A warning about 5.12-rc1

#102

Post by lumpa »

raverbashing wrote: post #97
lumpa wrote: post #89

Earlier quoted context omitted.

Comment rom "Helping Out with LTS Kernel Releases"[0]: "I find it amusing that the answer to "how can I help test" is "that people test the -rc releases when I announce them, and let me know if they work or not for their systems/workloads/tests/whatever". No smoke tests, no automated tools, no suggested workloads, no fuzzing, just "fool around and report back". There probably are lots of kernel testing tools around,…

Several people booting their favourite distro with the new kernel stresses a lot of areas at once. Yes, it's a manual test, but it "does the job" (or 99% of it at least)

It would do an even better job if the user could easily increase coverage or depth of that stressing and check against known issues (regressions). Maybe `make kselftest` is the way to go. But it might be worth creating an easy way for people to help test the kernel, something like Debian popcon meets CPU-Z benchmarks.

Re: A warning about 5.12-rc1

#103

Post by benlivengood »

encryptluks2 wrote: post #82
tremon wrote: post #67

Earlier quoted context omitted.

Since the bootloader for my encrypted disk isn't on there, it is harder to determine that it even exists. How does make it harder to determine your encrypted partition exists? The usual way encryption aids plausible deniability is through multiple keys, e.g. when one key unlocks a seemingly innocuous-looking installation, while the other unlocks the nasty bits. Having an encrypted partition in plain sight offers no p…

> How does make it harder to determine your encrypted partition exists? Because it just looks like random data that hasn't been formatted. > Having an encrypted partition in plain sight offers no plausible deniability at all to me, especially if it contains a default LUKS header. First, I do use a detached LUKS header. The LUKS header is on the USB drive. The machine functions fine and appears to be a regular Windows…

> Because it just looks like random data that hasn't been formatted.

I'm guessing that SSDs also give up the secret if an attacker has access to custom firmware to read the wear-levelling metadata and finds a bunch of recent writes in the random data.

At this point, unless speed or capacity are at a premium, it probably makes more sense to completely boot and run off of a fast USB drive. Linux + LUKS-header will be fairly obvious on the USB boot drive anyway, making plausible deniability pretty hard.

What's the threat model? State-level attackers (e.g. journalists working with Snowden) or the border police wanting you to provide a passphrase for stored data or to boot a system? For the latter a good solution is don't transport anything important across the border.

Re: A warning about 5.12-rc1

#104

Post by pdonis »

_-___________-_ wrote: post #38
pdonis wrote: post #25

Earlier quoted context omitted.

Would the bug Linus is describing still bite you if your swap is in a separate LVM partition? (That's how Ubuntu 20.04 sets things up by default.)

Only if it's a swap file on a filesystem on that LVM partition, and even then if the filesystem is otherwise empty then there's no other data to accidentally overwrite, you might just trash the filesystem structure.

Then, if I'm understanding this correctly, the default setup in Ubuntu (at least in Ubuntu 20.04, which I happen to have installed on a couple of laptops recently), which has been mentioned both in this discussion and in the lwn.net article discussion, should be safe from the bug, since that setup, if you enable full-disk encryption, sets up two LVM partitions, one for root (called "vgubuntu-root") and one for swap (called "vgubuntu-swap"). They show up as separate LVM partitions in fdisk. The swap appears to me to just directly use the "vgubuntu-swap" partition.

Re: A warning about 5.12-rc1

#105

Post by gpvos »

unionpivo wrote: post #46
gpvos wrote: post #37

Earlier quoted context omitted.

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 orga…

Of course. Thanks for stating a lot of mostly obvious things.

Assuming there is a test suite (I really don't know enough about Linux kernel testing, sorry), it is a matter of testing that on a representative set of configurations. Apparently no-one thought of having one with a swap file instead of a swap partition. That's okay, it's an understandable oversight, but one that clearly should be remedied.

Re: A warning about 5.12-rc1

#106

Post by _-___________-_ »

pdonis wrote: post #104
_-___________-_ wrote: post #38

Earlier quoted context omitted.

Only if it's a swap file on a filesystem on that LVM partition, and even then if the filesystem is otherwise empty then there's no other data to accidentally overwrite, you might just trash the filesystem structure.

Then, if I'm understanding this correctly, the default setup in Ubuntu (at least in Ubuntu 20.04, which I happen to have installed on a couple of laptops recently), which has been mentioned both in this discussion and in the lwn.net article discussion, should be safe from the bug, since that setup, if you enable full-disk encryption, sets up two LVM partitions, one for root (called "vgubuntu-root") and one for swap (…

Sounds fine. It would be strange if vgubuntu-swap contained an actual filesystem with a single file on it (the swap file).

Re: A warning about 5.12-rc1

#107

Post by travv0 »

1996 wrote: post #22

As no one did a TLDR: if you use a swapfile, it could overwrite part of the the filesystem where the swapfile exist. Don't use swapfiles if you can. Use a dedicated partition, there are many advantages (including automatic RAID0 if you have a swap partition on each drive)

If you click the link, there's a TL;DR right up at the top, under the title.

Re: A warning about 5.12-rc1

#108

Post by xodice »

samus wrote: post #62
pbhjpbhj wrote: post #57

Earlier quoted context omitted.

I used to use a swap partition, but then if you get the partition size wrong you're lumbered with it. Why wouldn't you use a file. At one point in the past I used the default (or recommended) /boot size and got stuck a couple of years later juggling at updates to fit the boot files into the partition. I just use a monolithic partition per OS per disk now and swap files within that. Is that not good practice (for home…

`/home` should be separate from the system so you can reinstall it without trouble. Same for `/var` (or subdirectories) if you value the data of particular services. Other than that, the bootloader and EFI must be able to access certain directories like `/boot` and `/boot/efi`. As long as it works for your use cases, everything is alright. Edit: A swap file has a little bit of overhead because of the underlying file…

The Linux kernel doesn't rely on the filesystem for swap files insuring no more overheard than swap partitions. It bypasses the filesystem and is told what blocks it can use, that's why some filesystems do not support swapfiles as there is additional plumbing to be done.

Re: A warning about 5.12-rc1

#110

Post by sys_64738 »

the_duke wrote: post #64

I used to assume that Linux had a huge test suite with hundreds of thousands of tests, given the crazy feature matrix that the kernel has to support. And that they would have started requiring tests for new features and bug fixes. Alas, that's not the case. There are a few external test suites like the Linux Test Project [1], but nothing that looks very extensive. The process seems to mostly rely on maintainers givin…

This is the checks & balances of the many eyes looking at code and eating your own dog food. These method succeed when you have a torrent of users but fail at smaller scale more often.
Post reply on HN