On Thu, Dec 5, 2019 at 6:40 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote: > > No it isn't. But as I've asked you for your definition of "support" > > and you still haven't, and I've offered my own and you haven't > > disputed it, I win. That's the short version because you have a track > > record of not reading provided references. For the long version: > > There's nothing to "win". This isn't a competition. We're all on the same side > here. I am not confusing your persistent negativism and contrarianism with a competition. I win is tongue in cheek, of course we're all on the same side. Thank you for saying so explicitly. > My definition of "supported in Fedora" is.. supported in Fedora. You can do it > in Fedora. Without modifying anything. In my DE, for example, I'd do that by > pressing Alt + F1, the Super key, or click the KDE icon in the left of my > primary screen's Panel, Leave -> Hibernate. Using the word to be defined in the definition is insufficient and vague. It's meaningless. Feature existence is not support. The community members make a thing supported, and it's only by community effort and prioritization that features are supported. The track record of hibernation support, such as it is, is best effort, but not blocking. If it breaks, Fedora ships with it broken. There are flat out not enough resources to treat it with any higher priority than this - it's not a new issue either. > > > > > b. It's disabled by kernel lockdown on UEFI Secure Boot systems. > > > > > > > > > > > > How so? What "kernel lockdown" are you referring to? > > > > > > [ 1.097121] Lockdown: swapper/0: Hibernation is restricted; see man > > kernel_lockdown.7 > > > > And also the above kernel list email thread mentions it also. I'm > > surprised you haven't heard of it, it's been around for quite a long > > time as it's an obvious attack vector that obviates the point of > > Secure Boot. > > I don't have a personal system that uses UEFI, much less "Secure Boot", so I > things that affect those systems in Fedora, but not the versions of RHEL I > work with, I have no reason to follow normally. I'll take a look, however. > "Secure Boot" is a misnomer, by the way, and hibernation is not a security > issue. Suspension is, but not hibernation. All you're doing is demonstrating you don't understand the issues, or maybe you don't care about the use case. The hibernation image is not signed, thus malicious code could be injected into the image, and loaded and executed upon resume. Contrary to you merely saying things as if that makes them true, there is in fact a security issue with hibernation that is incongruent with the purpose of Secure Boot. It would be no different than allowing arbitrary loading of unsigned kernel modules, which is also disallowed by default on Secure Boot systems. $ dmesg | grep -i lockdown [ 0.000000] Kernel is locked down from EFI secure boot; see man kernel_lockdown.7 [ 1.097121] Lockdown: swapper/0: Hibernation is restricted; see man kernel_lockdown.7 [ 1.438916] Lockdown: systemd: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7 [ 1.439911] Lockdown: systemd: BPF is restricted; see man kernel_lockdown.7 More lockdown is coming in 5.4. > > > What are you talking about? You should have at least 1x RAM for swap > > > whether you use hibernation or not. If you're having issues, you can > > > adjust the swappiness as needed. There is no "effective loss of the > > > system" involved. > ...snip... > > In the case where swap is used heavily, rather than incidentally, the > > UX is atrocious. The resulting swap thrashing is ai bad the system is > > functionally lost and it's completely reasonable for a user to force > > power off. > > What are you suggesting the UX is atrocious for? Modifying the swappiness > value? I have come across situations where a system without swap OOMs, and > effectively freezes up as a result, causing the user to hard-boot the system, > but I have never seen that with a system where swap was at least 1x the amount > of RAM. The thread I cited contains an example of a consistently reproducible unprivileged compile that acts like a fork bomb that will take down the system, including one with swap size = 1x RAM. It reproduces on baremetal and in a VM. The time to OOM providing some chance of recovery is *extended* the bigger swap is. Thus the problem is actually made worse. > > There's actual background study and work to be done before a release > > criterion is accepted. Saying things doesn't make them true. The > > criterion itself needs to be written, test cases produced and sanity > > checked, and perhaps most importantly: who will be fixing the blocker > > bugs? You need willing people to be available from multiple teams, > > each having enough resources to ensure it gets highly escalated fixes. > > It doesn't really make any sense to dismiss this. If it's deemed necessary for > there to be a blocker, we can make a new blocker. That's a non-issue. You asked who told me that it's not supported, I referenced you the thread discussing that point in detail, and yet you're still being dismissive. You have a hypocrisy problem when you accuse others of being dismissive, and yet being dismissive of others is your default position. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
