Encrypted SSD with MicroOS good idea or not?
Hi all, I’ve been thinking about a while now about a conversation I had with Richard about encryption with MicroOS with a SSD. Due to the immutable nature of MicroOS trimming would not work on a encrypted SSD. And over time the SSD would become slower and slower and slower. Is there any way we could mitigate this? As I’m running MicroOS on my business laptop I feel really weird having client data on my machine. I’ve already changed to Leap/SLED/Tumbleweed because of this, but MicroOS always lures me back in, and then I feel weird about it. Best, Syds
Hey,
I've had the same issue with my ssd where it took 3 to 5 minutes to shutdown/start my computer.
Moving my home partition from btrfs to xfs solved it. I do not know why but i always get latency when encrypting btrfs partitions
On Mon, Aug 2, 2021 at 20:34, Syds Bearda
Hi all,
I’ve been thinking about a while now about a conversation I had with Richard about encryption with MicroOS with a SSD.
Due to the immutable nature of MicroOS trimming would not work on a encrypted SSD.
And over time the SSD would become slower and slower and slower.
Is there any way we could mitigate this? As I’m running MicroOS on my business laptop I feel really weird having client data on my machine. I’ve already changed to Leap/SLED/Tumbleweed because of this, but MicroOS always lures me back in, and then I feel weird about it.
Best, Syds
On Mon, 2021-08-02 at 21:34 +0200, Syds Bearda wrote:
Hi all,
I’ve been thinking about a while now about a conversation I had with Richard about encryption with MicroOS with a SSD.
Due to the immutable nature of MicroOS trimming would not work on a encrypted SSD.
And over time the SSD would become slower and slower and slower.
Is there any way we could mitigate this? As I’m running MicroOS on my business laptop I feel really weird having client data on my machine. I’ve already changed to Leap/SLED/Tumbleweed because of this, but MicroOS always lures me back in, and then I feel weird about it.
Best, Syds
Trimming can work on an encrypted SSD cat /etc/crypttab cr_ata-LITEON_CV3-8D512-41_SATA_512GB_SED_TW0MN0K7LOH006CM02TL-part2 /dev/disk/by-id/ata-LITEON_CV3-8D512- 41_SATA_512GB_SED_TW0MN0K7LOH006CM02TL-part2 none discard https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_f...) Works' a treat, at the cost of some security implications - https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html So it can never be a default, but can easily be chosen. Also none of this is anything to do with MicroOS or immutable systems in general and apply equally to any encrypted Tumbleweed/Leap. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Mon, Aug 2, 2021, at 22:07, Richard Brown wrote:
On Mon, 2021-08-02 at 21:34 +0200, Syds Bearda wrote:
Hi all,
I’ve been thinking about a while now about a conversation I had with Richard about encryption with MicroOS with a SSD.
Due to the immutable nature of MicroOS trimming would not work on a encrypted SSD.
And over time the SSD would become slower and slower and slower.
Is there any way we could mitigate this? As I’m running MicroOS on my business laptop I feel really weird having client data on my machine. I’ve already changed to Leap/SLED/Tumbleweed because of this, but MicroOS always lures me back in, and then I feel weird about it.
Best, Syds
Trimming can work on an encrypted SSD
cat /etc/crypttab cr_ata-LITEON_CV3-8D512-41_SATA_512GB_SED_TW0MN0K7LOH006CM02TL-part2 /dev/disk/by-id/ata-LITEON_CV3-8D512- 41_SATA_512GB_SED_TW0MN0K7LOH006CM02TL-part2 none discard
https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_f...)
Works' a treat, at the cost of some security implications - https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
So it can never be a default, but can easily be chosen.
Also none of this is anything to do with MicroOS or immutable systems in general and apply equally to any encrypted Tumbleweed/Leap.
I totally remember our conversation different, happy to hear it does work, I’ll go reinstall tomorrow with encryption enabled. Was the security implication the reason you said it shouldn’t be used as I remember the slower (and therefore unusable) over time clearly.. To be honest you were working with SUSE week and started to write the new first boot script which enables flathub for gnome. Best, Syds
Regards,
-- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Mon, Aug 02, Syds Bearda wrote:
Hi all,
I’ve been thinking about a while now about a conversation I had with Richard about encryption with MicroOS with a SSD.
Due to the immutable nature of MicroOS trimming would not work on a encrypted SSD.
Why not?
And over time the SSD would become slower and slower and slower.
Is there any way we could mitigate this? As I’m running MicroOS on my business laptop I feel really weird having client data on my machine. I’ve already changed to Leap/SLED/Tumbleweed because of this, but MicroOS always lures me back in, and then I feel weird about it.
It would be helpful if you would describe your exact problem, means what did you do and what fails with which error message. fstrim works on MicroOS, and if configured correctly I fail do see a reason why it should not work with an encrypted SSD. All layers are able to pass the trim command down to the SSD. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
participants (4)
-
contact＠ffreitas.io -
Richard Brown -
Syds Bearda -
Thorsten Kukuk