81–90 of 115 posts
Like... is swap file support going shortcuts in the kernel so that it can corrupt the file system the swap file is residing on? Because (at least in my hope) no matter of write() or whatever calls on a file handle should cause a filesystem corruption...
Earlier quoted context omitted.
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 o…
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…
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 PC without the USB drive, with an extra partition that doesn't have encrypted data in plain sight. It would look like random data, which to someone else wouldn't know if I did a secure wipe and that it is waiting to be partitioned or if it is just old data that has since repurposed after resizing. I'm sure they could find out if they pry hard enough, especially if trimming is enabled or if they really started to question why the supposed random data can't be recovered to produce files.
Why are swap files/partitions constant size? Most of the time, I don't need any swap at all, and any swap file/partition is wasted space. While hibernated, I need ~the amount of system ram as swap. While running some horrendous matlab script, I need about 1TB of swap. Yet linux won't dynamically allocate it like other files. I'm forced to constantly resize it manually to save space or be able to do more things.
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…
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 involves reading and writing just a single block at a time.
This is a dedicated data partition that LVM managed to procure a data volume that user land encryption performs on for a swap partition.
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…
Basically the offset passed to bdev_write_page() was wrong, and has been like that since it was introduced to swap code back in v3.16.
In practice this means that the same filesystem corruption could happen with swapfiles sitting on top of filesystems which are created on top of block devices that bdev_write_page() supports (in specific: brd, zram, btt, pmem). This appears to be a non-common setup that apparently was not encountered. Nevertheless the fix is being backported to all stable kernels to cover those use-cases.
edit: bdev_write_page() was never broken, just the offset handed to it was wrong.
I guess because I use a swapfile I am not normal according to Linus? Haha, I just find it easier to use a swap file when dual-booting Windows and my Linux install is encrypted. Otherwise, it'd me more work to ensure my swap partition is encrypted.
I recently ended up using swapfiles because I refactored my disk layout and it was just simpler to chuck the swap on an existing nvme partition. I realised an extra benefit: you can make it a sparse file, so it never even uses disk space at all until you actually need it, which could be never.
AFAIK, this cannot work. The swap code does not go through the filesystem, it bypasses the filesystem (it only asks the filesystem code for the swap file extents during the "swapon" call), and it's the filesystem that would be responsible for allocating disk space when writing to a sparse file.
I'd find it interesting to read an analysis how this bug could have happened from a technical point. Like... is swap file support going shortcuts in the kernel so that it can corrupt the file system the swap file is residing on? Because (at least in my hope) no matter of write() or whatever calls on a file handle should cause a filesystem corruption...
Earlier quoted context omitted.
There's a cheaper, easier option. Just buy a new SSD for each OS you plan to run. A bit more expensive than messing with MBRs, but we'll... No more partition or MBR to deal with anymore. Well worth $50.
That's a perfect solution if you're already using the largest/fastest SSDs available, but otherwise be aware that you're sacrificing throughput: Each 1TB SSD will have around half the throughput of a single 2TB SSD because large SSDs are essentially a RAID0+ECC array of smaller SSDs
If you want a 2TB data drive, go on ahead. Both Linux and Windows handle multiple drives just fine.
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…
"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, but you wouldn't learn that from the linked article."
It seems to be conscious choice, to the point of developers stating that "the process works". Which, looking at the results, it does seem to work. But wouldn't it work better with more tests, easily run by users wanting to help? I mean, if a downstream patch in related code regresses the issue, is there a new test added with this fix that would catch that?
Edited to add: it seems that the situation is changing for the better, with gregkh saying in a comment: "`make kselftest` seems to do what you want today, if there are any gaps the kernel developers are glad to take more tests."
Why are swap files/partitions constant size? Most of the time, I don't need any swap at all, and any swap file/partition is wasted space. While hibernated, I need ~the amount of system ram as swap. While running some horrendous matlab script, I need about 1TB of swap. Yet linux won't dynamically allocate it like other files. I'm forced to constantly resize it manually to save space or be able to do more things.
The answer to why a partition is constant size: you are permanently reserving that amount of disk space, that's what a partition is. Swapfiles aren't dynamic for the same reason, but, you can have multiple swapfiles, and when they are empty, you can discard them. If you really want dynamic swap, you can run swapfiled, which will monitor memory usage and create and mount swapfiles of a given granularity on demand. If…
why would you assume that having a machine with 1TB of free space means that you have any way of spending money ?