| Message ID | 20220717234805.1084386-1-jane.chu@oracle.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v3] x86/mce: retrieve poison range from hardware | expand |
+ 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
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.
> 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
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
On Mon, Jul 18, 2022 at 09:11:33PM +0000, 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
diff --git a/arch/x86/kernel/cpu/mce/apei.c b/arch/x86/kernel/cpu/mce/apei.c index 717192915f28..a8274fd57add 100644 --- a/arch/x86/kernel/cpu/mce/apei.c +++ b/arch/x86/kernel/cpu/mce/apei.c @@ -37,7 +37,7 @@ void apei_mce_report_mem_error(int severity, struct cper_sec_mem_err *mem_err) m.bank = -1; /* Fake a memory read error with unknown channel */ m.status = MCI_STATUS_VAL | MCI_STATUS_EN | MCI_STATUS_ADDRV | MCI_STATUS_MISCV | 0x9f; - m.misc = (MCI_MISC_ADDR_PHYS << 6) | PAGE_SHIFT; + m.misc = (MCI_MISC_ADDR_PHYS << 6) | __ffs64(mem_err->physical_addr_mask); if (severity >= GHES_SEV_RECOVERABLE) m.status |= MCI_STATUS_UC;
With Commit 7917f9cdb503 ("acpi/nfit: rely on mce->misc to determine poison granularity") that changed nfit_handle_mce() callback to report badrange according to 1ULL << MCI_MISC_ADDR_LSB(mce->misc), it's been discovered that the mce->misc LSB field is 0x1000 bytes, hence injecting 2 back-to-back poisons and the driver ends up logging 8 badblocks, because 0x1000 bytes is 8 512-byte. Dan Williams noticed that apei_mce_report_mem_error() hardcode the LSB field to PAGE_SHIFT instead of consulting the input struct cper_sec_mem_err record. So change to rely on hardware whenever support is available. Link: https://lore.kernel.org/r/7ed50fd8-521e-cade-77b1-738b8bfb8502@oracle.com Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jane Chu <jane.chu@oracle.com> --- arch/x86/kernel/cpu/mce/apei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)