linux-kernel - RE: [PATCH v2] ACPI: APEI: EINJ: EINJV2 support added

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: <SJ1PR11MB608333C6628FE2FDBEB64C19FC489@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date:   Wed, 31 May 2023 16:23:23 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Piyush Malgujar <pmalgujar@...vell.com>,
        "Wilczynski, Michal" <michal.wilczynski@...el.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "xueshuai@...ux.alibaba.com" <xueshuai@...ux.alibaba.com>,
        "benjamin.cheatham@....com" <benjamin.cheatham@....com>,
        "bp@...en8.de" <bp@...en8.de>,
        "james.morse@....com" <james.morse@....com>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "jannadurai@...vell.com" <jannadurai@...vell.com>,
        "cchavva@...vell.com" <cchavva@...vell.com>
Subject: RE: [PATCH v2] ACPI: APEI: EINJ: EINJV2 support added

> I get that we have to support v1 and v2 for backward compatibility, but for the point no.2
> made by Tony - 
> "2) Incremental systems that have both V1 and V2 interfaces.",
> just wanted to understand if we expect any use case where if EINJ V2 is supported, both v1
> and v2 interfaces shall be required at the same time for error injection, as from the spec,
> if V2 is supported, EINJV2_SET_ERROR_TYPE takes precedence.
>
> This seems to be similar with V1 action types - whether to go with SET_ERROR_TYPE_WITH_ADDRESS or
> SET_ERROR_TYPE, is based on the action entry in the EINJ table where "SET_ERROR_TYPE_WITH_ADDRESS"
> gets precedence.

I don't think it will be required to support users mix and matching v1 and v2 in the middle of an injection.
So will need some locking between the einj/error_inject and the einjv2/error_inject action phase.

I'd still like to see the einjv2 injection supply all parameters in a single write to a debugfs file
and have the driver parse the values.

E.g.

# echo "corrected memory 0x1234567890 notrigger" > /sys/kernel/debug/apei/einjv2/error_inject

That would make injection a user-level atomic operation, and avoid all the confusion that results
from updating the param1, param2, ... files individually.

-Tony