Re: [Tails-dev] Critical Usability Issue due to which I Have…

Delete this message

Reply to this message
Autor: David A. Wheeler
Data:  
Dla: The Tails public development discussion list
Temat: Re: [Tails-dev] Critical Usability Issue due to which I Haven't Used Tails in Years
> From: Internet Spam <dpilspam@???>
> Date: Mon, Dec 5, 2022 at 2:41 AM UTC
> Subject: Critical Usability Issue due to which I Haven't Used Tails in Years
> ...
>
> The issue is this:
> Tails runs without any swap space (obviously, to maintain amnesia), the entire system may lock up at any moment due to heavy memory usage and opening of many Web browser tabs (which I usually do), the Magic Sysrq functionality of manually invoking the OOM killer in such emergency situations is disabled by default in Tails (and there's no way to enable without rebooting, and it's not recommended to enable it when connecting to the Internet as it's insecure), and Tails bundles no userspace early OOM daemon enabled out-of-the-box (such as systemd-oomd).
> The very least you can do is ship a new version of Tails with a slightly modified configuration value under /proc to enable the Magic Sysrq-F key combination. I request that you also consider shipping systemd-oomd enabled by default in the next major release of Tails (i.e. version 6.0).


I'm not a Tails developer, but I thought I might make a few comments that will hopefully be helpful.

Unfortunately, running many web browser tabs can easily use a lot of memory
depend on the pages being viewed. Doing this on a system without a large amount
of physical RAM *and* without swapping is asking for trouble.
The systems-oomd service itself *highly* recommends having swap enabled for it to work
<https://www.freedesktop.org/software/systemd/man/systemd-oomd.service.html>.

Making it easier to handle crashes isn't a bad idea, but that doesn't
*really* solve the end-user problem. What you *want* is a way to gracefully degrade
but have everything continue to work.

I think an alternative longer-term solution would be to allow users
to *enable* a swap file if the persistent storage is enabled.
After all, if persistent storage is enabled, you don't need perfect amnesia.
The easy implementation would then put the swap in a file
within the persistent storage; that way, you know it's encrypted, and
you don't have to manage a separate partition. Such swap space would be
slower than real RAM, but at least the system would keep doing its job.
I suggest setting the swappiness to a low value so it tends to be used only when needed;
the default is 60, but if you set it to 0 the kernel will not initiate swap until the
amount of free and file-backed pages is less than the high water mark in a zone
<https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/>.
This would be fairly easy to implement. You could do this at boot page time
or as a runtime system menu option. Doing it from
the GUI system menu is probably the most flexible.
Just make sure the backup system doesn't back up the swap file itself, just
the fact it exists (again, that should be easy to ensure).

Also enabling Magic Sysrq-F key seems reasonable to me, though maybe there's a
downside. That said, many users won't know
how to use it, and it's a sledgehammer best avoided where possible.

--- David A. Wheeler