linux-kernel - Re: [PATCH v4 8/9] ACPI: APEI: EINJ: Enable EINJv2 error injections

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: <20250313095604.00001ccf@huawei.com>
Date: Thu, 13 Mar 2025 09:56:04 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Zaid Alali <zaidal@...amperecomputing.com>
CC: <rafael@...nel.org>, <lenb@...nel.org>, <james.morse@....com>,
	<tony.luck@...el.com>, <bp@...en8.de>, <robert.moore@...el.com>,
	<dan.j.williams@...el.com>, <Benjamin.Cheatham@....com>,
	<Avadhut.Naik@....com>, <viro@...iv.linux.org.uk>, <arnd@...db.de>,
	<ira.weiny@...el.com>, <dave.jiang@...el.com>,
	<sthanneeru.opensrc@...ron.com>, <linux-acpi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <acpica-devel@...ts.linux.dev>
Subject: Re: [PATCH v4 8/9] ACPI: APEI: EINJ: Enable EINJv2 error injections

On Thu,  6 Mar 2025 15:48:09 -0800
Zaid Alali <zaidal@...amperecomputing.com> wrote:

> Enable the driver to inject EINJv2 type errors. The component
> array values are parsed from user_input and expected to contain
> hex values for component id and syndrome separated by space,
> and multiple components are separated by new line as follows:
> 
> component_id1 component_syndrome1
> component_id2 component_syndrome2
>  :
> component_id(n) component_syndrome(n)
> 
> for example:
> 
> $comp_arr="0x1 0x2
> >0x1 0x4
> >0x2 0x4"  
> $cd /sys/kernel/debug/apei/einj/
> $echo "$comp_arr" > einjv2_component_array
> 
> Signed-off-by: Zaid Alali <zaidal@...amperecomputing.com>
> ---
>  drivers/acpi/apei/einj-core.c | 101 ++++++++++++++++++++++++++++++----
>  1 file changed, 90 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> index 4c748fa0a479..1aea84958b00 100644
> --- a/drivers/acpi/apei/einj-core.c
> +++ b/drivers/acpi/apei/einj-core.c

>  static void einj_exec_ctx_init(struct apei_exec_context *ctx)
>  {
> @@ -288,11 +298,24 @@ static void *einj_get_parameter_address(void)
>  		struct set_error_type_with_address v5param;
>  		void __iomem *p;
>  
> +		v5param_size = sizeof(v5param);
>  		p = acpi_os_map_iomem(pa_v5, sizeof(v5param));
>  		if (p) {
> -			memcpy_fromio(&v5param, p, sizeof(v5param));
> +			int offset, len;
> +
> +			memcpy_fromio(&v5param, p, v5param_size);
>  			acpi5 = 1;
>  			check_vendor_extension(pa_v5, &v5param);
> +			if (available_error_type & ACPI65_EINJV2_SUPP) {
> +				len = v5param.einjv2_struct.length;
> +				offset = offsetof(struct einjv2_extension_struct, component_arr);
> +				nr_components = (len - offset) / 32;

Can we use sizeof() anything for that 32?

> +				acpi_os_unmap_iomem(p, v5param_size);
I wonder if a comment or two would be useful here to explain why we need to expand the mapping.

> +				offset = offsetof(struct set_error_type_with_address, einjv2_struct);
> +				v5param_size = offset + struct_size(&v5param.einjv2_struct,
> +					component_arr, nr_components);
> +				p = acpi_os_map_iomem(pa_v5, v5param_size);
> +			}
>  			return p;
>  		}
>  	}

...


> @@ -945,10 +1023,11 @@ static void __exit einj_remove(struct platform_device *pdev)
>  
>  	if (einj_param) {
>  		acpi_size size = (acpi5) ?
> -			sizeof(struct set_error_type_with_address) :
> +			v5param_size :
>  			sizeof(struct einj_parameter);
>  
>  		acpi_os_unmap_iomem(einj_param, size);
> +
Unrelated change that shouldn't be in this patch.


>  		if (vendor_errors.size)
>  			acpi_os_unmap_memory(vendor_errors.data, vendor_errors.size);
>  	}