I wonder, as we usually use upstream defaults. However, at least in my case, my LUKS2 headers are without --allow-discard by default, but I set them up already late 2022 / early 2023. So that is not representative for new installations.
If there had been a recent change, I might have overseen it, but afaik, we use only periodic trim, once a timer of systemd, and async trim is set by the kernel as default as well (if using defaults of Fedora). I think to remember there was a debate to remove one of the two. Anyway, that is far less invasive than continuous trim.
If TRIM impacts dm-crypt, it might be assumed that a sophisticated attack is able to identify your file system with a high probability, but for most users, that is public information anyway.
That said, I agree that from a crypto point of view, it is generally considered a bad practice to allow any leak of data/information, even if it feels trivial, because one can never prove in what circumstances this piece of data/information can fill “gaps” for an attacker. It’s in the end a performance/confidentiality trade-off.
Not the perfect / conclusive answer you might have hoped for, but the only thing I can provide off the cuff
I assume your information about --allow-discards is obtained from the flags of your LUKS header?
My understanding is upstream dm-crypt (cryptsetup) folks do not default to allow discards because of security concerns. The “holes” that results from discards reveals the write pattern at the least, which I guess could expose the file system to ciphertext attacks. Not my area. But anyway, Fedora looked into it and decided the security risk was low and so the feature change went through … in 2017? Jeez, that was a long time ago.
Upstream btrfs made discard=async the default with kernel 6.2, ~Feb 2023. This does not conflict with fstrim.timer/service which is also enabled by default.
Not the best foundation for decision making But yes, I agree, risk’s likely low for the majority, or from an alternative PoW, what can be revealed is unlikely to be worth protecting for the vast majority, at least not for that “price”.
I wonder why it’s disabled on my two LUKS2 devices, but I cannot exclude I set them up manually. I definitely setup the Adiantum device manually, but wonder of the AES-XTS device I have. Anyway, that at least would explain it for 2022.
Interesting, so we kept both In some mailing list I think to have read there was a discussion about it (I’m fine with it, just to avoid misunderstandings;)
@py0xc3 The installer sets persistent cryptsetup flag in LUKS header and this is where I saw it after installing F43 in a virtual machine. As a matter of fact, it turns out that it has been doing this for a few years already. It’s Blivet that got this option fairly recently now I think.
My systems do not have this flag set, but I did partition manually, like you. So it looks like had we used the default partitioning scheme, our systems would “silently” enable allow-discards for LUKS.
Actually, in my case its “really” disabled. No allow-discards. But I don’t have a default crypttab either, so that can explain why my system differs to the default, also in the result. It’s too long ago, so I don’t remember if I removed it manually or if it occurred by other means. I just documented the goals+results, not the way (indeed something I will improve in future).
Anyway, I don’t see it too critical. It’s an acceptable compromise for the majority imho. I would expect that users for whom it is not, would know and adjust (or use a different OS for related purposes anyway).
The very case you raise is actually more about how the dm-crypt devices had been setup/defaulted, and how they are opened/decrypted (depending on the case, either one of the two, or a combination of both), rather than how the mapped (decrypted) devices are partitioned.
I might review though, how this is implemented in current Fedoras. I currently do some testing with a package on different Fedora defaults. I might check it out during some of the tests. I wonder if that is still implemented through the crypttab, as described in the old proposal.
It would be an interesting project to find out if the impact of TRIM differs among AES-XTS and Adiantum, but I guess that would be a major (resource intensive) project
But yes, I agree, risk’s likely low for the majority, or from an alternative PoW, what can be revealed is unlikely to be worth protecting for the vast majority, at least not for that “price”.
In some mailing list I think to have read there was a discussion about it (I’m fine with it, just to avoid misunderstandings;)