drivers/efuse/efuse: Multiple Drivers Are Registered With World Writable

[catalinv-ncc]

drivers/: Multiple Drivers Are Registered With World Writable

Summary

Permissions (Part 1)

Description:

In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.

DISCLAIMER: I tried to be strict with the settings, better to relax them later if it's needed.

This is part of #19410

Impact

See #19410

Testing

Compiles ok.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

@catalinv-ncc please fix:

../nuttx/tools/checkpatch.sh -c -u -m -g  618119edb74520b5bf8aa456ea13760fda8a721c..HEAD
❌ Commit subject must be followed by a blank line

[linguini1]

This is a good find, but I think we need to at least test a few of these boards to make sure this doesn't break anything. Some of these changes are present on QEMU and sim, do you think you could test those targets?

[catalinv-ncc]

This is a good find, but I think we need to at least test a few of these boards to make sure this doesn't break anything. Some of these changes are present on QEMU and sim, do you think you could test those targets?

Please list 3-4 of the best (most comprehensive) targets you think I should try, and I will. That being said, there is no reason these should be world writable.

[linguini1]

Please list 3-4 of the best (most comprehensive) targets you think I should try, and I will. That being said, there is no reason these should be world writable.

I agree, this is mostly to identify issues so we could maybe even fix them to be compatible with the stricter permissions. I think the updated permissions are better!

I don't know what you have available to you, but I would say any of the STM32 targets maybe since they have a lot of the peripheral drivers that were modified. If you can run the example programs for the peripherals and they work then that would be sufficient to say nothing broke I would think. I.e. I2C utility, etc.

If not, testing the drivers you modified on QEMU would be easiest since it's all virtual. The simulator should also have some of these drivers.