linux-kernel - RE: [PATCH v6 1/4] ACPI: APEI: EINJ: Refactor available_error_type

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: <SJ1PR11MB6083540990D4929381FD3358FCB0A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date:   Thu, 16 Nov 2023 22:55:44 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Avadhut Naik <avadhut.naik@....com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
CC:     "rafael@...nel.org" <rafael@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "james.morse@....com" <james.morse@....com>,
        "bp@...en8.de" <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexey.kardashevskiy@....com" <alexey.kardashevskiy@....com>,
        "yazen.ghannam@....com" <yazen.ghannam@....com>,
        "avadnaik@....com" <avadnaik@....com>
Subject: RE: [PATCH v6 1/4] ACPI: APEI: EINJ: Refactor
 available_error_type_show()

> From: Avadhut Naik <Avadhut.Naik@....com>
>
> OSPM can discover the error injection capabilities of the platform by
> executing GET_ERROR_TYPE error injection action.[1] The action returns
> a DWORD representing a bitmap of platform supported error injections.[2]
>
> The available_error_type_show() function determines the bits set within
> this DWORD and provides a verbose output, from einj_error_type_string
> array, through /sys/kernel/debug/apei/einj/available_error_type file.
>
> The function however, assumes one to one correspondence between an error's
> position in the bitmap and its array entry offset. Consequently, some
> errors like Vendor Defined Error Type fail this assumption and will
> incorrectly be shown as not supported, even if their corresponding bit is
> set in the bitmap and they have an entry in the array.
>
> Navigate around the issue by converting einj_error_type_string into an
> array of structures with a predetermined mask for all error types
> corresponding to their bit position in the DWORD returned by GET_ERROR_TYPE
> action. The same breaks the aforementioned assumption resulting in all
> supported error types by a platform being outputted through the above
> available_error_type file.
>
> [1] ACPI specification 6.5, Table 18.25
> [2] ACPI specification 6.5, Table 18.30
>
> Suggested-by: Alexey Kardashevskiy <alexey.kardashevskiy@....com>
> Signed-off-by: Avadhut Naik <Avadhut.Naik@....com>
> Reviewed-by: Borislav Petkov (AMD) <bp@...en8.de>

Reviewed-by: Tony Luck <tony.luck@...el.com>