summaryrefslogtreecommitdiff
path: root/assets
diff options
context:
space:
mode:
authorA. Wilcox <AWilcox@Wilcox-Tech.com>2023-10-21 23:16:30 -0500
committerA. Wilcox <AWilcox@Wilcox-Tech.com>2023-10-21 23:16:30 -0500
commit21ebeeb18569086934c03721d3522b81ebdf859d (patch)
treef09f05459e3483d0b1f41165621aeb7cef458aa3 /assets
parentab212730bd17d6156edec350f3ff61aa0c7f9561 (diff)
downloadhorizon-21ebeeb18569086934c03721d3522b81ebdf859d.tar.gz
horizon-21ebeeb18569086934c03721d3522b81ebdf859d.tar.bz2
horizon-21ebeeb18569086934c03721d3522b81ebdf859d.tar.xz
horizon-21ebeeb18569086934c03721d3522b81ebdf859d.zip
hscript: bootloader: Take 100% control of efivarfs
We're the executor, we can just commandeer the entire thing, host system included. There is very low likelihood of damage to a host system because we are use umount instead of making the host r/w. The only thing that could break is `systemctl reboot --firmware`, or a host-side upgrade of GRUB that somehow changes the path of the EFI stub. Both of these are almost impossible to encounter on a host that is actually running the executor. However, encountering a broken read-only efivarfs seems to be VERY common in the Installation Environment. Fixes: ab212730bd ("hscript: bootloader: Set rdwr on 'real' efivarfs")
Diffstat (limited to 'assets')
0 files changed, 0 insertions, 0 deletions