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. > > -- > 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 _______________________________________________ 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
