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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 20 Jul 2021 13:04:38 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Eddie James' <>,
        Mark Brown <>
CC:     "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>
Subject: RE: [PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes

From: Eddie James <>
> Sent: 19 July 2021 16:47
> To: Mark Brown <>
> Cc:;;; linux-
> 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.

So just say that release versions of the hardware won't support
more than 8 byte transfers.

Having said that, you might want a loop in the driver so that
application requests for longer transfers are implemented
with multiple hardware requests.

I do also wonder why there is support in the main kernel sources
for hardware that doesn't actually exist.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists