linux-kernel - Re: [PATCH v2 1/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips

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: <CALCETrXvBxcZCyupHM6trb2Gv99MH9-HVG7ZuNGE2OPMZ7d7hA@mail.gmail.com>
Date:	Tue, 17 Mar 2015 13:14:43 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Boaz Harrosh <boaz@...xistor.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Rui Wang <ruiv.wang@...il.com>,
	Jean Delvare <jdelvare@...e.de>,
	Alun Evans <alun@...gerous.net>,
	Robert Elliott <Elliott@...com>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Paul Bolle <pebolle@...cali.nl>,
	Tony Luck <tony.luck@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] i2c_imc: New driver for Intel's iMC, found on
 LGA2011 chips

On Mar 13, 2015 9:15 PM, "Guenter Roeck" <linux@...ck-us.net> wrote:
>
> On 03/09/2015 01:55 PM, Andy Lutomirski wrote:
>>
>> Sandy Bridge Xeon and Extreme chips have integrated memory
>> controllers with (rather limited) onboard SMBUS masters.  This
>> driver gives access to the bus.
>>
>> There are various groups working on standardizing a way to arbitrate
>> access to the bus between the OS, SMM firmware, a BMC, hardware
>> thermal control, etc.  In the mean time, running this driver is
>> unsafe except under special circumstances.  Nonetheless, this driver
>> has real users.
>>
>> As a compromise, the driver will refuse to load unless
>> i2c_imc.allow_unsafe_access=Y.  When safe access becomes available,
>> we can leave this option as a way for legacy users to run the
>> driver, and we'll allow the driver to load by default if safe bus
>> access is available.
>>
>> Signed-off-by: Andy Lutomirski <luto@...capital.net>
>> ---
>>   drivers/i2c/busses/Kconfig   |  17 ++
>>   drivers/i2c/busses/Makefile  |   1 +
>>   drivers/i2c/busses/i2c-imc.c | 567 +++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 585 insertions(+)
>>   create mode 100644 drivers/i2c/busses/i2c-imc.c
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index ab838d9e28b6..50e3d79122dd 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -149,6 +149,23 @@ config I2C_ISMT
>>           This driver can also be built as a module.  If so, the module will be
>>           called i2c-ismt.
>>
>> +config I2C_IMC
>> +       tristate "Intel iMC (LGA 2011) SMBus Controller"
>> +       depends on PCI && X86
>> +       help
>> +         If you say yes to this option, support will be included for the Intel
>> +         Integrated Memory Controller SMBus host controller interface.  This
>> +         controller is found on LGA 2011 Xeons and Core i7 Extremes.
>> +
>> +         There are currently no systems on which the kernel knows that it can
>> +         safely enable this driver.  For now, you need to pass this driver a
>> +         scary module parameter, and you should only pass that parameter if you
>> +         have a special motherboard and know exactly what you are doing.
>> +         Special motherboards include the Supermicro X9DRH-iF-NV.
>> +
>
> I think the current approach of issuing warnings here and in the driver on load
> is the wrong one. For the most part, users will just run with distributions.
> If a distribution enables the driver, it will end up being used, warning or not.
>
> A much better approach, in my opinion, would be to only enable the driver for
> systems where it is known (or presumed) to be good, such as the Supermicro board
> mentioned above. This can be done with DMI data.
>
> For other boards, a 'force' module parameter can be added. This would ensure
> that the user _has_ to do something manually to load the driver. The warning
> on load would then only be displayed if the force module parameter is set.
>

This driver already has that: that's what "allow_unsafe_access" does.

I wouldn't be opposed to adding a DMI whitelist, although I really
don't want DMI entries to proliferate.

> Having said that, I am still not convinced that the driver should be in the kernel
> to start with. Browsing through Intel's datasheets, the registers are supported
> in E5-2600 v1, v2, and v3. However, in v3 Intel added a note saying that the registers
> should not be accessed by the OS directly, but only through the bios. Given that,
> and if that is possible, it might make more sense to rely on ACPI. It would then
> be up to the board and/or BIOS vendor to decide if the information should be available
> to the OS or not.

I think the plan is to add something to ACPI to tell us when we can
use these registers.  Unfortunately I'm not privy to whatever the ACPI
committee is doing.


--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/