linux-kernel - Re: [PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes

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: <d2e07f0beda57ffeaa31e8cf5bf28edfbd982e58.camel@linux.ibm.com>
Date:   Mon, 19 Jul 2021 10:46:33 -0500
From:   Eddie James <eajames@...ux.ibm.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     devicetree@...r.kernel.org, openbmc@...ts.ozlabs.org,
        robh+dt@...nel.org, linux-kernel@...r.kernel.org,
        linux-spi@...r.kernel.org
Subject: Re: [PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes

On Mon, 2021-07-19 at 16:20 +0100, Mark Brown wrote:
> On Fri, Jul 16, 2021 at 01:34:38PM -0500, Eddie James wrote:
> 
> > Security changes in the SPI controller - in the device microcode. I
> > can
> > reword the commit if you like.
> 
> How will people end up running this device microcode?  Is this a bug
> fix, or is this going to needlessly reduce performance for people
> with
> existing hardware?

The hardware is still in development. As part of the development, the
device microcode was changed to restrict transfers. The reason for this
restriction was "security concerns". This restriction disallows the
loop (or branch-if-not-equal-and-increment) sequencer command. It also
does not allow the read (or shift in if you prefer) command to specify
the number of bytes in the command itself. Rather, the number of bits
to shift in must be specified in a separate control register. This
effectively means that the controller cannot transfer more than 8 bytes
at a time.
Therefore I suppose this is effectively a bug fix. There will be no 
hardware available without these restrictions, so it is not a needless
reduction in performance. Every system that can run this driver will
run the more restrictive device microcode.

Thanks,
Eddie