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  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:   Thu, 23 Jun 2022 22:17:06 +0200
From:   Lino Sanfilippo <LinoSanfilippo@....de>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     gregkh@...uxfoundation.org, jirislaby@...nel.org,
        ilpo.jarvinen@...ux.intel.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, vz@...ia.com,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        lukas@...ner.de, p.rosenberger@...bus.com,
        Lino Sanfilippo <l.sanfilippo@...bus.com>
Subject: Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

On 23.06.22 at 18:29, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@...bus.com>
>>
>> The maximum allowed delay for RTS before and RTS after send is 100 ms.
>> Adjust the documentation accordingly.
>
>
> Is it only documentation issue? If the code allows this to be set higher
> than 100, we may not change the documentation since this an ABI (from
> firmware <--> kernel perspective) we need to support old variants.
>

Well currently the documentation claims that a maximum of 1000 msecs is allowed but
nothing actually checks the values read from device tree/ACPI and so it is possible
to set much higher values (note that the UART drivers dont check the delays read from
DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).

We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.

I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
the sanity checks for TIOCSRS485 were introduced
(see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
since before we did not have those limits for all drivers (some drivers clamped the
values itself but many did not care).
Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
in usecs range). So IMHO the risk is very low to break anything when values are clamped
that are higher than that.


Regards,
Lino



Powered by blists - more mailing lists