linux-kernel - Re: [PATCH 2/3] x86/mce: Define amd_mce_usable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5428166a-2a27-b400-f013-541309dcee5c@linux.alibaba.com>
Date:   Fri, 16 Jun 2023 09:59:08 +0800
From:   Shuai Xue <xueshuai@...ux.alibaba.com>
To:     Yazen Ghannam <yazen.ghannam@....com>, linux-edac@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, tony.luck@...el.com, x86@...nel.org,
        muralidhara.mk@....com, joao.m.martins@...cle.com,
        william.roche@...cle.com, boris.ostrovsky@...cle.com,
        john.allen@....com, baolin.wang@...ux.alibaba.com
Subject: Re: [PATCH 2/3] x86/mce: Define amd_mce_usable_address()



On 2023/6/15 23:15, Yazen Ghannam wrote:
> On 6/14/2023 10:12 PM, Shuai Xue wrote:
>>
>>
>> On 2023/6/14 23:09, Yazen Ghannam wrote:
>>> On 6/13/2023 10:19 PM, Shuai Xue wrote:
>>>>
>>>>
>>>> On 2023/6/13 22:11, Yazen Ghannam wrote:
>>>>> Currently, all valid MCA_ADDR values are assumed to be usable on AMD
>>>>> systems. However, this is not correct in most cases. Notifiers expecting
>>>>> usable addresses may then operate on inappropriate values.
>>>>>
>>>>> Define a helper function to do AMD-specific checks for a usable memory
>>>>> address. List out all known cases.
>>>>>
>>>>> Signed-off-by: Yazen Ghannam <yazen.ghannam@....com>
>>>>> ---
>>>>>    arch/x86/kernel/cpu/mce/amd.c      | 38 ++++++++++++++++++++++++++++++
>>>>>    arch/x86/kernel/cpu/mce/core.c     |  3 +++
>>>>>    arch/x86/kernel/cpu/mce/internal.h |  2 ++
>>>>>    3 files changed, 43 insertions(+)
>>>>>
>>>>> diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
>>>>> index 1ccfb0c9257f..ca79fa10b844 100644
>>>>> --- a/arch/x86/kernel/cpu/mce/amd.c
>>>>> +++ b/arch/x86/kernel/cpu/mce/amd.c
>>>>> @@ -746,6 +746,44 @@ bool amd_mce_is_memory_error(struct mce *m)
>>>>>        return legacy_mce_is_memory_error(m);
>>>>>    }
>>>>>    +/*
>>>>> + * AMD systems do not have an explicit indicator that the value in MCA_ADDR is
>>>>> + * a system physical address. Therefore individual cases need to be detected.
>>>>> + * Future cases and checks will be added as needed.
>>>>> + *
>>>>> + * 1) General case
>>>>> + *    a) Assume address is not usable.
>>>>> + * 2) "Poison" errors
>>>>> + *    a) Indicated by MCA_STATUS[43]: POISON. Defined for all banks except legacy
>>>>> + *       Northbridge (bank 4).
>>>>> + *    b) Refers to poison consumption in the Core. Does not include "no action",
>>>>> + *       "action optional", or "deferred" error severities.
>>>>> + *    c) Will include a usuable address so that immediate action can be taken.
>>>>> + * 3) Northbridge DRAM ECC errors
>>>>> + *    a) Reported in legacy bank 4 with XEC 8.
>>>>> + *    b) MCA_STATUS[43] is *not* defined as POISON in legacy bank 4. Therefore,
>>>>> + *       this bit should not be checked.
>>>> [nit]
>>>>
>>>>> + *
>>>>> + * NOTE: SMCA UMC memory errors fall into case #1.
>>>>
>>>> hi, Yazen
>>>>
>>>> The address for SMCA UMC memory error is not system physical address, it make sense
>>>> to be not usable. But how we deal with the SMCA address? The MCE chain like
>>>> uc_decode_notifier will do a sanity check with mce_usable_address and it will not
>>>> handle SMCA address.
>>>>
>>>
>>> Hi Shuai,
>>>
>>> That's correct.
>>>
>>> There isn't a good solution today. This will be handled in future changes.
>>
>> Hi, Yazen,
>>
>> Do you have plan to address it? If not, I can help. We meet this problem in our products.
>>
> 
> Yes, definitely. The first step is to update the address translation code; this is progress. Afterwards, we can find a way to leverage this in the MCE notifier flows.

Look forward to it.

> 
> Just curious, how big is the benefit of this preemptive page offline in your use cases? That is, compared to page offline as part of poison data consumption.

There are three aspects of benefits if SMCA address detected by scrubber is offlined
in advance:

- Free page: it should be isolated and not allocated by buddy so that the poison data
  will never be consumed.
- In-use page: the heath VMs could be migrated into other heath node if many UCE occurs.
- Mitigate the possibility of nested MCE which is a fatal error.

Thank you.

Best Regards,
Shuai.