linux-kernel - How to handle write-protect pin of NAND device ?

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

Message-ID: <CAK7LNAR0FemABUg5uN5fhy5LRsOm7n5GhmFVVHE8T57knDM9Ug@mail.gmail.com>
Date:   Mon, 27 Jan 2020 21:55:25 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     linux-mtd <linux-mtd@...ts.infradead.org>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: How to handle write-protect pin of NAND device ?

Hi.

I have a question about the
WP_n pin of a NAND chip.

As far as I see, the NAND framework does not
handle it.

Instead, it is handled in a driver level.
I see some DT-bindings that handle the WP_n pin.

$ git grep wp -- Documentation/devicetree/bindings/mtd/
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt:-
brcm,nand-has-wp          : Some versions of this IP include a
write-protect
Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt:-
wp-gpios: GPIO specifier for the write protect pin.
Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt:
         wp-gpios = <&gpf 22 GPIO_ACTIVE_LOW>;
Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt:-
wp-gpios: GPIO specifier for the write protect pin.
Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt:
         wp-gpios = <&gpio TEGRA_GPIO(S, 0) GPIO_ACTIVE_LOW>;

I wrote a patch to avoid read-only issue in some cases:
http://patchwork.ozlabs.org/patch/1229749/

Generally speaking, we expect NAND devices
are writable in Linux. So, I think my patch is OK.

However, I asked this myself:
Is there a useful case to assert the write protect
pin in order to make the NAND chip really read-only?
For example, the system recovery image is stored in
a read-only device, and the write-protect pin is
kept asserted to assure nobody accidentally corrupts it.

But, I am not sure if it should be handled in the
framework level with a more generic DT-binding.

Comments are appreciated.

--
Best Regards
Masahiro Yamada