linux-kernel - Re: [PATCH] serial: don't announce CIR serial ports

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:	Tue, 04 Aug 2015 22:03:00 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
CC:	linux-serial@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] serial: don't announce CIR serial ports

On 08/04/2015 07:25 PM, Maciej S. Szmigiero wrote:
> Hi Peter,
> 
> Thanks for looking into it.
> 
> On 04.08.2015 03:46, Peter Hurley wrote:
>> Hi Maciej,
>>
>> On 08/02/2015 05:09 PM, Maciej S. Szmigiero wrote:
>>> CIR type serial ports aren't real serial ports.
>>> This is just a way to prevent legacy serial driver
>>> from probing and eventually binding some resources
>>> so don't announce them like normal serial ports.
>>
>> I'd like to keep some form of reporting so that we know the
>> port was properly probed; what about extending uart_report_port()
>> to including CIR + disabled status?
> 
> Currently the printed message looks like this:
> "00:01: ttyS2 at I/O 0x3e8 (irq = 7, base_baud = 115200) is a CIR port".
> 
> I think it would be best to skip a device file name in this case,
> since this is how user sees (and uses) a real serial port.
> The message would be then:
> "00:01 at I/O 0x3e8 (irq = 7, base_baud = 115200) is a CIR port".
> 
> The dev name will always be present since the only current
> "source" of CIR ports is PNP 8250 driver which sets 
> dev pointer uncondtionally.
> 
>> Secondly, good catch! Because we should not be trying to
>> register a console on this port, nor driving modem signals.
>>
>> So maybe an early exit after uart_report_port?
> 
> All right, I will resubmit updated patch tomorrow.

In re-reviewing this, I think the proper solution is actually not
to add the uart port for a CIR port at all. It doesn't make
sense because the tty cannot be changed by setserial/ioctl(TIOCSSERIAL),
so the device node serves no purpose.

This problem is really an artifact of the 8250 driver port management,
and shouldn't involve the serial core at all.

An additional benefit of this approach is that a simple one-line
banner noting the port skip could be emitted instead from
serial8250_register_8250_port().

Regards,
Peter Hurley

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