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]
Message-ID: <87y13ehn6y.fsf@geanix.com>
Date: Thu, 26 Sep 2024 09:46:29 +0200
From: Esben Haabendal <esben@...nix.com>
To: Erez <erezgeva2@...il.com>
Cc: Michael Walle <mwalle@...nel.org>,  Tudor Ambarus
 <tudor.ambarus@...aro.org>,  Erez Geva <erezgeva@...ime.org>,
  linux-mtd@...ts.infradead.org,  Pratyush Yadav <pratyush@...nel.org>,
  linux-kernel@...r.kernel.org,  Miquel Raynal <miquel.raynal@...tlin.com>,
  Richard Weinberger <richard@....at>,  Vignesh Raghavendra
 <vigneshr@...com>,  devicetree@...r.kernel.org,  Rob Herring
 <robh@...nel.org>,  Krzysztof Kozlowski <krzk+dt@...nel.org>,  Conor
 Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH v5 1/5] mtd: spi-nor: core: add manufacturer flags

Erez <erezgeva2@...il.com> writes:

> On Mon, 23 Sept 2024 at 18:19, Michael Walle <mwalle@...nel.org> wrote:
>>
>> > > > I would gladly remove the obsolete mx25l12805d.
>> > > Why? I don't see any need for that.
>> > Maybe because we do not want compatibility table?
>>
>> I don't get this? Anyway, we do not remove support for older
>> flashes for no reason.
>
> I did not insist, you asked.
> Macronix stopped selling these chips 15 year ago.
> How long do you want to support old chips?

It is not unusual for embedded products to have a support span of more
than 20 years. And chips such as these flashes might not be entirely new
when the product is introduced. So dropping support for SPI-NOR flashes
that are newer than 25-30 years is definitely a risk. Somebody out there
might not be able to upgrade to latest kernel versions anymore, which is
not a position we should put anyone in. With the increasing pressure to
upgrade product for better security, we definitely should not make it
more difficult to run newer kernel versions than absolutely necessary.

/Esben

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ