linux-kernel - Re: [PATCH] firmware: SDEI: Allow sdei initialization without ACPI_APEI

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] [day] [month] [year] [list]

Message-ID: <b5c04110-c899-4aec-85bf-9978d80bf4ac@quicinc.com>
Date: Tue, 6 May 2025 16:30:51 +0800
From: Huang Yiwei <quic_hyiwei@...cinc.com>
To: Will Deacon <will@...nel.org>
CC: <rafael@...nel.org>, <lenb@...nel.org>, <james.morse@....com>,
        <tony.luck@...el.com>, <bp@...en8.de>, <xueshuai@...ux.alibaba.com>,
        <quic_aiquny@...cinc.com>, <quic_satyap@...cinc.com>,
        <linux-acpi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <kernel@...cinc.com>,
        <kernel@....qualcomm.com>
Subject: Re: [PATCH] firmware: SDEI: Allow sdei initialization without
 ACPI_APEI_GHES

> On Mon, Apr 28, 2025 at 05:56:23PM +0800, Huang Yiwei wrote:
>> SDEI usually initialize with the ACPI table, but on platforms where
>> ACPI is not used, the SDEI feature can still be used to handle
>> specific firmware calls or other customized purposes. Therefore, it
>> ......
>>   	}
>> +
>> +	return ret;
>>   }
>> +#ifndef CONFIG_ACPI_APEI_GHES
>> +subsys_initcall_sync(sdei_init);
>> +#endif
> 
> Using an initcall purely for the non-ACPI case feels like a hack to me.

Yeah, I agree with you actually, but to address the dependency chain 
issue highlighted in commit dc4e8c07e9e2 ("ACPI: APEI: explicit init of 
HEST and GHES in acpi_init()"), where the following relationships need 
to be maintained:

     ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init()
     ghes_init() => sdei_init()

> Could we instead just call sdei_init() from the arch code (and remove
> the call from acpi_ghes_init()) so that the platform device is
> registered at the same time, regardless of the firmware?
> 
> Will

I propose splitting sdei_init() into two separate functions: sdei_init() 
and acpi_sdei_init(). This way, sdei_init() will be called by 
arch_initcall and will only initialize the platform driver, while 
acpi_sdei_init() will initialize the device from acpi_ghes_init() when 
ACPI is ready. This approach should help maintain the dependency chain 
without causing any breaks.

     sdei_init --> platform_driver_register
     arch_initcall(sdei_init)

     acpi_init
         acpi_bus_init();
         acpi_hest_init();
         acpi_ghes_init();
             acpi_sdei_init(); --> platform_device_register_simple
     subsys_initcall(acpi_init);