5 ms·

> I think swap should always be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I kno

> I think swap should always be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I know has run hexdump on his swap partition and found PGP private keys in plain view. Your SSH key might be password-protected on disk, but it could end up in swap sooner or later... with no password needed. GnuPG and a few other security-conscious programs try to avoid this by using mlock() [1]. Unfortunately, by default the ZFS ARC can grow beyond the limit for wired pages, which will make those mlock() calls start failing once the system has been up long enough [2]. [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html [2] https://ximalas.info/2012/04/10/not-enough-room-for-wired-pages/ https://ximalas.info/2012/04/10/not-enough-room-for-wired-pa...

vog 9y ago
Moreover, you have stuff like password managers going though the clipboard. Relying on all tools correctly identifying their sensitive datasets and protecting them though mlock() is doomed to fail. If anything, a proper security concept should whitelist insensitive datasets, instead of blacklisting sensitive datasets. I don't get why any modern OS would use unencrypted SWAP. The default should be either encrypted SWAP, or no SWAP at all. The downsides are negligible compared to the upsides.
- ilammy 9y ago
  > encrypted SWAP When I was setting up dm-crypt for my Linux dev box at work I opted for using an encrypted swap as it really made sense: why keep on-disk stuff encrypted if swapped memory is in plain sight. It turned out to be a somewhat bad decision, because when the system did run out of memory (thank you, Firefox and Skype) and began swapping, the whole box just freezes as the kernel was too busy encrypting more and more stuff, not having time to even run the OOM killer. Maybe the systems use unencrypted swap to avoid triggering such bugs in default setups.
  - wolf550e 9y ago
    I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.
    - noinsight 9y ago
      Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4. You can test it yourself with `cryptsetup benchmark`: # cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 1874.2 MiB/s 2042.6 MiB/s I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.
      - wolf550e 9y ago
        cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 2266.2 MiB/s 2273.8 MiB/s perf says 21.86% cryptsetup [aesni_intel] [k] _aesni_dec4 19.83% cryptsetup [aesni_intel] [k] _aesni_enc4 17.80% cryptsetup [aesni_intel] [k] aesni_xts_crypt8 13.73% cryptsetup [kernel] [k] copy_user_generic_unrolled 2.20% cryptsetup [kernel] [k] get_page_from_freelist 1.86% cryptsetup [glue_helper] [k] glue_xts_crypt_128bit 1.53% cryptsetup [kernel] [k] put_page 1.36% cryptsetup [kernel] [k] blkcipher_walk_done so it's using the code from: https://github.com/torvalds/linux/blob/master/arch/x86/crypto/aesni-intel_asm.S#L2848 https://github.com/torvalds/linux/blob/master/arch/x86/crypt... I don't know if using AVX would speed it up. openssl is faster (openssl speed -evp aes-256-gcm and aes-256-xts).
- msla 9y ago
  Sure, they'll have an encrypted SWAP, and an unencrypted swap, and developers will choose which to use. Leverage Unix's case-sensitivity. /s
- kingofhdds 9y ago
  To tilt defaults to a safer side is usually (though, not always) good, if it's meant to be out-of-the-box system. Definitely, not the case here as bare-bones FreeBSD is essentially a platform for building a user's own solution for own needs. Not making too much assumptions about what they are is actually very rational for FBSD devs. I know my goal better, I know which choices/compromises I want to make.
kingofhdds 9y ago
FreeBSD is a tune-it-yourself OS. You think your swap should be encrypted? Fine, append ".eli" to the name of your swap GEOM (partition, slice, whatever) in fstab, and you're done. Some may not require this at all, because FreeBSD may be used in a lot of different situations. Your needs - your choice.
- na85 9y ago
  The submission in question is about defaults, not about choice.
  - kingofhdds 9y ago
    https://news.ycombinator.com/item?id=16012670 https://news.ycombinator.com/item?id=16012670

vog 9y ago

Moreover, you have stuff like password managers going though the clipboard. Relying on all tools correctly identifying their sensitive datasets and protecting them though mlock() is doomed to fail. If anything, a proper security concept should whitelist insensitive datasets, instead of blacklisting sensitive datasets. I don't get why any modern OS would use unencrypted SWAP. The default should be either encrypted SWAP, or no SWAP at all. The downsides are negligible compared to the upsides.

ilammy 9y ago
> encrypted SWAP When I was setting up dm-crypt for my Linux dev box at work I opted for using an encrypted swap as it really made sense: why keep on-disk stuff encrypted if swapped memory is in plain sight. It turned out to be a somewhat bad decision, because when the system did run out of memory (thank you, Firefox and Skype) and began swapping, the whole box just freezes as the kernel was too busy encrypting more and more stuff, not having time to even run the OOM killer. Maybe the systems use unencrypted swap to avoid triggering such bugs in default setups.
- wolf550e 9y ago
  I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.
  - noinsight 9y ago
    Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4. You can test it yourself with `cryptsetup benchmark`: # cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 1874.2 MiB/s 2042.6 MiB/s I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.
    - wolf550e 9y ago
      cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 2266.2 MiB/s 2273.8 MiB/s perf says 21.86% cryptsetup [aesni_intel] [k] _aesni_dec4 19.83% cryptsetup [aesni_intel] [k] _aesni_enc4 17.80% cryptsetup [aesni_intel] [k] aesni_xts_crypt8 13.73% cryptsetup [kernel] [k] copy_user_generic_unrolled 2.20% cryptsetup [kernel] [k] get_page_from_freelist 1.86% cryptsetup [glue_helper] [k] glue_xts_crypt_128bit 1.53% cryptsetup [kernel] [k] put_page 1.36% cryptsetup [kernel] [k] blkcipher_walk_done so it's using the code from: https://github.com/torvalds/linux/blob/master/arch/x86/crypto/aesni-intel_asm.S#L2848 https://github.com/torvalds/linux/blob/master/arch/x86/crypt... I don't know if using AVX would speed it up. openssl is faster (openssl speed -evp aes-256-gcm and aes-256-xts).
msla 9y ago
Sure, they'll have an encrypted SWAP, and an unencrypted swap, and developers will choose which to use. Leverage Unix's case-sensitivity. /s
kingofhdds 9y ago
To tilt defaults to a safer side is usually (though, not always) good, if it's meant to be out-of-the-box system. Definitely, not the case here as bare-bones FreeBSD is essentially a platform for building a user's own solution for own needs. Not making too much assumptions about what they are is actually very rational for FBSD devs. I know my goal better, I know which choices/compromises I want to make.

kingofhdds 9y ago

FreeBSD is a tune-it-yourself OS. You think your swap should be encrypted? Fine, append ".eli" to the name of your swap GEOM (partition, slice, whatever) in fstab, and you're done. Some may not require this at all, because FreeBSD may be used in a lot of different situations. Your needs - your choice.

na85 9y ago
The submission in question is about defaults, not about choice.
- kingofhdds 9y ago
  https://news.ycombinator.com/item?id=16012670 https://news.ycombinator.com/item?id=16012670