linux-kernel - Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode

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]

Date:   Thu, 24 Feb 2022 00:08:49 +0530
From:   Pratyush Yadav <p.yadav@...com>
To:     <Tudor.Ambarus@...rochip.com>
CC:     <michael@...le.cc>, <broonie@...nel.org>,
        <miquel.raynal@...tlin.com>, <richard@....at>, <vigneshr@...com>,
        <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <Nicolas.Ferre@...rochip.com>,
        <zhengxunli@...c.com.tw>, <jaimeliao@...c.com.tw>
Subject: Re: [PATCH 0/4] spi-mem: Allow specifying the byte order in DTR mode

Hi Tudor,

On 22/02/22 02:43PM, Tudor.Ambarus@...rochip.com wrote:
> On 2/22/22 16:27, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > Am 2022-02-22 15:23, schrieb Tudor.Ambarus@...rochip.com:
> >> On 2/22/22 16:13, Michael Walle wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> >>> the content is safe
> >>>
> >>> Am 2022-02-22 14:54, schrieb Tudor.Ambarus@...rochip.com:
> >>>> On 2/21/22 09:44, Michael Walle wrote:
> >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
> >>>>> know
> >>>>> the content is safe
> >>>>>
> >>>>> Am 2022-02-18 15:58, schrieb Tudor Ambarus:
> >>>>>> Fortunately there are controllers
> >>>>>> that can swap back the bytes at runtime, fixing the endiannesses.
> >>>>>> Provide
> >>>>>> a way for the upper layers to specify the byte order in DTR mode.
> >>>>>
> >>>>> Are there any patches for the atmel-quadspi yet? What happens if
> >>>>
> >>>> not public, but will publish them these days.
> >>>>
> >>>>> the controller doesn't support it? Will there be a software
> >>>>> fallback?
> >>>>
> >>>> no need for a fallback, the controller can ignore
> >>>> op->data.dtr_bswap16
> >>>> if
> >>>> it can't swap bytes.
> >>>
> >>> I don't understand. If the controller doesn't swap the 16bit values,
> >>> you will read the wrong content, no?
> >>>
> >>
> >> In linux no, because macronix swaps bytes on a 2 byte boundary both on
> >> reads and on page program. The problem is when you mix 8D-8D-8D mode
> >> and
> >> 1-1-1 mode along the boot stages. Let's assume you write all boot
> >> binaries
> >> in 1-1-1 mode. When reaching u-boot if you enable 8D-8D-8D mode, when
> >> u-boot
> >> will try to get the kernel it will fail, as the flash swaps the bytes
> >> compared
> >> to what was written with 1-1-1 mode. You write D0 D1 D2 D3 in 1-1-1
> >> mode and
> >> when reaching u-boot you will read D1 D0 D3 D2 and it will mess the
> >> kernel image.
> > 
> > But you have to consider also 3rd parties, like an external programmer
> > or
> 
> Why? If you use the same mode when reading and writing, everything is fine.
> I'm not sure what's your suggestion here.

So our stance here is that we don't care about external programs?

If that is the case then why bother with all this anyway? Since the swap 
happens at both page program and read, what you write is what you read 
back. Who cares the order stored in the actual flash memory as long as 
the data read is correct?

If we do care about external programs, then what would happen if the
external program writes data in 8D-8D-8D mode _without_ swapping the 
bytes? This would also cause data corruption. You can't control what 
they mode they use, and you can't detect it later either.

I think there is no winning here. You just have to say that external 
programs should write in 8D-8D-8D mode or it won't boot.

> 
> > another OS. So, there has to be *one correct* way of writing/reading
> > these
> > bytes.
> > 
> 
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.