Új hozzászólás Aktív témák

• #8926 attilav2 őstag BoB #8920

  Új Válasz 2024-09-21 10:40:16 #8926

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  attilav2

  őstag

  válasz BoB #8920 üzenetére

  Ezt találtam az opal-al megtámogatott LUKS-ról:
  https://www.phoronix.com/news/Cryptsetup-Lands-OPAL-Encrypt

  https://www.reddit.com/r/linuxquestions/comments/1bm7434/does_cryptsetup_270s_opal_support_work_on/?rdt=60256

  https://rahul.amaram.name/blog/2024/07/09/debian-on-self-encrypting-drive-using-cryptsetup-opal-support

  Ezek alapján sima liba elvileg, sokkal kevesebb szívással jár mint a sima sed hw titkosítás.

• #8925 attilav2 őstag BoB #8920

  Új Válasz 2024-09-21 10:27:10 #8925

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  attilav2

  őstag

  válasz BoB #8920 üzenetére

  Írd le a lépéseket hogy kapcsoltad be a hardveres titkosítást az ssd-n. Próbáltam google fordítóval értelmezni az arch wiki vonatkozó részeit de nekem elég bonyolultnak tűnik, meg lehet a fordítás sem az igazi. Kell valami pre boot authorization image-t generálni vagy letölteni valahonnan, lehet hogy az alaplap biosának is támogatnia kell a dolgot mert különben nem tudok bootolni a hw titkosított drive-ról, ennyit silabizáltam ki. A sedutil-cli --scan azt mondja az sn580 támogatja az opal-t. A LUKS elméletileg tudja használni a hardveres titkosítást(vagy legalábbis részben arra támaszkodni), ha a LUKS konténert a cryptsetup --hw-opal-only kapcsolóval hozom létre, ez nekem egyszerűbb lenne mint a meghajtó sima lejelszavazása. A kérdés az ha a LUKS-on keresztül opal-al használom a hw titkosítást akkor ugyanúgy lejelszavazódik a meghajtó mintha simán sed-et használnék, és támogatnia kell a biosnak a feloldást, meg pba image kell, vagy hogy van ez ? Mert a wiki azt írja hogy a LUKS fejléc fogja feloldani a hardveres titkosítást, tehát elvileg a LUKS ugyanúgy bekéri a jelszót mint eddig. Azt is írja a wiki hogyha opal-al megtámogatott LUKS titkosítást használok akkor a trim engedélyezve lesz alapból, és elméletileg így nem érintett az adatszivárgásban. A wiki szerint komolyabb adatszivárgás szoftveres titkosításnál trim mellett akkor lehet ha a cryptsetup 1.6.0 vagy alacsonyabb verzióval lett létrehozva a konténer, ez esetemben nem áll fenn, bőven magasabb verzióval hoztam létre.

• #8922 attilav2 őstag BoB #8920

  Új Válasz 2024-09-17 17:01:21 #8922

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  attilav2

  őstag

  válasz BoB #8920 üzenetére

  Igazad van, amíg a systemd-boot konfigban nem engedélyeztem hogy a LUKS engedje át a discard-ot, addig az fstrim -v / parancsra azt írta nem támogatott. Amint engedélyeztem reboot után működött az fstrim, kb 300gb-ot trimmelt. sd-encrypt -et használok a rendszerpartíció felcsatolásához, ilyenkor a /boot/loader/entries/arch.conf a következőképp néz ki:
  title Arch Linux NVME
  linux /vmlinuz-linux
  initrd /intel-ucode.img
  initrd /initramfs-linux.img
  options rd.luks.name=UUID=sn580_cryptroot root=/dev/mapper/sn580_cryptroot rw
  options rd.luks.options=UUID=discard

  Az UUID helyére a rendszerpartíció UUID-je kell. Az utolsó sor engedélyezi a trim-et.
  Az sn580_cryptroot helyére lehet tetszőleges nevet írni, praktikusan a meghajtónk típusát.

  Kísérletképp az fstab-ba beraktam a discard-ot, kíváncsi vagyok néhány hét múlva belassul e a rendszer, ha igen akkor marad a periodic trim mint lehetőség. A crucial mx500-on és a samsung QVO 860-on gyakorlatilag nem nagyon működött a continous trim, az fstrim-el indőnként be kellett segíteni. Van egy másik gépbe adata sp600-on(sata ez is) Arch Luks-al, az még nem lassult be, pedig kb egy éve használom, lehet az a meghajtó jobban komálja a linux alatti folyamatos trim-et.

Új hozzászólás Aktív témák