On Thu, Jul 28, 2022, at 2:11 AM, Vojtech Trefny wrote: > On Wed, Jul 27, 2022 at 5:53 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> >> >> On Wed, Jul 27, 2022, at 11:11 AM, Chris Adams wrote: >> > Once upon a time, Neal Gompa <ngompa13@xxxxxxxxx> said: >> >> My understanding is that Windows preloads are now blank-encrypted. >> >> That is, there's a BitLocker volume wrapping the filesystem, even with >> >> encryption turned off. It makes encrypting the disk later >> >> significantly easier (it doesn't have to do filesystem resizing and >> >> reallocation games). >> > >> > Huh, okay. It seems cryptsetup can't open it, but dislocker can. >> >> You can do something like >> >> dd if=/dev/nvme0n1p5 skip=1024000 count=2048 2>/dev/null | hexdump -C >> >> And see if that 1MiB range looks like ciphertext (garbage) or plaintext. I wouldn't be surprised if it's encrypted, and the encryption key itself isn't wrapped, it's just exposed in the Bitlocker metadata in a way dislocker can discover and cryptsetup can't (yet) - but I'm speculating. > > This is also what happens if you choose to "decrypt" your BitLocker > volume in Windows so if it is this case, cryptsetup doesn't support > it. We intentionally ignored this case mostly because it looked like a > small corner case (if you choose do decrypt the volume, Windows will > in the end fully decrypt the data and get rid of the BitLocker > volume/container), but if it's going to be a widespread use, we might > need to start looking into that. As Milan said, a reproducer and an > upstream issue for cryptsetup would be nice. > >> >> >> > But this does mean that doing anything in anaconda based on detection of >> > BitLocker being present should consider that... >> >> Either libblkid or cryptsetup would need to learn how to differentiate between the two kinds of Bitlocker volumes, in order for anaconda to have a chance of treating them differently. I'm not sure what the consideration would be though. > > If it really is the case described above, from libblkid point of view, > this is still BitLocker and the data is still encrypted so no > difference in how it should be handled -- mount cannot mount it, > ntfsresize cannot resize it so for all intents and purposes it is a > BitLocker volume and we cannot treat it differently just because the > volume key itself is not protected. > I think one of the thread responders was thinking that it would be possible to still use a GRUB menu entry for the decrypted BitLocker case. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
