Service firmware partitions is available to user, even from file manager

[RussianNeuroMancer]

Hello!

~$ lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 113,6G  0 disk 
├─sda1    8:1    0   260M  0 part 
├─sda2    8:2    0   128M  0 part 
├─sda3    8:3    0   4,9G  0 part 
├─sda4    8:4    0 107,4G  0 part 
└─sda5    8:5    0   950M  0 part 
sdb       8:16   0     4M  0 disk 
├─sdb1    8:17   0   3,5M  0 part 
└─sdb2    8:18   0   128K  0 part 
sdc       8:32   0     4M  0 disk 
├─sdc1    8:33   0   3,5M  0 part 
└─sdc2    8:34   0   128K  0 part 
sdd       8:48   0   128M  0 disk 
├─sdd2    8:50   0   128K  0 part 
└─sdd3    8:51   0     1M  0 part 
sde       8:64   0     4G  0 disk 
├─sde1    8:65   0     8M  0 part 
├─sde2    8:66   0     8M  0 part 
├─sde3    8:67   0   128K  0 part 
├─sde4    8:68   0     1M  0 part 
├─sde5    8:69   0   256K  0 part 
├─sde6    8:70   0   256K  0 part 
├─sde7    8:71   0    16M  0 part 
├─sde8    8:72   0     8K  0 part 
├─sde9    8:73   0   256K  0 part 
├─sde10   8:74   0    16K  0 part 
├─sde11   8:75   0   512K  0 part 
├─sde12   8:76   0     2M  0 part 
├─sde13   8:77   0   128K  0 part 
├─sde14   8:78   0   512K  0 part 
├─sde15   8:79   0    16M  0 part 
├─sde16 259:0    0     5M  0 part 
├─sde17 259:1    0    64K  0 part 
├─sde18 259:2    0     4K  0 part 
├─sde19 259:3    0     2M  0 part 
├─sde20 259:4    0   512K  0 part 
├─sde21 259:5    0     2M  0 part 
├─sde22 259:6    0   128K  0 part 
├─sde23 259:7    0   512K  0 part 
├─sde24 259:8    0    16M  0 part 
├─sde25 259:9    0     5M  0 part 
├─sde26 259:10   0    64K  0 part 
└─sde27 259:11   0     2M  0 part 
sdf       8:80   0   1,5G  0 disk 
├─sdf2    8:82   0     2M  0 part 
├─sdf3    8:83   0     2M  0 part 
├─sdf4    8:84   0     2M  0 part 
└─sdf5    8:85   0   128K  0 part 
sdh       8:112  1  59,6G  0 disk 
├─sdh1    8:113  1   512M  0 part /boot/efi
└─sdh2    8:114  1  59,1G  0 part /

(Ignore sdh, it's microSD I use to boot system.)

As you can see on screenshot below some partitions from list above is even available for mounting in Nautilus:

I'm afraid editing files on these devices (besides sda) or wrong device in dd command could cause grave consequences for motherboard. I don't know if my fear is justified, but if it's possible to brick motherboard, LTE modem or any other component by editing or removing files (intentionally or by accident) on these partitions, or by removing partitions itself, I think kernel driver should hide all block devices from UFS besides sda on these laptops, at least by default. To put this issue in perspective (again, only if my understanding of partitions content is correct, and only if it's possible to brick board/component this way) I have to note that it's impossible to repair for example Lenovo Yoga C630 WOS in countries where Lenovo doesn't sell it, even for money.

[lag-linaro]

Right. The user needs to be very careful about deleting unknown files/partitions.

However, this is not something we plan on changing ourselves.

Leaving this open to create some awareness, but AFAIC it's not a bug.

[RussianNeuroMancer]

Look at this from this point of view: by leaving hardware internals open for damage from userspace, driver create security vulnerability that allow to brick hardware, like Chernobyl did ("highly destructive to vulnerable systems, overwriting critical information on infected system drives, and in some cases destroying the system BIOS").

Also please pay attention to the fact that mounting partitions from screenshot doesn't even require root privileges and bricking motherboard or it's component can be done even without privileges escalation.

Another example, buggy software that destroy data in worst case scenario (example) in this case will brick motherboard or it's components.

Leaving hardware internals open for damage from userspace is just too dangerous. With all respect, please, reconsider.

[lag-linaro]

Would you like to propose a solution?

Patches always welcome. :smiley:

[RussianNeuroMancer]

Would you like to propose a solution?

Is ufshcd-qcom could distinguish main/first/biggest block device from UFS storage from the rest block devices on UFS that contain service partitions? Maybe hide other block devices besides main/first/biggest by default if device boot via ACPI (as I understand eventually this laptops will boot via ACPI instead of DT, right?) but expose them (with warning message on driver loading) if device boot via DeviceTree or if kernel parameter was set by user (maybe something like "ufshcd-qcom.unhide_qcom_firmware=1" or any other name) is specified? What you think?

Patches always welcome.

I wish I would know how to propose solution not in the wall of text but with actually working implementation. Unfortunately at this point my knowledge is limited to stuff like this.

P.S. Sorry for several e-mail notifications that was probably sent by GitHub every time I corrected my previous message in this bugreport.

[lag-linaro]

There is no way of doing this at the kernel level, since it cannot reliably differentiate between partitions which must be visible to the user and ones which should not. The UFS kernel driver's responsibility is to provide access to the UFS device by 'driving' the hardware device, not to provide superficial limitations based on what data is stored on the various partitions. Hiding critical partitions would have to be controlled at the userspace level if at all.

This project is designed solely to help consumers bootstrap Linux on these devices, agnostic to distribution. It is not a distribution itself, nor does it govern how users operate their devices. Some of the consumers of this project might wish to access the various firmwares in order to add support for the available devices the machine supports.

I will go one stage further than just leaving this issue open by supplying a warning in the README.md, but that is as far as we will go.

[lag-linaro]

Project warning documentation: https://github.com/aarch64-laptops/build/commit/3fc3cde379fe02cb4b039f3c790e0289c6784e33