Dotaz: šifrovaný disk pro notebook se swapem pro hibernaci

[lertimir]

zdravím. budu instalovat nový notebook viz nadpis a rozvažuji mezi dvěmi konfiguracemi boot by byl efi->GRUB, a zašifrované vše včetně /boot oddělený oddíl na swap zašifrovaný se stejnými hesly (heslo zadávám a klič v initramfs v šifrovaném boot) jako jako root

nvme0n1
     p1
        EFI
     p2
        LUKS
            swap
     p3
        LUKS
            root - btrfs

nebo obojí swap a root mít v LVM

nvme0n1
    p1
        EFI
    p2
        LUKS
            LVM
                swap
                root - btrfs

manipulaci s velikostí swapu nebude potřeba.

Co si myslíte, že je lepší?

Odpovědi

[Peter Golis]

Je to jedno, pokiaľ tam nebude rozumne nastavený secure boot aby niekto nepodhodil odchytenie hesla.

PS: Podobnú vec ako je v prvej voľbe som teraz niekedy riešil, ale na dvoch fyzických diskoch v NB zakryptovaných pomocou LUKS a spojených do jednej VG v ktorej je viacero LV. Zadávanie hesla mám riešené cez caching, aby ho to nepýtalo 2x. Chcel som to hodiť aj do blogu, ale teraz nevyšiel čas.

[lertimir]

Zatím jsem neviděl notebok s vahou pod 1,5 kg s dvěma disky. Ale jestli je tak se rád poučím. BTRFS RAID1 bych měl radeji.

[Peter Golis]

Jedná sa o NB v ktorom som vymenil optickú mechaniku za šachtu na pevný disk, aj s SSD. To už vyšlo z módy.

[lertimir]

Něco kde je optická mechanika je tak 3 kg.

[k3dAR]

T420s = 1.67kg, misto dvd mechaniky lze dat "suplik" na druhej 2.5" disk (nebo druhou baterii)...
+ krome interniho 2.5" disku, lze dat jeste mSATA SSD

[k3dAR]

pouzivam vsude druhou variantu(resp. s root-ext4 + LV boot), akorat bacha, jestli pouzivas *buntu (nevim jak to maj jinde), tak distribucni jadro se SecureBoot (umyslne) nedovoli (nesmyslne) hibernaci, udajne kvuli bezpecnosti, takze kde mam SecureBoot a chci hiernovat davam ubuntu-mainlne jadro v kterem to blokovane neni...
a druha vec, se SecureBoot misto GRUB/LUKS zavadece doporucuju sicherboot+vlastni_klice

[Peter Golis]

... *buntu ... distribucni jadro se SecureBoot (umyslne) nedovoli (nesmyslne) hibernaci, udajne kvuli bezpecnosti

Toto by ma zaujímalo. Vzhľadom na moje lenivé plány som si to nasimuloval v 64Bit VM s UEFI OVMF na Ubuntu 20.04, a normálne mi to s jadrom linux-signed-generic/now 5.3.0.24.28 hibernuje. Jediný zádrhel bol vo veľkosti SWAP. Pri využití východzej inštalácie (kryptovaný disk s LUKS) robí Ubuntu zásadne len 1G SWAP, a do toho sa pri bežnom použití desktopu nedá hibernovať.

Keď to budem robiť na ostro, tak mám očakávať nejaké problémy ktoré sa nedajú nasimulovať?

PS: Tie plamenné diskusie že pri LUKS nie je dobré hibernovať lebo medveď som čítal, ale nikde nemali žiaden logický argument.

[k3dAR]

hele, nevim zda sem to zkousel s 5.3(=18.04.4), ale s 5.0(=18.04.3) to urcite jeste neslo, za hodku budu u NB kde to mam a overim...
jinak ve virtualu si mel OVMF se SecureBoot a zaplej?
ad vychozi install, nevim jak v 20.04 a nejsem si teda jist ani s 18.04 jak FDE na UEFI, ale ja si disk pripravim predem abych mel i /boot sifrovanej, minimalne na legacy default install delal boot mimo, i kdyz stacilo aby instalator pridal 1 parametr pro grub a 1 radek pro auto druhe odemceni klicem do initramfs...

jj, take sem toho "medveda" nechapal, argument byl ze to neni bezpecne, ale pritom zacatek boot pri start i probuzeni je naprosto totoznej, jedinej rozdil je v tom, zda initramdisk z LUKS swap obnovi stav nebo ne, ale to uz probiha samozrejme az po odemceni LUKS...

[Peter Golis]

Ten zbytočný limit 1G na SWAP pri wizzarde je už niekoľko rokov. Z môjho pohľadu sa jedná o jedinú prekážku pre hibernáciu (okrem nekompatibility ovládačov HW, čo sa dá forsnúť).

OVMF som mal síce zapnuté, ale služby TPM sa mi nechcelo inštalovať a passthrough do fyzického TPM som nechcel použiť. Takže SecureBoot sa tváril ako zapnutý, ale bol neaktívny.

Ohľadne tej akoby nebezpečnosti hibernácie, tak som čítal nesprávne argumenty že hibernácia do kryptovaného swapu je moźná, ale obnova už nie. Najmä ak sa obnovuje až po odomknutí LUKS a detekcii LVM z initrd kde je ten swap už čitateľný. Boli tam aj podobné veci ktoré sa počas histórie zneplatnili.

Existuje jediný argument ktorý by som zobral. Teda ak sa použijú cudzie kľúče (napríklad od MS ktoré tam boli pchané kvôli dualbootu), tak je toto celé len placebo. A tie kľúče sú posvätené pri všetkých distribúciách. Z tohot sa dá utiecť jedine cez niečo ako spomínaný sicherboot s vlastnými kľúčami. To mám na pláne neskôr, ale bez záväzkov.

[k3dAR]

tak overeni az ted, Xubuntu 18.04.4, FDE/LUKS, aktualni jadro, zaplej SecureBoot a pri:

systemctl hibernate

dostanu hlasku:

"failed to hibernate system via logind: sleep verb not supported"

nejake info k tomu:
https://askubuntu.com/a/1125038
https://bugzilla.redhat.com/show_bug.cgi?id=1467045
ocividne tvurce patche netusi o tom ze by swap mohl byl na LUKS kde ta moznost kompromitovani swap proste neni...

[Peter Golis]

Presne takú chybu som dostával aj ja, až do doby kým som nezväčšil SWAP na rozumnú veľkosť a nepoužil novšie jadro. Viac som sa s tým nekašľal.

To odopretie hibernácie na zašifrovaný swap je nezmysel. Oveľa väčší bezpečnostný problém je Sleep, aj s Cold Swap RAM bez kompletnej enkrypcie RAM ktorá sa až teraz niekedy dostáva do HW.

[k3dAR]

pokus novejsim jadrem myslis mimo systemovej repositar, tak jak sem psal jinde s Ubuntu MainlineBuld to chodi, tam ten patch neni protoze Linus ho neprijal, a nemuselo jit o novejsi, tehdy sem to zkousel s totoznou verzi jadra jako s v repositari...
ohledne velikosti SWAP, vcera sem to zkousel na novem stroji kde mam zatim 4GB RAM, ale SWAP udelal 18GB
prave ten patch nevnima moznej LUKS, a ignoruje to ze pri suspend do ram, zustava pripadnej LUKS odemcenej, takze narozdil od bezpecne SecureBoot hibernace z/do LUKS swap, muze utocnik zneuzit pripadne chyby lock/screensaver reseni pri resume from sleep a dostal by se k odemcenemu LUKS...

[k3dAR]

potvrzuji, i na tomto stroji, stacilo nainstalovat ubuntu mainline jadro, restartovat a hibernace jde, v obou pripadech slo o zaplej SecureBoot, z EFI smazane default klice, sicherboot a nahrane vlastni klice (nejdriv sem zkousel s SB on, default klicema a Grub)

[k3dAR]

btw: ten patch je v 20.04 trochu jinak nez v bionic ale predpokladam/obavamse ze je to jen sledovani prejmenovane ci rozsirene "detekce"

[Peter Golis]

Ten SWAP 18G si si ku 4G vyrobil sám?

[k3dAR]

jj, rucne - protoze pocital ze tam vrazim 16GB RAM

overeno na stejnem stroji Xubuntu 20.04-Beta s EFI default klice, SB=on + default jadro = hibernace nejde

[Peter Golis]

No, tak ja zatiaľ nemám voľný fyzický HW na odladenie. A virt-manager má síce možnosť práce so swtpm, ale nerád riešim custom made balíčky mimo VM. Vo fyzickej mašine sa veci z mimo repozitárov odstraňujú a hlavne udržiavajú horšie.

[k3dAR]

chces vyuzivat TPM na automaticke odemceni? pokud ne, neni treba pro ciste UEFI+SB+DefaultKlice, nezkousel sem zda jde pouzit misto default vlastni, ale ani to by nemelo snad vyzadovat TPM (na fyzickem netreba)

[Peter Golis]

Chcem použiť TPM na uloženie mojich kľúčov pre Secure Boot.

[lertimir]

Bude to na Archu. Podívám se na ten sicherboot.

[Andrej]

Co si myslíte, že je lepší?

Co je lepší — bláto nebo louže? Obojí je špatně.

Swap má být soubor, nikoliv oddíl. Včetně hibernace na Btrfs.

Swap tedy není třeba řešit při inicializaci disku. Lze ho přidávat nebo odebírat kdykoliv, podle potřeby a (hlavně) bez zbytečného dělení diskového prostoru.

[k3dAR]

uniklo ti ze s LVM lze swap pridavat/odebirat take podle potreby a (hlavne) bez zbytecneho deleni diskoveho prostoru...

[Peter Golis]

Asi vychádzal z BSD kde SWAP na SSD musí byť v súbore, inak na ňom nezbehne TRIM. Alebo vychádzal zo starých čias, kedy mohol byť Linuxový SWAP v deravom (sparse) súbore. Už dávno nemôže, a musí to byť prealokované.

[Andrej]

Ani jedna z hypotéz neplatí.

Vycházel jsem z dnešní linuxové reality.

[Peter Golis]

Zväčšenie stávajúcej LV alebo vytvorenie novej LV je rovnako zložité ako zväčšenie stávajúceho súboru alebo vytvorenie nového súboru. A to pri zachovaní rovnakých predpokladov, PV pre VG musí mať trocha voľného miesta, rovnako ako FS musí mať trocha voľného miesta v prípade práce so súbormi.

[Andrej]

Tobě taky uniklo pár podstatných věcí:

• LVM je dost tlustá a (v dobách Btrfs) zbytečná vrstva abstrakce navíc. Udržovat ji jen kvůli (zbytečnému) oddílu pro (zbytečný) swap pro (zbytečnou) hibernaci je overkill.
• Je nesrovnatelně snazší prostě přidat soubor, než
  • zmenšit souborový systém,
  • zmenšit příslušný LVM oddíl,
  • vytvořit nový LVM oddíl pro swap.
  Pro odstranění nebo změnu velikosti swapu platí přibližně totéž.

[N]

Souhlasim s timto nazorem, ackoliv nepouzivam LVM ani BTRFS ani LUKS ale jen Ubuntu s vychozim swap souborem a i hibernuju s pomoci tohoto postupu

[k3dAR]

# zmenseni LVM i souboroveho systemu:
lvresize --size -1GiB /dev/vg/lv --resize-fs

# odstraneni LV swap
lvremove /dev/vg/swap

ad zbytecna hibernace, ty mas opravdu vychlastanej mozek... aby te fakta mene zatezovala: jak uspis do ram:

1. aby nezustal odemcenej LUKS
2. aby to slo probudit za pul roku bez pripojeneho adapteru
3. vypnuti a znovu pousteni vsech aplikaci neni odpoved

[lertimir]

Máš vyzkoušeno, že swapfile na btrfs je opravdu stabilní záležitost včetně hibernace???

Argumentaci sice rozumím, ale na druhou stranu mi nepřipadá zas tak špatné prostě rezervovat 8 nebo 16G na hibernaci. Stejně tlačit SSD někde k hranicím zaplněnosti je zbytečné, a jestli mám obsazenost 60% nebo 63% nemá tak velký rozdíl na práci toho SSD. Také nejsem si jist jestli je rychlostně jedno, jestli je swap oddíl nebo soubor, protože v oddílu je alokace na sektory jasná, kdežto v souboru musím zjistit z alokačních struktur, kudy soubor pokračuje v sektorech na disku. (ale chápu, že alokační struktury budou asi plně v paměti). A také chápu, že pro NVME je překlad sektorů do buněk stejně ještě jedna vrstva.

A jestli je hibernace zbytečná. No mohu buď notebook startovat z nuly. (což je rychlejší než z hibernace, ale zapomenu stav rozpracovanosti) nebo mohu jen ho uspávat, když chci zachovat rozpracovaný stav, (a to z hlediska bezpečnosti, když se k notebooku někdo dostane, mám za o dost horší, než vypnutý notebook s obrazem paměti ve swapu.)

[Josef Kufner]

Varianta s LUKS je default v Debianu. Ta první odstraní potřebu LVM, ale musíš pořešit bezpečné odemykání dvou oddílů (možností je povícero a je to jen trocha konfigurace). Overhead LVM v tomto případě je zanedbatelný. Použij to, co se ti líbí víc.

[lertimir]

Podívám se na ten sicherboot. více disků mi odemyká sd-encrypt. Potřebuji to i jinde na rootový btrfs RAID1.