Tails

#3 Updated by sonicsnail 2016-02-06 00:20:10

I’ve been having issues with suspend too. If I never close the lid, Tails shuts down as normal and emergency shutdown works fine too. But if I close the lid (suspend) and re-open it, and then attempt to shut down, Tails gives errors and doesn’t shut down and doesn’t wipe the memory; emergency shutdown doesn’t work after suspending either. Also, sometimes after suspending, Tails is frozen for about 30 seconds. None these problems existed on Tails 1.X because suspend was disabled.

Part of this is probably because I’m using an Acer C720 chromebook, which is known for having suspend issues on linux. A fix is documented here, along with the same errors I’ve been getting: http://www.circuidipity.com/c720-chromebook-to-jessiebook.html#suspend

#4 Updated by sonicsnail 2016-02-06 00:24:12

I think what sajolida is talking about relates to a tradeoff between security and convenience. While it’s convenient to be able to suspend Tails, it disables a security mechanism. In my opinion, Tails should be secure by default, and if it’s not possible to fix suspend so emergency shutdown works all the time, no matter what, then we shouldn’t be suspending. The nature of emergencies is that you can’t predict when they’ll happen, which is why safety mechanisms need to be reliable and always ready for immediate use.

Worst case scenario: if the default were to suspend, and if attackers managed to do a cold boot attack on a user’s suspended Tails system after the user removed the USB drive (mistakenly thinking that emergency shutdown would activate), Tails could be blamed for having insecure defaults.

So I think “not suspend” should be the default, and if necessary there could be an option to enable suspend (or documentation on how to do this) but with a warning that it disables emergency shutdown. That way, if users find it convenient to manually enable suspend all the time, they do so accepting the increased risk.

#5 Updated by elouann 2016-02-29 23:34:30

Suspend seems to freeze some devices:

MacBookPro12,1

Exact steps to reproduce the error
—————————————————
Close and open laptop lid

Actual result and description of the error
—————————————————————
Cursor is frozen and Tails apparently cannot be accessed without some way to un-freeze it. Computer must be restarted for functionality to reappear.

Cursor is frozen even if mouse and/or trackpad are functional by themselves (ex. light glowing on USB mouse)

#6 Updated by elouann 2016-03-07 14:08:51

Another bug report related to suspend on lid

Subject: unwanted suspend-to-ram during using actively tails 2.0.0 and 2.0.1

Exact steps to reproduce the error
—————————————————
During active working the system falls in suspend-to-ram.
reativating, awaking without any errors, but it falls back to suspend-to-ram in few seconds.

This happens with a samsung x20-notebook, that causes no problems with debian-distribution now for several years…
No problems with various distributions and live-systems.

No problem with tails in all versions now for more than one year.
This problem appeared in tails 2.x for the first time.

#8 Updated by volenta 2016-08-19 15:50:54

Yo,

This sed one-liner in config/chroot_local-hooks/48-disable-suspend-when-closing-lid will do the trick :

sed -i --regexp-extended 's/^#?HandleLidSwitch=.*/HandleLidSwitch=ignore/' /etc/systemd/logind.conf

:)

#12 Updated by segfault 2016-08-28 08:30:08

It seems like #11395 is blocked by Bug #11729. I don’t have time to fix Bug #11729 any time soon, so if no one else does, #11395 won’t happen any time soon. Because Bug #11729 also effects the suspend-to-RAM caused by closing the lid, I think we should apply this patch and prevent the suspend on lid closing.

#15 Updated by Anonymous 2018-08-17 16:48:27

segfault wrote:
> It seems like #11395 is blocked by Bug #11729. I don’t have time to fix Bug #11729 any time soon, so if no one else does, #11395 won’t happen any time soon. Because Bug #11729 also effects the suspend-to-RAM caused by closing the lid, I think we should apply this patch and prevent the suspend on lid closing.

#11395 seems to be the ticket that has accidentaly been deleted so it’s not clear what you are talking about :(
See https://labs.riseup.net/code/issues/12597

#17 Updated by segfault 2019-03-29 00:47:05

u wrote:
> segfault wrote:
> > It seems like #11395 is blocked by Bug #11729. I don’t have time to fix Bug #11729 any time soon, so if no one else does, #11395 won’t happen any time soon. Because Bug #11729 also effects the suspend-to-RAM caused by closing the lid, I think we should apply this patch and prevent the suspend on lid closing.
>
> #11395 seems to be the ticket that has accidentaly been deleted so it’s not clear what you are talking about :(
> See https://labs.riseup.net/code/issues/12597

For the record: #11395 was about showing the suspend button, the new ticket for this is Feature #14556.

#20 Updated by segfault 2019-04-03 10:44:14

intrigeri wrote:
> segfault wrote:
> > Optimistically setting to ready for QA because the only subtask is also ready for QA.
>
> @segfault, there’s no subtask currently. I guess you meant Feature #14556. Anyway, I trust you this is ready and I’ll review it.

Right, #11395 was the subtask until it got accidentally deleted and replaced by Feature #14556.

#23 Updated by intrigeri 2019-04-04 12:29:02

Code review passes, will build & test.

#25 Updated by intrigeri 2019-04-07 17:09:42

@segfault, we should probably not merge this before https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919914 is fixed in Buster: otherwise we would need to revert it and change users’ expectations again in just a few months.

#28 Updated by intrigeri 2019-05-01 08:54:37

> We don’t have the logs of the meeting in which we decided to not suspend when closing the lid (Bug #11052#note-7, “almost 3 years ago”) but this decision seems to be older than Bug #11729 (“over 2 years ago”).

Indeed, we don’t have the full logs; we have only this in the meeting minutes:

# [[!tails_ticket 11052 desc="Do not suspend when closing lid "]]

- Coming back from suspend breaks sometimes on some hardware.
- But suspend disables emergency shutdown (until the lid is open again)
and some people might be surprised by this.

So we want to support both options and thus what makes more sense is to
add an option to suspend from the system menu through some button,
keyboard shortcut, or a combination of both. Hypothesis are:

- Replace the "Restart" button with a "Suspend" button. That's more
visible.
- Change "Restart" or "Power Off" into "Suspend" when pressing "Alt".
That's more like the default in GNOME.
- Have an additional and dedicated button for "Suspend". But we might
add yet another button for the screen locker.

Regarding “Coming back from suspend breaks sometimes on some hardware”: this was reported for exactly one laptop, more than 3 years ago, while we’ve had suspend-on-lid-close enabled for years. There’s a good chance some upgrade fixed that since. I’ve not seen this happen on non-Tails Debian systems around me for many years. So I don’t think this is a strong argument nowadays.

Regarding “suspend disables emergency shutdown (until the lid is open again)”: this seems to be the only relevant argument in favour of disabling suspend-on-lid-close. Let’s focus on this one.

> So I’m a bit reluctant to override this decision without knowing how and why we made it.

I’m on the same page but I see no way to know now more precisely how and why we made it, so the best we can do is to glean whatever hint we can in these meeting minutes, tickets history, which we did already :/

> I’m not sure what to do now even though my personal preference would be to suspend when closing the lid.

Same here. Let’s also keep in mind that we’ve had suspend-on-lid-close enabled for years and I’m not aware of anyone raising serious concerns/issues with it since we discussed this 3 years ago. So perhaps it’s not such a big deal.

I’ll propose on tails-dev@ that we keep suspend-on-lid-close enabled, so whoever has a strong opinion about it has room to express it.

#31 Updated by segfault 2019-05-01 23:17:52

> Regarding “Coming back from suspend breaks sometimes on some hardware”: this was reported for exactly one laptop, more than 3 years ago, while we’ve had suspend-on-lid-close enabled for years. There’s a good chance some upgrade fixed that since. I’ve not seen this happen on non-Tails Debian systems around me for many years. So I don’t think this is a strong argument nowadays.

I guess that “Coming back from suspend breaks” was caused by Bug #11729. I’ve seen Bug #11729 myself repeatedly on at least two different laptops, the hardware I used to debug Bug #11729 was affected in about 1 out of 3 cases. If this issue occurs similarly frequently on most hardware, a lot of users would have been affected by it. That would again be a hint that “we don’t get many bug reports” does not equal “not many users are affected”.

> Regarding “suspend disables emergency shutdown (until the lid is open again)”: this seems to be the only relevant argument in favour of disabling suspend-on-lid-close. Let’s focus on this one.

I agree.

> Let’s also keep in mind that we’ve had suspend-on-lid-close enabled for years and I’m not aware of anyone raising serious concerns/issues with it since we discussed this 3 years ago. So perhaps it’s not such a big deal.

Note that in order to fix Bug #11729, I disabled the udev-watchdog during suspend. Previously, the system would emergency shutdown on resume if the Tails device was unplugged while the system was suspended. That will not be the case anymore, the system will keep running if the Tails device is unplugged during suspend.
We could work around this by adding an extra check for the boot device on resume, which will trigger the emergency shutdown if the device is not found.

#32 Updated by intrigeri 2019-06-01 11:43:08

segfault wrote:
> Note that in order to fix Bug #11729, I disabled the udev-watchdog during suspend. Previously, the system would emergency shutdown on resume if the Tails device was plugged out while the system was suspended. That will not be the case anymore, the system will keep running if the Tails device is plugged out during suspend.

Right.

> We could work around this by adding an extra check for the boot device on resume, which will trigger the emergency shutdown if the device is not found.

This would be sweet, but I’m not 100% sure we can do that in a way that does not cancel the fix for Bug #11729 (commit:e4e7f81288ff9723b94ec434bbc7006ce240cb0f) and reintroduce that problem on affected hardware. I’m not sure because I don’t fully understand what exact behaviour caused Bug #11729. If we assume that the emergency shutdown was triggered while suspending, queued, and actually executed while resuming, we should be fine. If OTOH the reason for Bug #11729 is a about a more complex (and racy) situation, then there’s a chance that when we implementing this, we find out that it’s hard to tell when exactly we can check “if the device is not found”: if we check too early, then possibly the system hasn’t re-discovered that device yet, or something like that.

#33 Updated by intrigeri 2019-06-01 12:07:50

I’ve made an updated proposal, which integrates segfault’s great idea, on tails-dev@. I’ll come back to it in a few weeks.

#35 Updated by segfault 2019-06-01 20:57:08

intrigeri wrote:
> segfault wrote:
> > Note that in order to fix Bug #11729, I disabled the udev-watchdog during suspend. Previously, the system would emergency shutdown on resume if the Tails device was plugged out while the system was suspended. That will not be the case anymore, the system will keep running if the Tails device is plugged out during suspend.
>
> Right.
>
> > We could work around this by adding an extra check for the boot device on resume, which will trigger the emergency shutdown if the device is not found.
>
> This would be sweet, but I’m not 100% sure we can do that in a way that does not cancel the fix for Bug #11729 (commit:e4e7f81288ff9723b94ec434bbc7006ce240cb0f) and reintroduce that problem on affected hardware. I’m not sure because I don’t fully understand what exact behaviour caused Bug #11729. If we assume that the emergency shutdown was triggered while suspending, queued, and actually executed while resuming, we should be fine. If OTOH the reason for Bug #11729 is a about a more complex (and racy) situation, then there’s a chance that when we implementing this, we find out that it’s hard to tell when exactly we can check “if the device is not found”: if we check too early, then possibly the system hasn’t re-discovered that device yet, or something like that.

True, but we should be able to work around that with by waiting a few seconds after resuming before checking the device.

I would implement this by putting another script in /lib/systemd/system-sleep which, on resume, sleeps a few seconds and then checks whether the boot device is there, and shuts down if it’s not. We could reuse the functions from udev-watchdog-wrapper for that (which we should then extract into tailslib), although I’m not sure whether the current implementation of boot_device() works in the case that the boot device was removed.

#36 Updated by sajolida 2019-06-02 16:41:15

Yes, we should definitely shutdown if the Tails device is unplugged while the computer is suspended!

#37 Updated by sajolida 2019-06-02 16:48:30

We decided on http://lists.autistici.org/message/20190515.110800.2c7b5109.en.html that we want to keep suspending when closing the lid.

as intrigeri wrote: It may be nice to provide a way to somehow tell Tails “I’m going to
close the lid but please don’t suspend, because I want to keep the
system up and able to trigger emergency shutdown if I unplug the Tails
device”.

This is a new feature request with a tiny target user base and we’re not
interested in putting much energy into it.

#39 Updated by intrigeri 2019-06-07 10:44:57

> Yes, we should definitely shutdown if the Tails device is unplugged while the computer is suspended!

See you on Bug #16787 then :)