Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Mohu tomu EXT4 šifrování rozumět tak, že třeba distribuce typu Ubuntu budou při instalaci nabízet rovnou šifrování celého disku (všech oddílů?) místo současného šifrování /home ?
Tak ext4 je souborovy system, takze jenom jedna partisna ne? Patrne nejaky prvotni pokus o bitlocker, hadam ale, ze bez podpory UEFI a HW .....
ext4 mozes mat na viacerich particiach. Pripadne pouzit LVM a LUKS (neviem ci podporuje TPM).
A rikam, ze nemuze byt na vice? Clovek nademnou se ptal na cely disk, ne partisny....
Netuším, co bude nabízet Ubuntu, ale šifrování celého disku nebo všech oddílů už se taky umí hodně dlouho. Dnes je "standard" LUKS (asi 11 let), ale nikomu nebránilo si zašifrovat blokové zařízení (cryptoloop) už dávno před tím.
V ext4 s podporou šifrování se to má tak, že si vytvoříte adresář, o kterém prohlásíte, že má být zašifrovaný a dáte mu master key. Z tohoto klíče se potom vytváří klíče pro šifrování jednotlivých souborů (objektů) ukládané do tohoto stromu. Takže různé části fs můžete mít zašifrované jinými klíči.
Tedy už nebude potřeba to, co dělají některé distribuce, tedy že si nad uživatelových home vytvoří další fs (fuse) a do spodního fs jdou soubory šifrované tou mezivrstvou.
Všechny možnosti fungují z hlediska userspace naprosto transparentně, teď se někdo do svého fs rozhodl implementovat podporu šifrování. (Nehodí se jim šifrovat celé blokové zařízení, ani si vytvořit fs nad fs.)
Osobně se mi (architektonicky) nejvíce líbí šifrovat blokové zařízení, ničemu nebrání dělat LV per uživatele a zašifrovat to klíčem derivovaným z jeho hesla (nebo jiné identifikace). Funguje to pro všechny FS a dokonce to funguje, i když tam žádný fs není (blokové zařízení je taky soubor, takže aplikaci nic nebrání požívat celý disk jako jeden soubor). Dělat šifrování na vyšších vrstvách se hodí ve speciálních případech. Jestli je to zrovna tento případ, nevím. Ale od toho je to OSS, ať si každý dělá patche jaké chce. Já je používat nemusím.
Sifrovani blokoveho zarizeni je sice pohodlne a transparentni, ale z kryptografickeho hlediska nesikovne. Odolnost sifer totiz prudce klesa kdyz pouzivas stejny klic na velke mnozstvi dat. Normalne se to resi tak, ze ke klici pridas nejaky nahodny "seed", jenze pri sifrovani blokoveho zarizeni ten seed neni kam ulozit, protoze sifrujes 1:1. Navic neni ani kam ulozit kontrolni soucet pro overeni, ze jsi desifroval spravne. Chtelo by to ke kazdemu rekneme 8kb bloku nekam ulozit 8b seed a 8b kontrolni soucet, jenze to proste blokove udelat nejde, protoze potrebujes zarovnani na 4kb na vstupu i vystupu. Kdyz to pritom udelas v ramci filesystemu, nemas s tim zadny problem, protoze to muzes ulozit do inode.
"MD RAID dostal zase prozměnu RAID 5/6"
Co se tím myslí? Ten má podporu R 5/6 déle než 17 let. V LKML jsem zmínku o MD (ani DM, tam by to dávalo o něco větší smysl) pro release 4.1 nenašel.
http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04389.html
- RAID5/6 can now batch multiple (4K wide) stripe_heads so as to
handle a full (chunk wide) stripe as a single unit.
- RAID6 can now perform read-modify-write cycles which should
help performance on larger arrays: 6 or more devices.
- RAID5/6 stripe cache now grows and shrinks dynamically. The value
set is used as a minimum.
Takže drobné optimalizace.
K DM by me hlavne zajimalo, kdy bude k dispozici skutecny load-balancing pri cteni z RAID 1.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.