linux-kernel - Re: [PATCH v3 1/2] mtd: spi-nor: add OTP support

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] [day] [month] [year] [list]

Message-ID: <a6ee55184d91fa1c1802bd82290407bd@walle.cc>
Date:   Mon, 01 Mar 2021 22:31:22 +0100
From:   Michael Walle <michael@...le.cc>
To:     Tudor.Ambarus@...rochip.com
Cc:     linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        miquel.raynal@...tlin.com, richard@....at, vigneshr@...com
Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add OTP support

Am 2021-03-01 18:32, schrieb Michael Walle:
> Am 2021-02-28 13:00, schrieb Tudor.Ambarus@...rochip.com:
>> On 2/16/21 6:28 PM, Michael Walle wrote:
>> Does the otp memory organization matter for the end user?
>> Can't we lock/read/write past region size, for example 2 or 3 regions 
>> in a row,
>> depending on length?
> 
> Mhh tough one. I guess the question really is: Do we want
> to remap the 0x1000, 0x2000, 0x3000 offsets?
>  - 0x1000 -> 0
>  - 0x2000 -> 1 * region_size
>  - 0x3000 -> 2 * region_size
> 
> This is just an example, some devices may us other offsets.
> 
> I'd see this as a prerequsite for handling multiple regions
> in one write, because otherwise you'll have to handle the
> holes which makes it impossible I guess. For example what
> would happen with (given an otp size of 0x100):
>  (1) lock(0, 0x100)
>  (2) lock(0x100, 0xf00)
>  (3) lock(0, 0x1000)
> 
> (1) will work, (2) should return -EINVAL; but what will (3)
> return. -EINVAL too, I guess. But then, ops spanning multiple
> regions doesn't make sense at all, because they will always
> return -EINVAL.
> 
> Unfortunately, I don't know how userspace might access it.
> 
> This is how it looks like at the moment:
> 
> # flash_otp_info -u /dev/mtd1
> Number of OTP user blocks on /dev/mtd1: 3
> block  0:  offset = 0x1000  size = 256 bytes  [unlocked]
> block  1:  offset = 0x2000  size = 256 bytes  [unlocked]
> block  2:  offset = 0x3000  size = 256 bytes  [unlocked]

Hm, I just found the following in the mtd-utils [1]:
"offset and size must match on OTP region boundaries".

[1] 
http://git.infradead.org/mtd-utils.git/blob/HEAD:/misc-utils/flash_otp_lock.c#l25

-michael