On Sat, Aug 17, 2019 at 6:25 PM Joseph D. Wagner <joe(a)josephdwagner.info&gt; wrote: I wonder if systemd could provide a way for a service to ask for poweroff when a timeout has been reached, and for plymouth to set something like 20 minutes for the timeout? I agree that this shouldn't be an indefinite wait. Even consider a laptop scenario, we're going to wait until the battery completely discharges? That's not a good idea. -- Chris Murphy

On 2019-08-18 02:57, Vitaly Zaitsev via devel wrote: It is intended to display the same image on the screen continuously until I suffer from screen burn-in? My issue is not with waiting forever on the password prompt. My issue is with displaying the same password prompt forever, causing screen burn-in. There are unexpected reboots, like crashes and dual-boot systems where a non-default OS decides to automatically reboot for updates, only for the reboot to go into the default with LUKS. Joseph D. Wagner

Vitaly Zaitsev via devel wrote on Mon, Aug 19, 2019 at 09:31:33AM +0200: He's not asking for pretty moving pictures, just blanking the screen is fine. the tty can do it just fine tunable in /sys/module/kernel/parameters/consoleblank so this really is a plymouth bug to me, it should have everything it needs for this embedded in the initrd to be able to do that before the OS fully loads. LCD definitely has this issue - display the same image forever and the pixels will remember it / you will be left with an overlay of the previously still image. I'm not sure if the shiniest newest generations of LCD have the problem or not, but I've had multiple generations (latest being 5ish years old) and they all have the issue - for example the top/bottom bars of my window managers are burned in and the rare times I leave it on white-ish background I can still see them, because it's just always there and hardly ever changes. It's unnoticeable most of the time but definitely present, if the luks prompt stays up for a few weeks I'm sure it'll be visible. (It's probably fine overnight, but it can't hurt the electricity bill anyway) -- Dominique

On 19.08.2019 12:38, Dominique Martinet wrote: This is a known IPS displays issue, known as "ghosting". This is not a burn-in. It cannot harm display at all. Manufacturers does not treat this as a defect. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

On 8/19/19 3:42 AM, Artur Iwicki wrote: That doesn't make any sense. When are you going to have a laptop that isn't plugged in do a reboot with no one watching it? It doesn't matter whether or not the screen is blanked, the laptop is going to run out of battery anyway.

On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote: I don't think it's fair for one person to decide what the "right thing to do" is. This kind of thinking is what leads to things like GNOME's awful defaults. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Tuesday, August 20, 2019 8:31:27 AM MST Przemek Klosowski via devel wrote: Considering an environment that I support would require this to be disabled (always show the prompt, while it's up), I would generally be against this change if it is not implemented as an option. Additionally, as this is being implement counter to the default behavior for the last decade, I would suggest that it be disabled by default, with an option for users to enable it if they would like. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Wednesday, August 21, 2019 3:10:04 AM MST Ernestas Kulik wrote: That's precisely my point though. If you're not either the one implementing the change, or paying for the change to be made by somebody else, you don't get to make the decisions. As far as GNOME goes, it's not my fault that it's nearly unusable out of box, to the extent that, at work, we immediately (okay, after a week or so) manually compiled KDE for our RHEL8 systems, and just installed the packages for RHEL7 and RHEL6 systems. In RHEL6 it wasn't too bad, so we still kept it around as an *additional* option for users there. That isn't really relevant to this thread, of course. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On 8/19/19 7:15 PM, Chris Murphy wrote: At my work, most of the windows laptops have full disk encryption so I asked a coworker for some info. She started her laptop on battery and let it sit at the encryption password prompt for about 30 minutes and nothing happened. She also told me that she has seen other laptops at the office that were probably auto rebooted on Friday and were still waiting at the prompt on Monday.

On 8/20/19 4:31 AM, Samuel Sieb wrote: It's exactly as you imply---McAfee waits for a typed password, whereas bitlocker typically uses TPM and so it proceeds to Windows user login, which times out and goes to sleep.

As for macOS, it will shut down the machine after a minute or two (haven’t measured) if you do not enter your passphrase. BK

With disk encryption turned on. (They call it FileVault.) BK

On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote: List I think we can all agree that shutting the system down is not the appropriate behavior, right? -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote: I've personally had this happen to me several times, where (far more improtantly than the battery) a laptop tucked into a confined sleeve got inadvertantly powered on and essentially baked itself while sitting at that password prompt. So, yes, powering off is a completely sensible thing to do. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur.

On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote: There is no significant fire risk from this. It's just not good for the laptop. There's not exactly a temperature range that can cause damage, but there is a nominal range for each individual chip, and a nominal range for the entire system based on that. Anything over isn't guaranteed to do damage, but will definitely degrade performance, and anything significantly outside of that range, in either extreme, could do permanent damage. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Tuesday, August 20, 2019 8:19:24 PM MST Chris Murphy wrote: entire system based on that. Anything over isn't guaranteed to do It simply negates your claim, nothing more. We're not considering fire risks here. Once a system reaches the upper, and sometimes lower, extreme of that system's rated range (which will be different per system, and not something we can throw in the OS), the EC, the PMC, the MC or similar system will shut down the system on most consumer hardware, unless the user has explicitly disabled it, which isn't possible without flashing your own firmware on many systems. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On 8/20/19 11:15 PM, John Harris wrote: You're right that fire is not the principal risk: instead, it's cooking the chemicals in the LCDs and batteries---not the chips, which typically have operating maximum temperature of 80C. The LCD operating temperature is typically up to 50C, and a typical absolute maximum  temperature is 60-70C (*). The batteries have similar limits. Solomon reported burning sensation, which typically means 60C or more. I would prefer a suspend---hit a key or move a mouse and see the prompt again. Still, what's wrong with a quick reboot? The additional time from power up to disk decryption is typically short, unless we're talking servers with tons of secondary firmware. I think Fedora should optimize for laptops/desktops, so if we had to chose one default I would vote for sleep, or shutdown if sleep was not available. but it's less secure---the decryption password hashes (**) have to be present on the media. Bitlocker in TPM mode has the secrets locked in the TPM, and as an added benefit uses the 'enterprise' authorization scheme, with revocation, recovery keys, single logon (no separate decryption and login credentials), etc. You wrote that bitlocker 'configured properly ... simply shows a prompt forever', but I think that the current best practice is to use TPM, in which case the system proceeds to the login prompt, and the full decryption is only done after user authentication. I think that's how FileVault in MacOS works, and perhaps Linux is also heading this way. (*) https://www.pacificdisplay.com/cdm/CDM-40200.pdf (**) Note that in a commercial context this includes the user password as well as any recovery passwords, which may be common across the enterprise so the risk is even more significant.

On 22/08/2019 00:10, Chris Murphy wrote: Hi, and while the subgroup of the group investigates ... Perhaps it would be a good idea to ask LUKS maintainers during the process, what do you think about the idea? :-) With the upstream maintainer hat on, there are several groups, that pushes very hard for TPM use, and others against it, for years already. (Just TPM1.2 is now obsolete, and most hw vendors pretend it never even existed.) This is Linux, there are so many possible use cases that the only strategy is to allow maintainers to configure it. If you see what is going upstream now, I am trying to prototype support for dynamic token handlers. (A LUKS2 token is an object that can be used to unlock LUKS keyslot using some external input - like TPM2). All this stuff can be completely disabled/compiled out, but also we can have TPM2 token handler installed by default - it depends on user/distro policy. You can use wrappers like Clevis/Tang, but there will also be a more straightforward solution to use TPM2 in LUKS2 in the near future. The initial idea behind LUKS is that it is a hw-independent solution, that's why we have very strong memory-hard password-based key derivation there for opening a keyslot. (If you have a decently strong passphrase, offline dictionary attack cost is very high, even if you have massive computation power.) If you enable an attacker to just unlock it using present hw, most of the parameters do not make sense anymore. It depends on the threat model, but let just expect stolen laptop that unlocks the disk automagically on that hw. And of course, we can use TPM with a PIN. Then our brave automation will try to use a cached passphrase (for example), and locks out TPM chip with exceeding number of PIN tries :) Also, the use of TPM2 can be very fragile. Seems that PCR registers changes are very different on different hw. Changing some BIOS option can cause that your system no longer boots, while on other hw it still works. So before you enable any such mechanisms, be very careful, you are opening a big can of worms. Milan p.s. Actually, there are also plans for much broader academic research for TPM2 behavior, and I would be more than happy if Fedora users could help us. Stay tuned ;-)

On Tuesday, August 20, 2019 5:34:03 PM MST Alexander Ploumistos wrote: For a system running on battery, it'd be okay to throw in power down at ~30% or whatever user configurable percentage, in my opinion. If such a thing were to be implemented, I'd suggest defaulting to 30% on battery powered systems, and, in that one instance, it'd probably be okay to change it to that from the default behavior. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote: behavior, right? Okay, why? -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Tuesday, August 20, 2019 7:59:44 PM MST Chris Murphy wrote: I'm sorry, but I don't see a list anywhere. Could you provide me with the Message-Id? In laptops, I would agree that we should add a cutoff before the battery is drained, as certain battery chemistries cannot be fully utilized if they frequently fall below a certain level, lithium-Ion in particular. For a laptop, 3 minutes may be a sane option. Definitely not for a workstation or server. I personally don't like that on laptops either, as the laptop could have been remotely rebooted, and seeing that would be the nod somebody needs to see to go enter the key and get it booted, or what have you. I would personally disable it on my systems, for example, and I would recommend against setting it as the default because it is much different from current behavior. Why would this behavior be in any way desirable on a desktop system? A TPM or other hardware key storage does not solve the same problem as asking for a key to be entered to decrypt. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

On Wed, Aug 21, 2019 at 09:34:57AM +0200, Vitaly Zaitsev via devel wrote: We're not talking about taking the system out behind the toolshead here. Is LUKS really so brittle that 'shutdown -h now' is insufficient? I'll agree that this behavior arguably doesn't make sense for servers as they're typically unattended with limited physical access, and reboots are usually rare. Workstations, on the other hand -- if there's nobody to enter the password on the coneole, what's the point of leaving it spun up, wasting power indefinitely? Meanwhile, for laptops, the only sane default to have is to shut down after some "small X" amount of time. (What constitutes a laptop? Something with a battery. Laptop that's plugged in? treat it as a workstation.) (And yes, I know that the only practical difference between a "workstation" and a "server" is the software that's installed/enabled) - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur.

On 20/08/19 20:59 -0600, Chris Murphy wrote: Just that the particular corner case is not perceived in isolation, there are other early-boot-stuck situations that would make sense to deal with in the same fashion even if the sources are completely different (predictability is more important from user's POV, IMHO). One such other situation is having the bootloader (grub2) failed and hence be stuck in 'press a key to continue' or just staying in the selection menu without any timeout ticking for whatever reason. That's directly comparable to the LUKS prompt without any attention for a prolonged time. With grub2, situation is actually worse, since without having any means to control CPU throttling (which is already present by the time one is to enter LUKS password), laptop will indeed become said "heating pad" after a bit (one could for instance enter the grub prompt if it's deemed a feature for some). -- Poki

On Fri, Aug 23, 2019 at 5:48 AM Jan Pokorný <jpokorny(a)redhat.com&gt; wrote: There is signature verification of all the bootloader binaries, and the kernel, in the UEFI Secure Boot case. I'm not sure what kind of signature checking could be enabled in the case of UEFI Secure Boot disable and BIOS and other firmware types. First, there'd need to be some way to identify an error, then what can be done (try another kernel, OK what if that fails?) to mitigate it. Since Fedora 30, the grub.cfg is no longer modified by grubby, it's a static configuration file. So at least in the normal case, it's created correctly from the outset and other than bit rot it should always be present and correct forever. What if any of that changes? I'm not sure what the fallback behavior is, it's possibly worth exploring. The Fedora GRUB BLS module does have some sanity testing of the BLS snippet in it, but I'm not sure how robust it is and if there's a fallback other than trying another menu entry, which means trying another kernel. At the point which it's exhausted all menu entries and kernels, then what? Does GRUB in the pre-boot environment on all archs have the capacity to power off the system? I'm not sure. It's an interesting question. -- Chris Murphy

On Fri, Aug 23, 2019 at 12:59 PM John Harris <johnmh(a)splentity.com&gt; wrote: GRUB verifies the signature of the kernel before it is booted, in the Secure Boot enabled case. a. Press any key before the timeout and it won't shutdown b. Power back on, and don't walk away, so you can press any key before the timeout, and it won't shut down The only way you're going to troubleshoot bootloader problems is having the equivalent of physical access. -- Chris Murphy

On Monday, August 19, 2019 3:42:10 AM MST Artur Iwicki wrote: I'm sorry if this comes off as a bit rude, but "works for us, so why bother" is an absolutely fine response, unless you're getting paid to implement said feature request. -- John M. Harris, Jr. <johnmh(a)splentity.com&gt; Splentity https://splentity.com/

Tomasz Torcz wrote on Mon, Aug 19, 2019 at 04:45:31PM +0200: interesting, I had missed that it had been disabled in a4199f5eb8096d63[1] -------- From: Tim Gardner <tim.gardner(a)canonical.com&gt; Date: Wed, 22 Mar 2017 09:07:20 -0600 Subject: [PATCH] tty: Disable default console blanking interval BugLink: http://bugs.launchpad.net/bugs/869017 Console blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that any crash output is invisible which is unhelpful on a server (virtual or otherwise). Furthermore, CRT burn in concerns should no longer govern the default case. Affected users could always set consoleblank on the kernel command line. --------- I guess I can take back my previous mail if this works with plymouth (not sure if it is strictly console ?), thank you for pointing that out. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit... -- Dominique