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]

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

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.

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.

Thanks,
Guenter

--
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/