I was wondering how this would impact multi-boot systems, as mixing hibernation and multi-boot is an extremely bad idea (unless you know what you're doing, and even then there a
are so many ways to shoot yourself in the foot).
"Also, I'm not 100% sure if that hibernation trick is actually possible, I've never really seen it on multi-boot systems and I wonder why, but from what I understand about hibernation (RAM gets saved to HD, restored next boot) the components are there?"
It is possible, I've done it. If you're on a multi-boot system with Linux and Windows, you can freely hibernate either and boot into the other, as long as they completely don't touch each other. Neither can even mount the disk images of the other, let alone start changing things, or you face effectively-guaranteed corruption. Be careful with shared SD cards too. (I had it so Linux would never auto-mount those anyhow, so it was OK.)
The biggest objection I'd have to your plan is mostly that you'd also need some sort of backup plan, I don't think USB sticks are generally designed to store thousands of dollars' worth of stuff on them.
Hibernation would work but then you have to make sure that the two operating systems don't share any drive (such as a data drive), because writing on a drive mounted by an hibernated system can cause all kind of weird issues.
Nope; if the hibernated OS has the storage volume mounted, and you edit that volume in another OS, separate or not you will end up with corruption, just as if two machines had mounted it simultaneously.
Wouldn't hibernating the machine and then copying the hibernation data to another machine do the trick? Sure it wouldn't be as instant, but it would skip most of the boot configuration.
Honestly hibernation never worked out perfectly in Linux. I have desktops to laptops running with different hardware, every once in a while the hibernation goes for toss and need to reboot
This seems like a bug because it means system state results in unpredictable behavior. There should be a dedicated swap for hibernation, like the pre-allocated hiberfile used by Windows.
Ah of course, I haven't thought about it that way, thanks for your explanation.
I guess it depends if you're willing to put all eggs in one basket so to speak. But instead of disabling hibernation outright maybe distros can find a compromise there.
My anecdotal experience with friends that tried Linux is that it left such a bad impression when they opened they're laptop the next morning and it's lost most of its battery life that some actually went back to Windows.
The Linux kernel is huge, complex and particularly messy in terms of internal structure. This makes even otherwise trivial modifications hard, and complex modifications extremely hard. The development overhead is brutal.
And hibernation just happens to be a scenario that's a nightmare to implement with such a design.
Never had problems with any. Ok, hibernation was a tough nut to crack, but you just have to make sure that your swap size matches your memory size... then it's just
Yes, the benefit of securely implementing hibernation with Secure Boot on for Linux is a direct benefit for Linux users, no impact one way or another for those using Windows.
Does hibernating via a swap file work reasonably well yet? I haven't had a chance to try this out yet, but that's the main reason I still have a swap partition on my laptop.
Remember that a hibernating system is actually in a low power state, but there's still some draw. This means that specific processes might be running.
Baseboard / preboot / bootloader and other execution environments, including even running within the firmware of specific peripherals, is a concern I've been aware of since ~2005, from people who are taken exceptionally seriously in the security community. Context was a presentation following an RSA conference and Intel's plans at the time for extensive baseboard/preboot environments (which have largely failed to take hold on consumer hardware, though many/most server systems now have same).
Do I think the risk is high? No. But it's nonzero.
reply