linux-kernel - Re: [PATCH v2] mtd: spi-nor: keep lock bits if they are non-volatile

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: <990b9b16-36e5-ce73-36c7-0ebfa391c26b@ti.com>
Date:   Wed, 22 Jan 2020 17:40:15 +0530
From:   Vignesh Raghavendra <vigneshr@...com>
To:     <Tudor.Ambarus@...rochip.com>, <michael@...le.cc>
CC:     <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <richard@....at>, <boris.brezillon@...labora.com>,
        <miquel.raynal@...tlin.com>, <marex@...x.de>
Subject: Re: [PATCH v2] mtd: spi-nor: keep lock bits if they are non-volatile



On 22/01/20 12:23 am, Tudor.Ambarus@...rochip.com wrote:
> Hi, Michael, Vignesh,
> 
> On Sunday, January 12, 2020 12:50:57 AM EET Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
[...]

>>> I see three choices:
>>> 1/ dt prop which gives a per flash granularity. The prop is related to
>>> hw
>>> protection and there might be some chances to get this accepted, maybe
>>> it is
>>> worth to involve Rob. But I tend to share Vignesh's opinion, this would
>>> configure the flash and not describe it.
>>
>> Still my preferred way. but also see below. But I wouldn't say it
> 
> Try to convince Rob.
> 
>> configures the
>> flash but describe that the user want to use the write protection.
>>
>>> 2/ kconfig option, the behavior would be enforced on all the flashes.
>>> It would
>>> be similar to what we have with CONFIG_MTD_SPI_NOR_USE_4K_SECTORS. I
>>> did a
>>> patch to address this some time ago:
>>> https://patchwork.ozlabs.org/patch/
>>> 1133278/
>>
>> Mhh. If we would combine this with this patch that would be at least a
>> step into
>> the right direction. At least a distro could enable that kernel option
>> without
>> breaking old boards/flashes. Because as outlined about you need that for
>> flashes
>> in category (2). Or you'd have to do a flash_unlock every time you want
>> to write
>> to it. But that would be really a backwards incompatible change.. ;)
>>
>>> 3/ module param, the behavior would be enforced on all the flashes.
>>>
>>> Preferences or suggestions?
>>
> I would go with 2/ or 3/. Vignesh, what do you prefer and why?
> 

I dont like option 1, because I am not convinced that this is a HW
description to be put in DT.  IIUC, problem is more of what to do with
locking configuration that is done before Linux comes up(either in
previous boot or by bootloader or POR default). Current code just
discards it and unlocks entire flash.
But proposal is not to touch those bits at probe time and leave this
upto userspace to handle.

Adding a Kconfig does not scale well for multi-platform builds. There
would not be a way to have protection enabled on one platform but
disabled on other. Does not scale for multiple flashes either

Option 3 sounds least bad among all. If module param can be designed to
be a string then, we could control locking behavior to be per flash
using flash name.


-- 
Regards
Vignesh