Remove SWAP file on SSD systems / provide option in installer

187 views
Skip to first unread message

Tai...@gmx.com

unread,
Sep 26, 2017, 3:43:32 AM9/26/17
to qubes...@googlegroups.com
It increases SSD wear and decreases privacy by writing temporary data to
disk (no bueno!), I believe an option should be provided in the
installer for this.

Developers thoughts? Would you accept a patch for this?

Peter Todd

unread,
Oct 1, 2017, 3:59:15 PM10/1/17
to Tai...@gmx.com, qubes...@googlegroups.com
On Tue, Sep 26, 2017 at 03:43:27AM -0400, Tai...@gmx.com wrote:
> It increases SSD wear and decreases privacy by writing temporary data to
> disk (no bueno!), I believe an option should be provided in the installer
> for this.

Re: privacy, you can setup swap files to use encrypted storage with *volatile*
encryption keys that are generated at boot, and never get written to persistent
storage. Dunno if Qubes does this already, but I've set this up myself on
Debian boxes before.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc

yura...@gmail.com

unread,
Oct 19, 2017, 11:59:33 AM10/19/17
to qubes-devel

As a temporary solution, you could place the SWAP at the far end of the drive, make it as small as possible so hardly nothing gets written to it, and then on-top of that implement the solution Peter Todd suggested, to be certain. If it tears on the SSD, then it will only happen to those same blocks all the time. Even if you re-install, just reconnect to the old SWAP, or re-make with same size/location at the end of the drive again. Even if blocks are destroyed here, it won't really matter, since you dedicated that tiny area at the end of the disk for this purpose, presumably until the day you throw it out due to old age.

It's not as beautiful as a solution to simply just skip it, but its practical solution here and now at least.

yura...@gmail.com

unread,
Oct 19, 2017, 12:04:01 PM10/19/17
to qubes-devel


On Tuesday, September 26, 2017 at 7:43:32 AM UTC, Tai...@gmx.com wrote:

I forgot to mention, I believe this partitioning tool is made by the Fedora Project? So even if requesting Qbues to fix this, it isn't feasible to do so, since it's not their repository. Perhaps this is better asked in a Fedora forum. Maybe it is even fixed in the newer Fedora versions already, however I did not check.

Chris Laprise

unread,
Oct 21, 2017, 12:21:31 AM10/21/17
to Peter Todd, Tai...@gmx.com, qubes...@googlegroups.com
On 09/26/2017 11:14 AM, Peter Todd wrote:
> On Tue, Sep 26, 2017 at 03:43:27AM -0400, Tai...@gmx.com wrote:
>> It increases SSD wear and decreases privacy by writing temporary data to
>> disk (no bueno!), I believe an option should be provided in the installer
>> for this.

I don't think wear is much of an issue with recent devices. But security
(at least as dom0 is concerned) is still an issue...

> Re: privacy, you can setup swap files to use encrypted storage with *volatile*
> encryption keys that are generated at boot, and never get written to persistent
> storage. Dunno if Qubes does this already, but I've set this up myself on
> Debian boxes before.

My first use of FDE also involved the manual setup of volatile keys on
swap. I always assumed this is the way that automatic installers did it,
too. I'm guessing the installers don't use volatile keys so they can
support hibernate.

So now I'm looking at my /etc/crypttab wondering if I can change it to
use /dev/urandom ?

--

Chris Laprise, tas...@posteo.net
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Vít Šesták

unread,
Oct 22, 2017, 9:07:50 AM10/22/17
to qubes-devel
Well, there are actually multiple swaps, roughly one per VM. Not having swap on Linux is rather a way to troubles despite having enough RAM, especially with memory balancing in Qubes, but you can make it more privacy-respecting.

The dom0 swap is configurable. I advise having it on a device encrypted by a random key instead of turning it off completely.

The swaps in default AppVMs are hardcoded in prepare-volatile-img.sh. They are always 1GiB. You can tune it, but when you update Qubes, it can get replaced. I have a tuning that moved volatile.img to another partition. The partition is encrypted by a key that is held in memory only, so the whole partition is protected in a similar way as dom0 swap.

Regards,
Vít Šesták 'v6ak'

Rusty Bird

unread,
Oct 22, 2017, 10:57:27 AM10/22/17
to Chris Laprise, Peter Todd, Tai...@gmx.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Chris Laprise:
> On 09/26/2017 11:14 AM, Peter Todd wrote:
> > Re: privacy, you can setup swap files to use encrypted storage with *volatile*
> > encryption keys that are generated at boot, and never get written to persistent
> > storage. Dunno if Qubes does this already, but I've set this up myself on
> > Debian boxes before.

That would be https://github.com/QubesOS/qubes-issues/issues/977 - now
titled "Use random encryption key for swap partition".

> So now I'm looking at my /etc/crypttab wondering if I can change it to use
> /dev/urandom ?

For R3.2 btrfs setups, see https://gist.github.com/rustybird/917ac2560fe4e9541d1f
but it won't work on LVM, i.e. R4.0... :(

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZ7K9aXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfhBoP/iC4c8L7X5yOa5G9K32qfT/g
K3JPfFy7GadzZjXH9Qb4AG1ioP+IdwpzGgsJKSRCIO3DMXc63Q1cgftvQInEUaB+
CiLC/FnTaJEXWJUGnwJQmyUbh3185hRgfH9m3gtLkseYVaV5BA1EikNgEP4wmgce
EFhwCKhaKK0p7Be77QBwu64cHz15aLuL+vy0hCyRvnYZGe0Pl6mUj1ycWFym8TaP
B/DqAxVhkuuhhalP572r6tZWOH+hVAWXgXf+ZYYeYY7CTs+Bj46OKhqMe4nH6mnd
oLZ9K7qTt9W4jmBkbeLd7wutrJMYXx/mQ0Rzoqeth+B7HGnLZsAwnhapp3Rrdsal
Pu5QneF844TCZLq384rShvigMoigyMKJoKOCDFRmnhR74RWD7YFIgel7tnQd3AsC
m7yAjpjd9viRDYmzQKBeKDjax51kOBSfJzN8z0zzM81vcyaV0HLJNAcM4rHgzJF9
V2g0agDCQ2Dt/3Nw4Ns8mEH5eUEyiPS2+UywMvLYVWXbSZ2kiq5AO66yGRxsmewx
ciXNsE+Ui4c5j+GtdTHSC58nrIANKC1joCq56COPvf4cChSrc+e8OaG06DecJl9d
d04KimpF3GBNF/UV6rpHO6Go5gDSuWM8CXyZ+Q7pTlZZL3Ek5UZPFTAX+zEcUdLk
cd0OWjVuhxMAkoXEH2Zj
=ur/t
-----END PGP SIGNATURE-----

Reply all
Reply to author
Forward
0 new messages