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]
Date:   Thu, 18 Feb 2021 11:49:42 +0100
From:   Maarten Brock <m.brock@...mierlo.com>
To:     Måns Rullgård <mans@...sr.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] serial: 8250: add option to disable registration of
 legacy ISA ports

On 2021-01-31 14:18, Måns Rullgård wrote:
>> What userspace visable change will be caused by this?
> 
> There won't be /dev/ttyS devices for ports that don't exist.

Oh yes, please!

That would mean I can create ttyS2 and upward while keeping ttyPS0 and 
ttyPS1 (which invaded the serial<N> alias namespace) at the lower 
numbers.

>> Will ports get renumbered?
> 
> Not if they had predictable numbers to begin with.

It is hard to make predictable numbers with the backward operating 
serial<N> aliases in the device tree. It makes relations in the wrong 
direction.

If a system has two ttyPS<N> uarts (xilinx_uartps) and needs them at 
ttyPS0 and ttyPS1 (or at least <=ttyPS9, due to another bug in 
start_getty) and 10 ttyS<N> (8250) you can configure the kernel for 10 
8250 devices and give 8 of them the predictable ttyS2 to ttyS9. The last 
two will get the remaining ttyS0 and ttyS1. You cannot assign them their 
number, because the serial0 and serial1 alias are required for the 
ttyPS0 and ttyPS1.

However with this option it would be possible to configure for 12 8250 
devices and not use nor see ttyS0 and ttyS1.

The best option would of course be to not even instantiate kernel 
drivers for non-existing devices.

Maarten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ