Re: [PATCH v3] x86/mce: retrieve poison range from hardware
On Mon, Jul 18, 2022 at 09:11:33PM +, Jane Chu wrote: > On 7/18/2022 12:22 PM, Luck, Tony wrote: > >> It appears the kernel is trusting that ->physical_addr_mask is non-zero > >> in other paths. So this is at least equally broken in the presence of a > >> broken BIOS. The impact is potentially larger though with this change, > >> so it might be a good follow-on patch to make sure that > >> ->physical_addr_mask gets fixed up to a minimum mask value. > > > > Agreed. Separate patch to sanitize early, so other kernel code can just use > > it. > > > > Is it possible that with >if (mem->validation_bits & CPER_MEM_VALID_PA_MASK) > the ->physical_addr_mask is still untrustworthy? The validation_bits just show which fields the BIOS *says* it filled in. If a validation bit isn't set, then Linux should certainly ignore that field. But if it is set, then Linux needs to decide whether to use the value, or do a sanity check first. -Tony
Re: [PATCH v3] x86/mce: retrieve poison range from hardware
On 7/18/2022 12:22 PM, Luck, Tony wrote: >> It appears the kernel is trusting that ->physical_addr_mask is non-zero >> in other paths. So this is at least equally broken in the presence of a >> broken BIOS. The impact is potentially larger though with this change, >> so it might be a good follow-on patch to make sure that >> ->physical_addr_mask gets fixed up to a minimum mask value. > > Agreed. Separate patch to sanitize early, so other kernel code can just use > it. > Is it possible that with if (mem->validation_bits & CPER_MEM_VALID_PA_MASK) the ->physical_addr_mask is still untrustworthy? include/ras/ras_event.h has this if (mem->validation_bits & CPER_MEM_VALID_PA_MASK) __entry->pa_mask_lsb = (u8)__ffs64(mem->physical_addr_mask); else __entry->pa_mask_lsb = ~0; which hints otherwise. apei_mce_report_mem_error() already checks mem->validation_bits up front. thanks! -jane > -Tony
RE: [PATCH v3] x86/mce: retrieve poison range from hardware
> It appears the kernel is trusting that ->physical_addr_mask is non-zero > in other paths. So this is at least equally broken in the presence of a > broken BIOS. The impact is potentially larger though with this change, > so it might be a good follow-on patch to make sure that > ->physical_addr_mask gets fixed up to a minimum mask value. Agreed. Separate patch to sanitize early, so other kernel code can just use it. -Tony
RE: [PATCH v3] x86/mce: retrieve poison range from hardware
Luck, Tony wrote: > +m.misc = (MCI_MISC_ADDR_PHYS << 6) | __ffs64(mem_err->physical_addr_mask); > > Do we want to unconditionally trust the sanity of the BIOS provided > physical_address_mask? > > There's a warning comment on the kernel __ffs64() function: > > * The result is not defined if no bits are set, so check that @word > * is non-zero before calling this. > > Otherwise, this looks like a good idea. It appears the kernel is trusting that ->physical_addr_mask is non-zero in other paths. So this is at least equally broken in the presence of a broken BIOS. The impact is potentially larger though with this change, so it might be a good follow-on patch to make sure that ->physical_addr_mask gets fixed up to a minimum mask value.
RE: [PATCH v3] x86/mce: retrieve poison range from hardware
+ m.misc = (MCI_MISC_ADDR_PHYS << 6) | __ffs64(mem_err->physical_addr_mask); Do we want to unconditionally trust the sanity of the BIOS provided physical_address_mask? There's a warning comment on the kernel __ffs64() function: * The result is not defined if no bits are set, so check that @word * is non-zero before calling this. Otherwise, this looks like a good idea. -Tony