linux-kernel - Re: [RFC 0/1] serdes: Add whitelist to bring back missing serial port

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: <87woawpxpt.fsf@kokedama.swc.toshiba.co.jp>
Date:   Mon, 16 Dec 2019 15:54:06 +0900
From:   Punit Agrawal <punit1.agrawal@...hiba.co.jp>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     linux-serial@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org, nobuhiro1.iwamatsu@...hiba.co.jp,
        shrirang.bagul@...onical.com, robh@...nel.org,
        gregkh@...uxfoundation.org, johan@...nel.org
Subject: Re: [RFC 0/1] serdes: Add whitelist to bring back missing serial port

Hi Hans,

Thanks for chiming in.

Hans de Goede <hdegoede@...hat.com> writes:

> HI,
>
> On 16-12-2019 05:08, Punit Agrawal wrote:
>>
>> Hi,
>>
>> While booting v5.5-rc1 on Apollo Lake based UP2[0], I ran into an
>> issue with the primary serial port. The kernel is able to output to
>> ttyS0 but systemd isn't able to raise a login prompt. On further
>> investigation, it turns out that no serial device (/dev/ttyS0) is
>> being created as the device is claimed by serdev sub-system.
>>
>> The issue has been reported in a few different places[0][1]. A patch
>> was proposed to solve the issue but there doesn't seem to be any
>> further progress[2]. Feedback on the thread suggested implementing a
>> whitelist based approach - which is what this RFC does.
>>
>> With this patch, systemd is able to create a login prompt. The
>> whitelist has intentionally been left blank as it's not clear which
>> devices go in there.
>
> As I already mentioned when discussing this upstream:
>
> https://marc.info/?l=linux-serial&m=152460460418058&w=2
>
> I am afraid that a whitelist is not going to fly, that means
> duplicating all the device-ids in all the relevant drivers and that
> everytime we add a device-id we need to do so in 2 places. Just take
> a look at drivers/bluetooth/hci_bcm.c at the device-id list starting
> at line 1187 and that is just 1 driver.

I had seen the linked mail but was missing the context given here. I am
not that familiar with the serial devices framework.

>
> I also mention a hack for RTL8723BS devices there, but those have
> gotten a proper in kernel driver in the mean time.
>
> Looking at the ACPI device id list in the proposed upstream fix
> with a "hsuart serdev driver":
> https://www.spinics.net/lists/linux-serial/msg30035.html
>
> +static const struct acpi_device_id hsuart_acpi_match[] = {
> +	{"INT3511", 0},
> +	{"INT3512", 0},
> +	{ },
> +};
>
> Then blacklist with just these 2 ids would clearly be a much better
> approach, as we are talking 2 ids vs 50+ ids here for whitelist vs
> blacklist.
>
> The whitepaper on this:
> https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/enabling-multi-com-port-white-paper.pdf
> Also mentions these 2 as "the default Hardware IDs (INT3511 and INT3512) used here are Intel HS-UART COM
> port peripheral device IDs." as the hardware ids to use if the port has no
> specific function, in other words to use these 2 ids when under Linux the
> serial-port should just show up as a /dev/ttyS* device.
>
> So I believe that the fix here is using a blacklist with just these 2
> ids in there.

That makes sense.

A shorter list of exceptions is better than the longer list of supported
device list that is going to be duplicated.

I will respin the patches taking the blacklist approach if there is no
other feedback.

Thanks,
Punit