On 29 September 2024 11:23:12 UTC, Zhihao Cheng <chengzhihao1@xxxxxxxxxx> wrote: >在 2024/9/29 18:52, Daniel Golle 写道: >> On Sun, Sep 29, 2024 at 12:03:11PM +0800, Zhihao Cheng wrote: >>> 在 2024/9/28 22:38, Daniel Golle 写道: >>>> On Sat, Sep 28, 2024 at 03:45:49PM +0200, Krzysztof Kozlowski wrote: >>>> [...] >>>> The case I want to cover here is the bootloader itself being stored >>>> inside a UBI volume. MediaTek's fork of ARM TrustedFirmware-A bl2 comes >>>> with support for UBI and loads BL3 (which is TF-A BL31 and U-Boot, and >>>> maybe OP-TEE as well) from a static UBI volume. Removing, renaming or >>>> altering that volume results in the device not being able to boot any >>>> more and requiring a complicated intervention (at attaching debugging >>>> UART and using low-level recovery tool) in order to recover. >>> >>> Who removes/renames the 'critical' volume? I suggest to fix it in the upper >>> layer(not in kernel). After looking through the patch 2, it seems a hack >>> solution. >> >> The enemy is the user, the upper layer is between the keyboard and the >> screen. Just like for 'read-only' MTD partitions I'm looking >> for a similar solution for UBI which prevents the user from accidentally >> deleting or destroying the bootloader, lets say, when logged in via SSH. >> . >> > >I guess that other partitions(excepts mtd) have the similar situations, users could delete a rootfs(ext4) partition by operation the raw block device. The kernel has no way to stop user doing this, what if the user just want to rebuild partions? True, but as you correctly pointed out the worst-case scenario would be Linux no longer booting. You would fix that by using a bootable USB pendrive. However, the user wont easily manage to delete the bootloader or BIOS by accident, such as a simple typo of the partition number or accidentally destroying GPT. If the storage of low-level boot firmware is accissible from within Linux then there are always additional safeguards, such as the write-protection of mmcblkXbootY hw-partition, or MTD partitons holding bootloader components being marked as read-only. >Marking volume as critical(by a stopper in kernel) could prevent user mistakenly operating, but I think it is more important that user need to know what he/she is doing. I agree that education of users is crucial, yet I think the risk of needing complicated hardware interventions (direct access to NAND flash chip, attaching JTAG, ...) which are required in order to recover from a mistake should also be taken into account.
