linux-kernel - Re: [PATCH 2/2] serial: pl011: Move uart_register

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: <20140219004736.65beeb08@alan.etchedpixels.co.uk>
Date:	Wed, 19 Feb 2014 00:47:36 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Tushar Behera <tushar.behera@...aro.org>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-samsung-soc@...r.kernel.org, jslaby@...e.cz,
	ben.dooks@...ethink.co.uk, broonie@...nel.org
Subject: Re: [PATCH 2/2] serial: pl011: Move uart_register_driver call to
 device probe

> > The race isn't the uart code, it's the driver model.
> > 
> > Consider what happens when this happens:
> > 
> > * Two pl011 devices get registered at the same time by two different
> >   threads.
> 
> How?  What two different busses will see this same device?  The amba bus
> code should prevent that from happening, right?  If not, there's bigger
> problems in that bus code :)
> 
> That's where this problem should be fixed, if there is one, otherwise
> this same issue would be there for any type of driver that calles into
> the uart core, right?

I did some more digging into this the problem goes beyond the uart and
driver model code. Even if you serialize every bus and you serialize
every bus against every other bus (which you can't do btw as we get
recursive probes of one bus from a device probe of another) it's still
racy. We have non bus registering paths for some drivers and those could
be user triggered.

An obvious example is 8250.

If the 8250 driver is loaded on a platform where no device is
autodetected (which is true on a few wackier PC laptops with touchscreens
on an 8250) then you hae a race between say a PCMCIA card insertion of an
8250 and a user who creates the first 8250 device using setserial at the
same moment.

There are similar races between the various directly created devices on
some of the serial ports and bus probed ones where the driver mixes bus
probing with olde worlde straight forward hardcoding.

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