ugrás a tartalomhoz

dm-crypt - btrfs - raid1

inf · 2018. Jan. 15. (H), 18.30
Foglalkozott már köztetek valaki dm-crypt-el?

Szeretném betenni btrfs - raid1 alá, viszont van egy olyan problémám vele, hogy mindkét meghajtót eltérő módon titkosítaná, mert a raid1 a felette lévő szinten van ebben az esetben. Ez többlet terheléssel járna a gép szempontjából, illetve még tovább lassítaná az IO-t. Létezik bármilyen megoldás ezzel a szoftver raid-el arra, hogy csak egyféleképp titkosítson a dm-crypt és mindkét meghajtóra ugyanaz menjen rá?
‹ Spectre, Meltdown port scan ›
 ■
1

Közben utánajártam, jelenleg

inf · 2018. Jan. 16. (K), 14.49
Közben utánajártam, jelenleg nem megoldható, és valszeg még évek, mire lesz titkosítás támogatása a btrfs-nek, szóval most csak ez a megoldás létezik. A másik lehetőség, hogy áttérek zfs-re, ami támogatja a titkosítást, viszont sokkal több memóriát zabál. Azt hiszem csinálni fogok benchmarkot mindkettőre, illetve nézni fogom a fogyasztást, memória, cpu terhelést, aztán utána döntök.
4

Azt hiszem, dedup nélkül a

hóhér · 2018. Jan. 17. (Sze), 19.24
Azt hiszem, dedup nélkül a zfs-nek sincs extrém memóriaigénye.
5

Én olyasmit olvastam, hogy az

inf · 2018. Jan. 17. (Sze), 20.15
Én olyasmit olvastam, hogy az integritás fenntartásához kell a sok memória neki. Mondjuk ettől még igazad lehet, hogy ennek köze van a dedup használatához. Nekem 1TB körüli hely elég jelenleg, ha az elfogy, akkor csapok még hozzá új lemezeket, szóval a dedup szerintem nem szempont, nincs szó hatalmas adat mennyiségről. Kitalálok valami benchmarkot i/o sebességre, cpu terhelésre, memória fogyasztásra, aztán kipróbálom mindkettőt. A cpu támogatja az aes-ni-t, de így sem számítok 100MB/s-nál jóval nagyobb sebességre az SSD-n. A gigabites hálóhoz annyi elég is, ha meg később felfejlesztem 2 vagy 5g-re, akkor elgondolkodok rajta, hogy kell e nekem ez a titkosítás.
8

Ja más is írta közben, hogy

inf · 2018. Jan. 18. (Cs), 02.51
Ja más is írta közben, hogy dedup nélkül nem zabál annyit a zfs.
2

Hol bukik a dolog?

vbence · 2018. Jan. 16. (K), 21.58
Gondolom LVM-et hazsnálsz. Miért nem a raid által adott block device-t dm-crypteled?
3

Nem terveztem, hogy lvm-et

inf · 2018. Jan. 17. (Sze), 00.32
Nem terveztem, hogy lvm-et használok, amennyire én tudom a btrfs nagyjából ugyanazokat a funkciókat ellátja, bár elég kezdő vagyok a témában. A raid-et is a btrfs csinálja egyébként, és szükséges is, hogy így legyen, mert csak így fogja automatikusan javítani, ha nem stimmel a crc checksum egy blokkra valami miatt. Amúgy annyi az előnye a hagyományos raid-el szemben, hogyha egy blokkot nem tud javítani, akkor csak az ahhoz a blokkhoz tartozó fájlok vesznek el, nem az egész array megy a levesbe.

szerk:
Lehet, hogy amit írtam csak raid5/6 esetén érvényes, és raid1-nél normál raid is vissza tudja állítani a nem sérült fájlokat.
6

LVM

vbence · 2018. Jan. 17. (Sze), 22.46
Az LVM-ből elsősorban azt használom, hogy segít összevissza bármit bármibe tenni, esetleg később változtatni, újragondolni, akkor is megéri, ha nem használod az advancedebb funckiókat (snapshot).

A linux kernel szoftveres raidje elég nagy múltú, sok helyen használt szoftver, vannak akik néhány harverraiddel szemben is erre támaszkodnak pont a sok elérhető recovery opció miatt, én nem hallottam ezeket az aggályokat, linkelhetnéd ha kéznél van a forrás.
7

Nincs kéznél, már elég régen

inf · 2018. Jan. 18. (Cs), 02.50
Nincs kéznél, már elég régen olvastam. Az rémlik, hogy hagyományos raid-nél ha rebuild-nél bad block-ra fut még egy lemez, akkor minden elveszik, ezeknél a fájlrendszerhez kötött raid-eknél meg csak az érintett fájlok vesznek el, az adat nagyrésze ilyenkor is megmarad. Ezen kívül a raid össze van kötve a checksum ellenőrzéssel is, szóval az se fordulhat elő, hogy eltérő érték van a két lemezen, és a rosszal írja felül a jót. Nem tudom ezek hagyományos raid-nél mennyire megoldhatóak, nincs vele tapasztalatom, és nem is igazán tudom ezeket a scenario-kat hogyan lehetne tesztelni.

Egyébként a btrfs-nél a raid1 nem egészen mirror-t jelent, felosztja 1GB-os chunk-okra az adatot, és szétosztja a lemezek között a chunk-okat úgy, hogy minden chunk-ról legyen egy másolat egy másik lemezen. Szóval bármikor hozzácsaphatok még egy lemezt, illetve akár el is lehet venni belőle lemezt, ha van elég szabad hely és utána rebuild-elek. Ezen felül a metadata-ról több másolat készül mindegyik lemezen szétosztva a lemez teljes szélességében, szóval szinte nulla az esélye, hogy eltörjön a fájlrendszer vagy egy checksum hibás legyen. Ennyit a reklámról. :D

Találtam közben egy összehasonlítást is, ezek szerint az mdraid gyorsabb és több másolatot tud csinálni az adatról is, viszont data integrity szempontjából erősen alulmarad. Azt hiszem ez volt a döntő szempont a btrfs vagy zfs mellett szemben a hagyományos megoldással. A btrfs-t végül azért választottam, mert egyelőre nincs túl sok memória a gépben, illetve mert bekerült a Linux kernelbe. Egyébként azt mondják, hogy a zfs jobb.

Van még annyi hátránya a btrfs-nek pl ext4-el vagy akár zfs-el szemben, hogy a copy on write miatt lassúak a virtuális gépek. Nem tudom ez docker container-ekre mennyire igaz. Viszont azt olvastam most, hogy kikapcsolható ez a feature arra a subvolume-ra, amin a vm cuccai vannak, szóval elvileg ez se olyan nagy gond, ha odafigyel rá az ember.
9

KI

Hidvégi Gábor · 2018. Jan. 18. (Cs), 10.04
Az emberek milliárdjának van arra igénye, hogy egyedi legyen, hogy kitűnjön a sok közül. Ehhez mindenféle fémdarabokat csippentenek a ide-oda, a bőrfelületüket nonfiguratív tetoválásokkal rajzolják tele, drága ruhákat aggatnak magukra, luxusautókat és -mobiltelefonokat használnak, a világgazdaságban sokezer milliárd dolláros üzletek köttetnek e cél érdekében.

Neked meg csak elég, hogy leírsz két-három szót, és már a címből tudni lehet, hogy inf3rno az elkövető.

Jól becsüld meg magad, mert nincs még egy ilyen a világon : )
10

:D

inf · 2018. Jan. 18. (Cs), 15.46
:D
11

dehogynincs... :)

hóhér · 2018. Jan. 18. (Cs), 20.10
Google: hajbazer poliverzum site:hup.hu
*ssy site:forum.index.hu
;)
Bocs. :D
12

Ez a hajbazer szimpatikus. :D

inf · 2018. Jan. 18. (Cs), 20.43
Ez a hajbazer szimpatikus. :D Találtam is vicces dolgokat: link, az mondjuk nem jött le, hogy miért szívatják. Kb. odáig jutottam, hogy nem ért egyet azzal, hogy teljesen jól működő gépeket dobnak ki, csak mert kijött az újabb változat.

szerk:
Amúgy ezzel kapcsolatban teljesen igaza van sztem. link Pont most vesztett pert az Apple, mert szoftveresen visszalassította a régebbi iphone-okat. link Szerintük azért, mert gyengült bennük az aksi, és hamarabb merülnének, valószínűleg az igazság meg az, hogyha belassul a cucc, akkor inkább veszik meg az emberek az újat, mert az tuti gyorsabb. Alapvetően gusztustalannak tartom ezt a tervezett elavulást én is. :D

szerk2:
Egyébként röhögni fogtok, utoljára az XP-ben sikerült normálisan kikapcsolni a mouseaccel-t, azóta még az accelfix-ek sem működnek. Egyedül a Linux, amiben nem tapasztalom. :D Régen minden jobb volt. :D
14

Nem mondom, hogy nincs igaza

hóhér · 2018. Jan. 19. (P), 13.36
Nem mondom, hogy nincs igaza sok dologban. Viszont helyenként azért hajmeresztő a marhasága, de nem is ez volt a lényeg.
Gábor azt írta, egyedi vagy abban, hogy azonnal felismerhető a téma, amit indítasz. Csak hoztam pár példát, hogy nem annyira. ;)
16

Jaja. Csak hogy visszatérjünk

inf · 2018. Jan. 19. (P), 17.32
Jaja. Csak hogy visszatérjünk az eredeti témához, nagy valószínűséggel a zfs mellett fogok maradni, mert abba be van építve a titkosítás, szóval nem használ dupla processzor időt emiatt feleslegesen, és elvileg minden mást is tud, amit a btrfs. Ha lesz egy kis időm, akkor megcsinálom dm-crypt + btrfs-re is a benchmark-okat, meg lvm + md-raid + dm-crypt + ext4-re is, bár az jóval kevésbé törődik az adatok integritásával. Elvileg a FIO az erre alkalmas benchmark, bár nem tudom, hogy hogyan tudom rávenni benchmark pontok helyett, hogy MB/s értéket adjon. Ha sehogy, akkor kipróbálom, hogy néhány GB random memóriában tárolt adatot milyen sebességgel ír ki a meghajtóra vagy olvas be onnan a memóriába. Ezen felül a tesztek közben monitorozni fogom a processzor és memória használatot is. Nagyjából ez a terv, szerint összeszórok egy blog bejegyzést is, ha kész vagyok, úgyis már lassan egy éve, hogy oda nem írtam semmit.
13

Hajbazer

Hidvégi Gábor · 2018. Jan. 19. (P), 10.20
Amivel Hajbazer kritizálja a szoftverfejlesztőket, szinte mindenben igaza van.
15

Hááááát... de ahogy

hóhér · 2018. Jan. 19. (P), 13.38
Hááááát... de ahogy inf3rnonak is írtam, nem ez volt a lényeg, hanem az, hogy szinte azonnal felismerhető, ha az említettek egyike indít topikot.
:)
17

OFF - Kritika

Pepita · 2018. Jan. 20. (Szo), 09.52
Kritizálni mindenkit lehet, csak nem mindegy, hogy inkább kritizálsz és csak azt hangoztatod, hogy mi a rossz (és miért), vagy inkább példát mutatsz, hogy mi a jó (jobb) és miért érdemesebb arra menni...
18

Hahaha, azt hiszem meg is

inf · 2018. Jan. 21. (V), 02.08
Hahaha, azt hiszem meg is találtam, ami nekem kell: https://github.com/buty4649/fio-cdm. Betegek ezek a japánok. :D Még csak a workload-on sem kell agyalnom, megcsinálták egy az egyben ugyanazt fio-ban, mint amit a crystaldiskmark csinál.
Elvileg nagyobb buffer méret kell, mint ebben a seq r/w-re használtak, legalábbis máshol azt írják, hogy 1m helyett 12m hozza nagyjából azokat a számokat, mint a CDM. Azt hiszem ez a szekvenciális írás, olvasás random adattal, ami nekem kell, nagyjából ezen le tudom mérni, hogy mi a max sebessége a titkosított raid-es cuccnak, aztán mérlegelni, hogy megéri e.
19

Közben kiderült még annyi

inf · 2018. Jan. 22. (H), 23.44
Közben kiderült még annyi fejlemény, hogy ext4 + md-raid + dm-integrity -vel úgy tűnik semmiképp nem érdemes megoldani az integritás védelmet, legalábbis a dm integrity dokumentációjában egyértelműen azt írják, hogy data mode-ban csinálják a journaling-ot ordered mode helyett, ami gyakorlatilag azt jelenti, hogy minden adat kétszer kerül kiírásra a lemezre. link Nem tudom, hogy a valóság mit takar, még az is lehet, hogy a dokumentáció elavult. Igazából nem is nagyon van hol utánakérdezni a dolognak, gitter-en nincs fent a repo, issue-t nem lehet beküldeni, nyilván csurig lenne a Linux issue-kkal, levlistát meg most nincs energiám keresni hozzá. Ettől függetlenül azért teszelni fogom azt a megoldást is. Egyelőre még van egy csomó cikk, amit megnyitottam és át kell rágnom magam rajta, utána kezdem csak a teszteléseket.
20

A btrfs is kapott egy újabb

inf · 2018. Jan. 24. (Sze), 07.13
A btrfs is kapott egy fekete pontot, nem lehet a swap-et rátenni, nem támogatja sem a partíciót sem a swap fájlt. Ha már ECC-t veszek a gépbe, hogy a memória integritása is biztosítva legyen, akkor azért problémás, hogy olyan swapbe kell kiírni aminél ez nincs meg. A zfs-ről ezzel szemben azt írják, hogy nincs ilyen probléma. Ami még felmerült, hogy esetleg tömörített ramdisk-re ki lehet írni a swap-et, viszont én az asztali gépemből kiindulva nem szívesen vagyok swap nélkül. Omlott már össze azért a rendszer, mert elfogyott a memória, és a szervernél ezt nem szívesen kockáztatom meg, mert rossz esetben az egész adatbázis megy a levesbe. Lassan már össze kell írnom a pros/cons-t is az egyes megoldásoknál, körvonalazódik egy cikk/blog bejegyzés.

Egyébként beveszem a tesztbe az ecryptfs-t is. Annak az a hátránya, hogy baromi lassú az írás (akár 10x gyorsabb is lehet a dm-crypt), viszont minden fájlt egyesével titkosít le, akár külön kulccsal is, és a backup készítésénél sem kell kikódolni a fájlokat. Ezen kívül megnézem a zfs-t deduppal és anélkül is, hogy mennyi memóriát eszik 1TB-os lemeznél.
21

Olvasgatok a témában, vannak

inf · 2018. Jan. 27. (Szo), 11.36
Olvasgatok a témában, vannak itt kemény dolgok: link. Titkosított rendszerbe tetszőleges szoftvert tudnak injektálni szinte minimális információ alapján ha valaki CBC mode-al titkosít. Aztán persze ha lehetőség van aktív támadásra, pl hálózaton utazik a titkosított üzenet, akkor még arra is volt lehetőség, hogy a teljes üzenetet visszafejtsék: link. Mára már elvileg foltozták ezt a rést. Az eddigiek alapján tárolásra az XTS, üzenetküldésre meg az OCB mode-ok a jók.

A block cipher-nek meg egyelőre az AES 128 bites kulccsal elfogadható, bár lehet próbálkozni egzotikusabb dolgokkal is, pl chacha, de ezekre egyrészt nincs hardver támogatás (pl: AES-NI), tehát lassúak lesznek, másrészt meg nem biztos, hogy szabványosítva vannak. Ami érdekes, hogy az AES 256 bites kulccsal sérülékenyebbnek tűnik, mint a 128 bites kulccsal link, de persze ez is implementáció függő. Ezeknél azt írják, hogyha túl kevés ciklust használnak, akkor van csak probléma. Sajna az AES szabványban is messze az ajánlott alatti számú ciklust használnak, ami kihat az implementációkra: aes-js, különben nem lennének kompatibilisek egymással. :S Mondják még, hogy kvantum komputerrel a 128 bites törhető lesz, míg a 256 bites is biztonságos marad, de egyelőre még közelében sem vagyunk olyan gépeknek, amik 2^64 kvantum műveletet tudnak végezni belátható időn belül, szóval én ezt néhány évtized múlva érzem csak reális veszélynek.

LUKS-al lehet használni serpent-et is, ami biztonságosabb, mint az AES. Ahogy nézem a ZFS natívan csak AES-t támogat és abból is GCM és CCM mode-okat. Az XTS-t nem használják, valószínűleg azért, mert MAC-et is hozzáfűznek integritás védelemnek. Érdekes kérdés, hogy vajon van e értelme így csinálni, hogy minden 128 bites-os blokk végére MAC-et tesznek, mert baromi lassú a CRC-hez képest, amit 16-64KB-os szektorokra használnak a btrfs-nél. Jobban bele kéne néznem a ZFS lelkébe ehhez, de annyi időt nem szánok a dologra. Annyi extrát hozzá lehet tenni, hogy megnézem a LUKS-ot többféle mode-al is, nem csak AES+XTS-el. Egyébként bár a GCM-nek is vannak sebezhetőségei, azért biztonságosabb így, mintha MAC nélkül XTS-el kódolnánk, azonnal jelzi, ha megpróbáltak e beleírni az adatba a kulcs ismerete nélkül. Azért OCB szerencsésebb lett volna, és már licenszes probléma sincs, mert ingyenessé tették.
22

Érdekes kérdés, hogy vajon

inf · 2018. Jan. 28. (V), 02.52
Érdekes kérdés, hogy vajon van e értelme így csinálni, hogy minden 128 bites-os blokk végére MAC-et tesznek, mert baromi lassú a CRC-hez képest, amit 16-64KB-os szektorokra használnak a btrfs-nél. Jobban bele kéne néznem a ZFS lelkébe ehhez, de annyi időt nem szánok a dologra.


Közben beszéltem a ZFS fejlesztőivel, a GCM-nél auth tag van, nem MAC, de gyakorlatilag egyenértékű a kettő. Ezt használják integritás ellenőrzésre a ciphertext esetében, plusz még ezen felül SHA-512-t használnak a plaintext ellenőrzésére is. Szóval a ZFS-nél jóval védettebbek ilyen szempontból az adatok, mint a btrfs-nél, ahol csak CRC-t használnak a plaintext-hez. Sebességben olyan 10g-t ki lehet sajtolni a dologból AES-NI-vel, illetve valószínűleg a SHA-512 is elég gyors, bár annak nem néztem utána. A lényeg, hogy valószínűleg nem ez lesz a bottleneck még ilyen algoritmusokat használva sem, illetve a CPU-t sem fogja agyonterhelni. Serpent-el és más cipher-ekkel kb a negyede érhető el egyébként sebességben, mert azokra nincs hardveres gyorsítás. Nekem kb a tizede kell ennek a sebességnek az 1g belső hálómhoz jelenleg, szóval elvileg még tudok majd rápakolni egy réteg adatbázis titkosítást is. Még mindig vannak megnyitott cikkek, amiket el akarok olvasni, de már csak napok kérdése, hogy ténylegesen nekiálljak benchmark-ozni a különböző megoldásokat. Alig várom, hogy kipróbáljam mit tud a szerver. :-)