on flingue les données avec sda, pas le matos lui-même
En fait même pas, l’argument de Lennart est encore plus falacieux que cela, rm /dev (comparé à rm /sys) ne flingue même pas les données, ça t’oblige seulement à rebooter...
et son excuse est bidon
Clairement bidon ! Il écrit par ailleurs :
Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.
Donc, il choisit consciemment de laisser un fichier modifiable 100% du temps chez tout le monde pour le cas où un jour quelqu’un a besoin de demander à redémarrer dans le firmware depuis sa distro... C’est complètement taré... Il suffirait très simplement que sa commande systemctl reboot --firmware remonte temporairement le système de fichier de configuration uefi le temps de configurer cela...
Aussi, d’autres mécanismes de sécurités peuvent être mis en place, par exemple pour dumper le vbios de ma carte graphique (on ne parle ici que de lecture seule, hein !) je dois faire cela :
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
The 'rom' file is special in that it provides read-only access to the device's ROM file, if available. It's disabled by default, however, so applications should write the string "1" to the file to enable it before attempting a read call, and disable it following the access by writing "0" to the file. Note that the device must be enabled for a rom read to return data successfully. In the event a driver is not bound to the device, it can be enabled using the 'enable' file, documented above.
Voyez le echo 1 ? c’est l’action « hey, je vais faire un truc inhabituel, mais je sais ce que je fais », c’est un peu comme le flag --yes-i-know-what-i-am-doing de hdparm.
L’option UEFI utilisée par Systemd pourrait utiliser des mécanismes similaires.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Tous coupables
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal rm -rf tue votre bios UEFI. Évalué à 10.
En fait même pas, l’argument de Lennart est encore plus falacieux que cela,
rm /dev(comparé àrm /sys) ne flingue même pas les données, ça t’oblige seulement à rebooter...Clairement bidon ! Il écrit par ailleurs :
Donc, il choisit consciemment de laisser un fichier modifiable 100% du temps chez tout le monde pour le cas où un jour quelqu’un a besoin de demander à redémarrer dans le firmware depuis sa distro... C’est complètement taré... Il suffirait très simplement que sa commande
systemctl reboot --firmwareremonte temporairement le système de fichier de configuration uefi le temps de configurer cela...Aussi, d’autres mécanismes de sécurités peuvent être mis en place, par exemple pour dumper le vbios de ma carte graphique (on ne parle ici que de lecture seule, hein !) je dois faire cela :
Voir à ce sujet sysfs-pci.txt :
Voyez le
echo 1? c’est l’action « hey, je vais faire un truc inhabituel, mais je sais ce que je fais », c’est un peu comme le flag--yes-i-know-what-i-am-doingdehdparm.L’option UEFI utilisée par Systemd pourrait utiliser des mécanismes similaires.
ce commentaire est sous licence cc by 4 et précédentes