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
| ||
|
Date: Sun, 08 May 2022 13:08:33 +0206 From: John Ogness <john.ogness@...utronix.de> To: Neil Armstrong <narmstrong@...libre.com>, Marek Szyprowski <m.szyprowski@...sung.com>, Petr Mladek <pmladek@...e.com> Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-amlogic@...ts.infradead.org Subject: Re: [PATCH printk v5 1/1] printk: extend console_lock for per-console locking Hi Neil, On 2022-05-06, Neil Armstrong <narmstrong@...libre.com> wrote: > Thanks all for figuring out the issue, perhaps other uart drivers > could fall in the same issue if startup code isn't protected with > lock? When preparing for the official patch submission [0], I needed quite a bit of time to understand why another function (meson_uart_reset) should not and cannot acquire the port->lock. I then started investigating some other drivers and indeed I see lots of potential problems. Any console initializing port->lock from the driver's probe() is probably wrong (and there are lots of them). But as I've learned with the meson driver, the details are subtle. Each driver will need to be carefully evaluated to see if it is actually safe. uart_ops->startup() is called without holding port->lock. If the device is a console, it is already registered and printing. driver->probe() is called without holding port->lock. If the device is a console, it is already registered and printing. For both functions, port->lock might not be initialized yet, so blindly acquiring it is wrong. Note that this is not related to the introduction of kthread printing. I've put it on my TODO list to go through the ~76 console drivers to investigate their startup() and probe() implementations. But I will not be able to do this quickly. My time might be better spent writing to all the maintainers asking them to please verify the usage. John Ogness [0] https://lore.kernel.org/lkml/20220508103547.626355-1-john.ogness@linutronix.de
Powered by blists - more mailing lists