ZFS native crypto in OpenZFS

h^2

h^2

hat ne Keule +1
Die native ZFS crypto ist jetzt in OpenZFS gelandet und für Linux auch schon integriert worden:
https://github.com/zfsonlinux/zfs/commit/0b04990a5de594659d2cf20458965277dd6efeb1
Und das, obwohl auf Linux sogar viel reimplementiert werden musste aus Lizenzgründen. Wie sieht hier der Stand jetzt bei uns aus? Soweit ich weiß ist das neuer code, und nicht der geleakte...
Ich weiß, dass man da früher skeptisch war, aber es wäre schon ziemlich toll, dataset-weise verschlüsseln zu können. Und dann auch noch cross-platform, was kann man mehr wollen :D
 
Laut Allan Jude wird im Moment noch geprüft, ob der Code taugt und soll anschließend in HEAD aufgenommen werden.
 
Und ist das Verfahren gut? Ich meine mich zu erinnern, dass es an der proprietären ZFS-Lösung einige Kritikpunkte gab welche das Verfahren als nicht optimal bewerteten. Genaueres müsste ich aber auch erst wieder suchen....
 
Es geht um eine clean-room reimplementation. IIRC rührte die Skepsis bei FreeBSD am Anfang daher, dass nicht klar war, wie "clean".
Aber die Lizenz des Ganzes wären dann frei.
 
h^2 schrieb:
Es geht um eine clean-room reimplementation. IIRC rührte die Skepsis bei FreeBSD am Anfang daher, dass nicht klar war, wie "clean".
Aber die Lizenz des Ganzes wären dann frei.
Zum Vergrößern anklicken....
AFAIK ist der ZFS Cryptocode von Oracle mal im Internet aufgetaucht und weil sich keiner ne Klage von Oracle einfangen wollte, weil der Open Source Crypto-Code dem proprietären ähnelt, hat sich da lange keiner rangetraut.
 
Außerdem war der Kryptocode wohl nicht von Suns besten Kryptographen entwickelt worden und hatte diverse Probleme.
 
Der korrekte Weg ist, dass der Kram nach OpenZFS zurückfließt und von dort dann in FreeBSD gemerged wird. Das muss allerdings nicht so sein. Es ist auch schon öfter Code direkt zwischen Linux und FreeBSD geflossen. Beispielsweise damals TRIM, was erst auf FreeBSD implementiert wurde, unter Linux finalisiert und dann von dort aus auf FreeBSD gemerged.
 
Die Kombination aus ZFS Dataset Encryption und Rerooting könnte ein guter Kompromiss für günstige Dedicated Root Server sein.
 
Vor ca. 3 Wochen ist es ja jetzt wirklich gemerget worden: https://github.com/zfsonlinux/zfs/pull/5769

Noch immer kein Wort zum Status auf FreeBSD. Ich finde es wirklich Schade, dass FreeBSD seine Pionier-Rolle bei ZFS offensichtlich nicht genutzt hat um soclhe Akzente zu setzen. Anscheinend prägen die ZoL-Entwickler viel stärker wo es lang geht, obwohl ZFS doch auf Linux ein Nischendasein fristet. Weiß jemand warum?
 
Ich glaube, dass es ein Unterschied in Sachen Entwicklungsphilosophie ist. Im Linux-Lager ist man eher bereit Risiken einzugehen, auch mal Code zu mergen der vielleicht noch nicht 1.000x durchgetestet ist. Illumos und FreeBSD sind da wesentlich konservativer. Niemand will riskieren eine so große Änderung an ZFS vorzunehmen, ohne mindestens 2 doppelte Böden in Form ausreichender Erfahrungen mit dem Code zu haben. Das Security Team will sich nicht die Blöße geben eventuell schlechter Kryptographie zugestimmt zu haben, wenn irgendwann Unzulänglichkeiten gefunden werden sollten. core@ will keinen Ärger mit Oracle, denen ja Code zur Dataset-Verschlüsselung geleakt war. Und so weiter.

Ich persönlich mag dies konservative Denken eigentlich, aber im Moment nimmt es bei FreeBSD Auswüchse an, die mich nerven. Nachdem die endlose Geschichte drm-next jetzt langsam zum Abschluss kommt, rückt das leidige Thema "UEFI, GELI und ich" ganz oben auf meine Nerv-Liste. Eng gefolgt von den diversen schönen Bhyve-Features, die seit Jahr und Tag auf ihren Commit warten.
 
Konservatives Denken schön und gut, aber was es nicht gibt, kann man eben auch nicht testen. Ein experimentelle Patchset gegen das aktuelle Release oder Stable wäre da schon was. Wer sich des Risikos bewusst ist, kann sich das selbst bauen und testen. Ich hätte genug Anwendungen wo ich das gerne einsetzen könnte und ein kleines Restrisiko bezüglich Datenverlust in kauf nehmen würde. So könnte das ganze "reifen". Ich werd mir das unter Linux auf jedenfall mal ansehen.
 
http://www.open-zfs.org/wiki/OpenZFS_Developer_Summit_2017

ZFS Developer Summit und bis jetzt gerade mal eine halbe Person von FreeBSD auf dem Panel :apaul:

Gab es irgendwann einen wirklichen Policy-Change sich aus der Entwicklung zurück zu ziehen oder ZFS gar langfristig aufzugeben? Ich finde das alles schon sehr merkwürdig. Das hat m.E. auch nichts mit konservativem Denken zu tun, sondern mehr damit das Denken anderen zu überlassen.

edit: Oder gab es vielleicht von den anderen Entwicklern den Move FreeBSD-devs auszuschließen?
 
FreeBSD war auf den OpenZFS Summits aber noch nie wirklich vertreten. Was sicher auch daran liegt, dass FreeBSDs Entwickler außer in der Anfangsphase von ZFS niemals wirklich große Features entwickelt haben. Und wenn doch, waren bzw. sind sie mit OpenSolaris / Illumos inkompatibel, weshalb sie nicht in OpenZFS eingehen konnten. TRIM wurde z.B. recht zeitnah von Linux übernommen, aber ist meines Wissens bis heute aufgrund fehlender Infrastruktur in Illumos nicht in OpenZFS angekommen. zfsd ist eng gegen FreeBSDs devd und GEOM entwickelt, damit weitgehend unportabel. Dennoch:

OpenZFS-Änderungen gehen meist innerhalb von Wochen in FreeBSD ein. Das betrifft auch neue Features, zum Beispiel ist gerade vor wenigen Tagen pausierbares 'zfs send' committed worden. In Sachen größerer Features werden wie lange erwarteten ZFS Channel Programs werden wahrscheinlich in den nächsten Tagen kommen. Damit fehlt FreeBSD nur noch Crypto, was auf einem der letzten Dev Summits besprochen wurde. Da gibt es derzeit zwei Probleme. Einmal merken die OpenZFS-Entwickler selbst an, dass der Code noch Reviews durch Personen benötigt, die sich mit der Materie auskennen. Es ist fraglich, dass FreeBSDs Security Team einem Import ohne zumindest ein entsprechendes Review zustimmt. Außerdem unterstützt FreeBSDs OpenCrypto kein AES-CCM, was vom OpenZFS Crypto Code benötigt wird ist. Das müsste also implementiert werden und ebenfalls durch den Review-Prozess. Linux Lösung war einfach das ganze Illumos-Cryptoframework zu portieren.
 
Der läuft im Kernel (ZFS Channel Programs laufen im Kernel) in so einer Art Sandbox, meine ich.
 
Naja, ich hab den Hype um Lua(Script) nie verstanden. M.E. eine absurde Syntax und für kleinere Sachen gibt es doch schöne SH-Dialekte, für größere eben python oder Ruby...
Bin froh, dass ich von awesome weg bin zu i3 :cool:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben