linux-kernel - Re: [PATCH net-next v7 3/7] arch: x86: add IPC mailbox accessor function and add SoC register access

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: <0307750b-dd98-4718-8c3c-928df6a80ef5@linux.intel.com>
Date: Thu, 20 Feb 2025 10:29:31 +0800
From: Choong Yong Liang <yong.liang.choong@...ux.intel.com>
To: david.e.box@...ux.intel.com, Dave Hansen <dave.hansen@...el.com>,
 Simon Horman <horms@...nel.org>, Jose Abreu <joabreu@...opsys.com>,
 Jose Abreu <Jose.Abreu@...opsys.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, "H . Peter Anvin"
 <hpa@...or.com>, Rajneesh Bhardwaj <irenic.rajneesh@...il.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Jiawen Wu <jiawenwu@...stnetic.com>, Mengyuan Lou
 <mengyuanlou@...-swift.com>, Heiner Kallweit <hkallweit1@...il.com>,
 Russell King <linux@...linux.org.uk>, Hans de Goede <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Richard Cochran <richardcochran@...il.com>,
 Serge Semin <fancer.lancer@...il.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 platform-driver-x86@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next v7 3/7] arch: x86: add IPC mailbox accessor
 function and add SoC register access

On 20/2/2025 1:01 am, David E. Box wrote:
> On Thu, 2025-02-06 at 08:46 -0800, Dave Hansen wrote:
>> On 2/6/25 05:18, Choong Yong Liang wrote:
>>>
>>> - Exports intel_pmc_ipc() for host access to the PMC IPC mailbox
>>> - Add support to use IPC command allows host to access SoC registers
>>> through PMC firmware that are otherwise inaccessible to the host due
>>> to security policies.
>> I'm not quite parsing that second bullet as a complete sentence.
>>
>> But that sounds scary! Why is the fact that they are "otherwise
>> inaccessible" relevant here?
> 
> The PMC IPC mailbox is a host interface to the PMC. Its purpose is to allow the
> host to access certain areas of the PMC that are restricted from direct MMIO
> access due to security policies. Other parts of the PMC are accessible via MMIO
> (most of what the intel_pmc_core driver touches with is MMIO), so I think the
> original statement was trying to explain why the mailbox is needed instead of
> MMIO in this case. However, I agree that the mention of security policies is not
> relevant to the change itself.
> 
>> ...
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index 87198d957e2f..631c1f10776c 100644
>>> --- a/arch/x86/Kconfig
>>> +++ b/arch/x86/Kconfig
>>> @@ -688,6 +688,15 @@ config X86_AMD_PLATFORM_DEVICE
>>>   	  I2C and UART depend on COMMON_CLK to set clock. GPIO driver is
>>>   	  implemented under PINCTRL subsystem.
>>>   
>>> +config INTEL_PMC_IPC
>>> +	tristate "Intel Core SoC Power Management Controller IPC mailbox"
>>> +	depends on ACPI
>>> +	help
>>> +	  This option enables sideband register access support for Intel
>>> SoC
>>> +	  power management controller IPC mailbox.
>>> +
>>> +	  If you don't require the option or are in doubt, say N.
>>
>> Could we perhaps beef this up a bit to help users figure out if they
>> want to turn this on? Really the only word in the entire help text
>> that's useful is "Intel".
>>
>> I'm not even sure we *want* to expose this to users. Can we just leave
>> it as:
>>
>> 	config INTEL_PMC_IPC
>> 		def_tristate n
>> 		depends on ACPI
>>
>> so that it only gets enabled by the "select" in the other patches?
> 
> I agree with this change Choong. This can be selected by the driver that's using
> it. There's no need to expose it to users.
> 
>>
>>> + * Authors: Choong Yong Liang <yong.liang.choong@...ux.intel.com>
>>> + *          David E. Box <david.e.box@...ux.intel.com>
>>
>> I'd probably just leave the authors bit out. It might have been useful
>> in the 90's, but that's what git is for today.
>>
>>> +	obj = buffer.pointer;
>>> +	/* Check if the number of elements in package is 5 */
>>> +	if (obj && obj->type == ACPI_TYPE_PACKAGE && obj->package.count ==
>>> 5) {
>>> +		const union acpi_object *objs = obj->package.elements;
>>> +
>>
>> The comment there is just not super useful. It might be useful to say
>> *why* the number of elements needs to be 5.
>>
>>> +EXPORT_SYMBOL(intel_pmc_ipc);
>>> +
>>> +MODULE_LICENSE("GPL");
>>> +MODULE_DESCRIPTION("Intel PMC IPC Mailbox accessor");
>>
>> Honestly, is this even worth being a module? How much code are we
>> talking about here?
> 
> Yeah, this doesn't need to be a module either.
> 
> David
> 

Hi David,

Thank you for the confirmation.
Let's work together to address the comments.