Re: is it possible to add a new filter to detect unusable partition types
> On Dec 17, 2024, at 16:34, Heming Zhao wrote: > > Hi LVM2 maintainers, > > One of SUSE's customers encountered an issue with LVM2. The user created > several partitions, one of which was marked as "BIOS boot" (4) instead of > "LINUX LVM" (8E). Subsequently, the user ran pvcreate/vgcreate/lvcreate on > this partition. During a system update, grub2-install installed GRUB2 in the > "BIOS boot" partition, resulting in LVM2 metadata corruption. > > The root cause of this issue is that grub2-install targets the "BIOS boot" > partition when this lvm2 device is specified for installation. If the user > had initially marked the partition as "LINUX LVM", grub2-install would not > have chosen this partition. > > On the other hand, it would be beneficial if LVM2 could implement a new > filter or a filter function to detect and exclude the "BIOS boot" partition > from being considered a valid target for LVM2 device creation. This could > involve issuing a warning or error message to alert the user of the potential > conflict. This may also help user to notice the issue more easily. > > Best regards, > Heming Also Cc util-li...@vger.kernel.org and grub-devel@gnu.org as it’s not an issue with lvm but also other fs progs. It would be great if we can enhance libblkid to avoid data loss even caused by user mistakes. — Su
Re: is it possible to add a new filter to detect unusable partition types
Dne 17. 12. 24 v 10:13 Glass Su napsal(a): On Dec 17, 2024, at 16:34, Heming Zhao wrote: Hi LVM2 maintainers, One of SUSE's customers encountered an issue with LVM2. The user created several partitions, one of which was marked as "BIOS boot" (4) instead of "LINUX LVM" (8E). Subsequently, the user ran pvcreate/vgcreate/lvcreate on this partition. During a system update, grub2-install installed GRUB2 in the "BIOS boot" partition, resulting in LVM2 metadata corruption. The root cause of this issue is that grub2-install targets the "BIOS boot" partition when this lvm2 device is specified for installation. If the user had initially marked the partition as "LINUX LVM", grub2-install would not have chosen this partition. On the other hand, it would be beneficial if LVM2 could implement a new filter or a filter function to detect and exclude the "BIOS boot" partition from being considered a valid target for LVM2 device creation. This could involve issuing a warning or error message to alert the user of the potential conflict. This may also help user to notice the issue more easily. Hi lvm2 is using blkid to detect 'present' signature on a block device - and normally prompt to confirm wiping such signature. We may possibly add similar logic for 'partition signatures'. However there is still the plain fact that lvm2 with --force or even just '--yes' option is assumed to simply proceed and clean&clear such conflicting signatures and simply makes the block device to be a PV. All that said IMHO primary bug here is within 'grub2-install' which simply should not be blindingly overwriting block device which is in use - this should be fixed ASAP as there is the biggest risk of data loss, although I guess everyone is using 'grub2-install --force' - as without this option (even in my personal experience) is typically refusing to do any work And same applies to most UI tools I've seen that use lvm2 - all seem to be pushing '--force & --yes' with each it emitted lvm2 command... Regards Zdenek
Re: [PATCH v2] tpm2_key_protector: dump PCRs on policy fail
On Tue, Dec 17, 2024 at 11:45:32AM +0800, Gary Lin wrote: > On Tue, Dec 17, 2024 at 09:35:34AM +0800, Gary Lin wrote: > > On Mon, Dec 16, 2024 at 05:28:34PM +0100, Daniel Kiper wrote: > > > On Thu, Dec 12, 2024 at 02:11:24PM +0800, Gary Lin wrote: > > > > PCR mismatching is one common cause of TPM key unsealing fail. Since the > > > > system may be compromised, it is not safe to boot into OS to get the PCR > > > > values and TPM eventlog for the further investigation. > > > > > > > > To provide some hints, GRUB now dumps PCRs on policy fail, so the user > > > > can check the current PCR values. PCR 0~15 are chosen to cover the > > > > firmware, bootloader, and OS. > > > > > > > > The sample output: > > > > > > > > PCR Mismatching! Check firmware and bootloader before typing passphrase! > > > > TPM PCR [sha256]: > > > > 00: 115c89bfa0e59e050cda5d2664031d225305f3582cf0c2afcb7c1f1ac2a7cf8d > > > > 01: 079b3eadca25e10248daea4b1d508e5cfb703db28386be809a0b375c0a0a80a5 > > > > 02: 2cd8ec3de6a07e1fd39676100db57ba62372e820c19812fee55899f65746e192 > > > > 03: 9423b585d4eac05c97a0c06bca8898ad0ca519a6b810dcb91129bcdc10f4b112 > > > > 04: fa36bf5c9110d3891f040e2146d157484cd41123fa8faf4bc6b91db3d12b70ca > > > > 05: 13e9ea9e38e5258e6ee2b6ae94a3cece0137490ef95c65caaac10cdf5e1bc40d > > > > 06: 3ac10d749054a818806788f4e4eaa2fb4dd7d13ce0e99dc175145b63c34bb71c > > > > 07: a6657a60f77928cad614a7ad153ab9ae0bed48e33b70348ae11a26762002b3bc > > > > 08: 42e04f5bac1965535cb6bdb30c62bb199b1ba21d1ec6b22d0da159dfc925b8bb > > > > 09: 5c83e8be79d4a432e6d409610de389ee6f1ac0c193f38d84a9ff94f360bd458b > > > > 10: > > > > 11: > > > > 12: > > > > 13: > > > > 14: 894dd8e4ca1bb62e055f674f9390a39c4643ebdd1014702feef000c47e36a003 > > > > 15: > > > > error: failed to unseal sealed key (TPM2_Unseal: 0x99d). > > > > error: no key protector provided a usable key for luks > > > > (af16e48f-746b-4a12-aae1-c14dcee429e0). > > > > > > If you do this why do not add also a GRUB command to dump all PCRs, > > > including DRTM ones. > > > > > Sure, a new command would be helpful to inspect PCRs with GRUB shell. > > I'll add the command in v3. > > > There is one problem with the command. Since GRUB always measures the > commands into PCR 8, so the PCR dump command may also affect PCR 8 and > the user may never get a stable PCR 8. It is a problem with every GRUB command, even ls. So, I would not care much here. Though I think we should add a blurb to the GRUB documentation saying about side effect of running commands from the GRUB shell. And I would add a GRUB command, including its documentation, in the separate patch. So, we will have two patches then... Or three if we count a blurb mentioned above as a separate patch. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: is it possible to add a new filter to detect unusable partition types
On Tue, Dec 17, 2024 at 11:21:26AM +0100, Zdenek Kabelac wrote: > Dne 17. 12. 24 v 10:13 Glass Su napsal(a): > > > > > On Dec 17, 2024, at 16:34, Heming Zhao wrote: > > > > > > Hi LVM2 maintainers, > > > > > > One of SUSE's customers encountered an issue with LVM2. The user created > > > several partitions, one of which was marked as "BIOS boot" (4) instead of > > > "LINUX LVM" (8E). Subsequently, the user ran pvcreate/vgcreate/lvcreate > > > on this partition. During a system update, grub2-install installed GRUB2 > > > in the "BIOS boot" partition, resulting in LVM2 metadata corruption. > > > > > > The root cause of this issue is that grub2-install targets the "BIOS > > > boot" partition when this lvm2 device is specified for installation. If > > > the user had initially marked the partition as "LINUX LVM", grub2-install > > > would not have chosen this partition. > > > > > > On the other hand, it would be beneficial if LVM2 could implement a new > > > filter or a filter function to detect and exclude the "BIOS boot" > > > partition from being considered a valid target for LVM2 device creation. > > > This could involve issuing a warning or error message to alert the user > > > of the potential conflict. This may also help user to notice the issue > > > more easily. > > Hi > > lvm2 is using blkid to detect 'present' signature on a block device - and > normally prompt to confirm wiping such signature. > > We may possibly add similar logic for 'partition signatures'. > > However there is still the plain fact that lvm2 with --force or even just > '--yes' option is assumed to simply proceed and clean&clear such > conflicting signatures and simply makes the block device to be a PV. > > All that said IMHO primary bug here is within 'grub2-install' which simply > should not be blindingly overwriting block device which is in use - this > should be fixed ASAP as there is the biggest risk of data loss, although I > guess everyone is using 'grub2-install --force' - as without this option > (even in my personal experience) is typically refusing to do any work IMHO, the BIOS Boot partition is dedicated to grub boot code and cannot be shared with other software. Any attempt other than grub writing to this area should be prohibited, it should not be the other way around. Furthermore, adding such check could lead to unexpected failures if the data is a leftover. Grub does not write blindly, it checks that the partition is indeed a BIOS Boot partition before writing to it, as the user is required to explicitly set the partition type. For LVM root with legacy BIOS boot, having a BIOS Boot partition is mandatory, otherwise grub won't have usable space to embed the boot code in the GPT partition layout, and you won't be able to boot or access a functional system in the first place. That said, the BIOS Boot partition is in use by grub before it is mistakenly used to create a PV and extend the LVM root onto it. It is unlikely that GRUB is overwriting it. In such cases, it's more likely the other way around. Thanks, Michael > > And same applies to most UI tools I've seen that use lvm2 - all seem to be > pushing '--force & --yes' with each it emitted lvm2 command... > > Regards > > Zdenek >
Re: is it possible to add a new filter to detect unusable partition types
On Tue, Dec 17, 2024 at 11:21:26AM +0100, Zdenek Kabelac wrote: > Dne 17. 12. 24 v 10:13 Glass Su napsal(a): > > > > > On Dec 17, 2024, at 16:34, Heming Zhao wrote: > > > > > > Hi LVM2 maintainers, > > > > > > One of SUSE's customers encountered an issue with LVM2. The user created > > > several partitions, one of which was marked as "BIOS boot" (4) instead of > > > "LINUX LVM" (8E). Subsequently, the user ran pvcreate/vgcreate/lvcreate > > > on this partition. During a system update, grub2-install installed GRUB2 > > > in the "BIOS boot" partition, resulting in LVM2 metadata corruption. > > > > > > The root cause of this issue is that grub2-install targets the "BIOS > > > boot" partition when this lvm2 device is specified for installation. If > > > the user had initially marked the partition as "LINUX LVM", grub2-install > > > would not have chosen this partition. > > > > > > On the other hand, it would be beneficial if LVM2 could implement a new > > > filter or a filter function to detect and exclude the "BIOS boot" > > > partition from being considered a valid target for LVM2 device creation. > > > This could involve issuing a warning or error message to alert the user > > > of the potential conflict. This may also help user to notice the issue > > > more easily. > > Hi > > lvm2 is using blkid to detect 'present' signature on a block device - and > normally prompt to confirm wiping such signature. > > We may possibly add similar logic for 'partition signatures'. > > However there is still the plain fact that lvm2 with --force or even just > '--yes' option is assumed to simply proceed and clean&clear such > conflicting signatures and simply makes the block device to be a PV. > > All that said IMHO primary bug here is within 'grub2-install' which simply > should not be blindingly overwriting block device which is in use - this > should be fixed ASAP as there is the biggest risk of data loss, although I > guess everyone is using 'grub2-install --force' - as without this option > (even in my personal experience) is typically refusing to do any work > > And same applies to most UI tools I've seen that use lvm2 - all seem to be > pushing '--force & --yes' with each it emitted lvm2 command... If prompts were in a machine-parsable format, tools that used lvm2 could differentiate between ones that should automatically be responded to with "yes" and ones that should not. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [PATCH v2] tpm2_key_protector: dump PCRs on policy fail
On Tue, Dec 17, 2024 at 03:29:02PM +0100, Daniel Kiper wrote: > On Tue, Dec 17, 2024 at 11:45:32AM +0800, Gary Lin wrote: > > On Tue, Dec 17, 2024 at 09:35:34AM +0800, Gary Lin wrote: > > > On Mon, Dec 16, 2024 at 05:28:34PM +0100, Daniel Kiper wrote: > > > > On Thu, Dec 12, 2024 at 02:11:24PM +0800, Gary Lin wrote: > > > > > PCR mismatching is one common cause of TPM key unsealing fail. Since > > > > > the > > > > > system may be compromised, it is not safe to boot into OS to get the > > > > > PCR > > > > > values and TPM eventlog for the further investigation. > > > > > > > > > > To provide some hints, GRUB now dumps PCRs on policy fail, so the user > > > > > can check the current PCR values. PCR 0~15 are chosen to cover the > > > > > firmware, bootloader, and OS. > > > > > > > > > > The sample output: > > > > > > > > > > PCR Mismatching! Check firmware and bootloader before typing > > > > > passphrase! > > > > > TPM PCR [sha256]: > > > > > 00: 115c89bfa0e59e050cda5d2664031d225305f3582cf0c2afcb7c1f1ac2a7cf8d > > > > > 01: 079b3eadca25e10248daea4b1d508e5cfb703db28386be809a0b375c0a0a80a5 > > > > > 02: 2cd8ec3de6a07e1fd39676100db57ba62372e820c19812fee55899f65746e192 > > > > > 03: 9423b585d4eac05c97a0c06bca8898ad0ca519a6b810dcb91129bcdc10f4b112 > > > > > 04: fa36bf5c9110d3891f040e2146d157484cd41123fa8faf4bc6b91db3d12b70ca > > > > > 05: 13e9ea9e38e5258e6ee2b6ae94a3cece0137490ef95c65caaac10cdf5e1bc40d > > > > > 06: 3ac10d749054a818806788f4e4eaa2fb4dd7d13ce0e99dc175145b63c34bb71c > > > > > 07: a6657a60f77928cad614a7ad153ab9ae0bed48e33b70348ae11a26762002b3bc > > > > > 08: 42e04f5bac1965535cb6bdb30c62bb199b1ba21d1ec6b22d0da159dfc925b8bb > > > > > 09: 5c83e8be79d4a432e6d409610de389ee6f1ac0c193f38d84a9ff94f360bd458b > > > > > 10: > > > > > 11: > > > > > 12: > > > > > 13: > > > > > 14: 894dd8e4ca1bb62e055f674f9390a39c4643ebdd1014702feef000c47e36a003 > > > > > 15: > > > > > error: failed to unseal sealed key (TPM2_Unseal: 0x99d). > > > > > error: no key protector provided a usable key for luks > > > > > (af16e48f-746b-4a12-aae1-c14dcee429e0). > > > > > > > > If you do this why do not add also a GRUB command to dump all PCRs, > > > > including DRTM ones. > > > > > > > Sure, a new command would be helpful to inspect PCRs with GRUB shell. > > > I'll add the command in v3. > > > > > There is one problem with the command. Since GRUB always measures the > > commands into PCR 8, so the PCR dump command may also affect PCR 8 and > > the user may never get a stable PCR 8. > > It is a problem with every GRUB command, even ls. So, I would not care > much here. Though I think we should add a blurb to the GRUB documentation > saying about side effect of running commands from the GRUB shell. > > And I would add a GRUB command, including its documentation, in the > separate patch. So, we will have two patches then... Or three if we > count a blurb mentioned above as a separate patch. > Okay. I have another patch series to improve the NV index support, and I'll merge this patch into that patchset with two more patches: one for the command and the other for the document. Gary Lin ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
