linux-kernel - Re: [PATCH] spi: Check conflicting CS based on spi->chip

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: <20140109160505.GC2494@intel.com>
Date:	Thu, 9 Jan 2014 18:05:05 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Cc:	linux-spi@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spi: Check conflicting CS based on spi->chip_select
 instead of device name

On Thu, Jan 09, 2014 at 03:59:38PM +0200, Jarkko Nikula wrote:
> On 01/09/2014 03:23 PM, Mika Westerberg wrote:
> >Commit e13ac47bec20 (spi: Use stable dev_name for ACPI enumerated SPI
> >slaves) changed the SPI device naming to be based on ACPI device name
> >instead of carrying bus number and chip select for devices enumerated
> >from ACPI namespace.
> >
> >In case of a buggy BIOS that lists multiple SPI devices sharing the same
> >chip select (even though they should use different) the current code fails
> >to detect that and allows the devices to be added to the bus.
> >
> >Fix this by walking through the bus and comparing spi->chip_select instead
> >of device name. This should work regardless what the device name will be in
> >future.
> >
> >Cc: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
> >Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> >---
> >  drivers/spi/spi.c | 18 +++++++++++++-----
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >
> >diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> >index 349ebba4b199..13dcc360bde6 100644
> >--- a/drivers/spi/spi.c
> >+++ b/drivers/spi/spi.c
> >
> I guess this is a valid fix in that sense that before my patch those
> ill-defined SPI devices were not added. Is this something which
> should go to 3.13?

This is pretty rare case so I wouldn't expect any current HSW machines for
example to have such bugs. I'm not even sure if the SPI bus on LPSS is used
anywhere outside Intel currently.

However, we happen to have few development machines here where this bug
exists.

Up to Mark to decide whether this is urgent enough to be included in 3.13.

> Acked-by: Jarkko Nikula <jarkko.nikula@...ux.intel.com>

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