kernel: alg: aead: Test 3 failed on encryption for rfc4106-g

[TomL]

Moin

So langsam nähere ich mich dem Punkt, an dem alle Unwägbarkeiten meiner neuen Stretch-Installation beseitigt sind. Die folgende Meldung im Journal sehe ich schon länger, aber weil bisher alles gut lief, habe ich das erst mal hinten an gestellt.

Code: Alles auswählen

journalctl -b -p err
Feb 14 10:05:11 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 10:05:11 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

Das hat -so weit ich das herausfinden konnte- mit der ipsec-AES-Verschlüsselung durch den Kernel zu tun. Passend zur Fehlermeldung gibts auch einen rfc-Text dazu:
https://tools.ietf.org/html/rfc4106

Ich vermute nun, dass mir einfach ein Kernel-Treiber fehlt, den ich in meiner Custom-Distri noch nachinstallieren muss.

Code: Alles auswählen

lsmod | grep cryp -i
fscrypto               28672  1 ext4
cryptd                 24576  3 ablk_helper,ghash_clmulni_intel,aesni_intel

Ich habe nur keine Idee, welcher das sein könnte. Mit den gegebenen Stichworten finde ich weder im Repo etwas passendes, noch mit der Web-Suche auf der Debian-Seite:

Code: Alles auswählen

apt-cache search gcm-aesni
root@thomaspc:~
# apt-cache search rfc4106
root@thomaspc:~
# apt-cache search crc32c-intel
root@thomaspc:~

Hat jemand eine Idee, wie ich die Meldungen beseitigen kann?

[rendegast]

Da war doch mal etwas mehr viewtopic.php?f=33&t=164022

Feb 04 10:51:50 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel
Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul

Vielleicht einfach nur eine Bewertung Deiner crypto-Engine.
Ist ja "nur" ein "Test .. failed". kein error oder fail des Moduls mit stacktrace.

Vielleicht intel-microcode?
BIOS-Upgrade?

(Versuch) kernel "normal" (signed) <-> '-unsigned'?
(Versuch) Eigenbau kernel 4.10?

[TomL]

Da war doch mal etwas mehr viewtopic.php?f=33&t=164022

Ja, klar, aber das ist alles behoben. Aktuell keine weiteren Fehlermeldungen im Log.

Vielleicht einfach nur eine Bewertung Deiner crypto-Engine.
Ist ja "nur" ein "Test .. failed". kein error oder fail des Moduls mit stacktrace.
::::
Vielleicht intel-microcode?

Intel-CPU, der Hinweis auf "intel" in der Meldung wird mir jetzt erst bewusst.

Code: Alles auswählen

lscpu
Architecture:          x86_64
Vendor ID:             AuthenticAMD
Model name:            AMD FX(tm)-4300 Quad-Core Processor

Denkst Du, ich muss da nichts weiter unternehmen?

Eigenbau kernel 4.10?

Nein, kein Eigenbau. Es ist der normale Kernel, zuerst vom Installer, jetzt automatisch durch dist-upgrade aktualisiert. Ich habe nicht dran geschraubt.

[rendegast]

lscpu
Architecture: x86_64
Vendor ID: AuthenticAMD
Model name: AMD FX(tm)-4300 Quad-Core Processor

Dann halt mit amd64-microcode versuchen.

Eigenbau kernel 4.10?

Nein, kein Eigenbau.

Das habe ich mir schon gedacht,
ich meinte es damit zu versuchen.

Ja, klar, aber das ist alles behoben. Aktuell keine weiteren Fehlermeldungen im Log.

Hast Du denn etwas spezielles unternommen, um

Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul

wegzubekommen?

[TomL]

Dann halt mit amd64-microcode versuchen.

Das war schon installiert. Ich vermute, der Installer hat es bei der Auswahl "Alle unfreien Treiber für dieses Gerät installieren" automatisch installiert.

Hast Du denn etwas spezielles unternommen, um

Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul

wegzubekommen?

Ich hatte die 3 Meldungen zusammen als EIN Problem verstanden, und das eine Lösung alle Meldungen beseitigt. Ist das ein "eigenes" Problem?

[rendegast]

Ist das ein "eigenes" Problem?

Es ist ein anderer Test für ein anderes Modul.
Was die Test bedeuten, erschließt sich aber wohl nur aus dem Quelltext des kernel.

Feb 03 13:33:51 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 03 13:33:51 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel
Feb 03 13:33:51 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
...
Feb 03 15:28:53 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 03 15:28:53 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
<Nix mehr crc32c-intel>
...

Wenn diese Meldung nicht mehr auftaucht,
hat sich wohl irgendwas verändert.
kernel-Upgrade? Obwohl

linux-signed (4.1) unstable; urgency=medium
* Update to linux version 4.9.6-3
-- Ben Hutchings <ben@decadent.org.uk> Sat, 28 Jan 2017 15:32:33 +0000

linux-signed (4) unstable; urgency=medium
* Update to linux version 4.9.2-2
-- Ben Hutchings <ben@decadent.org.uk> Fri, 13 Jan 2017 14:51:14 +0000

...

ist die tatsächliche Verfügbarkeit auf dem Server wohl jeweils ein paar Tage später.
Eventuell betraf die Meldung auch den Installationskernel des verwendeten Iso.
Irgendwas im BIOS ab/angeschaltet?

Vielleicht hängt es ja auch mit anderen Modulen zusammen.
Hier zBsp. wird crc32c-generic wegen btrfs geladen,
kein btrfs dann kein crc32c.
Und cryptd verwendet/bewertet dann einfach nur geladene Module, statt selbst welche aufzurufen?

[TomL]

Ich habe jetzt gerade noch mal neu gebootet. So ist jetzt die aktuelle Situation:

Code: Alles auswählen

# journalctl -b -p err
-- Logs begin at Mon 2017-02-13 16:00:32 CET, end at Tue 2017-02-14 15:01:46 CET. --
Feb 14 15:01:20 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 15:01:20 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

# lsmod | grep crc -i
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
crc16                  16384  1 ext4
crc32c_generic         16384  2
crc32c_intel           24576  0

# lsmod | grep crypt -i
fscrypto               28672  1 ext4
cryptd                 24576  3 ablk_helper,ghash_clmulni_intel,aesni_intel

Ich würde jetzt annehmen, der früher vorhandene Fehler (crc32-pclmu) scheint sich mit dem Kernel-Upgrade behoben zu haben, denn explizit habe ich bisher nicht darauf reagiert. Wie gesagt, weil alles lief, habe ich das erst mal hinten an gestellt und heute mir ist gar nicht aufgefallen, dass von den Anfangs 3 Fehlern bereits einer weg ist.... mannomann, das Du Dich daran erinnern kannst....

Aber die Frage ist, wie man die Meldungen bewerten muss. Auch wenn hier nur ein Test "failed", heisst das vielleicht, dass möglicherweise der ganze AES-Mechanismus jetzt tot oder inaktiv ist? Ich kann überhaupt nicht einschätzen, ob das ein Grund zur Sorge ist oder ob man das einfach ignorieren kann. Oder ist das nur ein temporäres Problem, weil Stretch eben derzeit noch nicht st able ist und man kann das einfach aussitzen?

[rendegast]

Die Test kommen wohl aus
crypto/testmgr.*

Es gibt noch per CRYPTO_MANAGER > CRYPTO_TEST
crypto/tcrypt.*
("Quick $ dirty crypto test module")

tcrypt ist ein separates Modul (das sich bei mir gar nicht laden läßt, "Invalid cross-device link"),
testmgr wird wohl irgendwo implizit verwurstet.
------------------------
EDIT wegen kernel-parameters.txt

901 cryptomgr.notests
902 [KNL] Disable crypto self-tests

('notests' ist ein Parameter von testmgr)
ist es wohl Bestandteil des inline-Moduls cryptomgr (CRYPTO_MANAGER).
------------------------

Darin stecken viele 'case XX' mit Bezug auf crypto-Modi
(und in testmgr.h viel binäres Zeug),
wie das aber mit den "Test YY" zusammengebracht werden kann?

der früher vorhandene Fehler (crc32-pclmu) scheint sich mit dem Kernel-Upgrade behoben zu haben, denn explizit habe ich bisher nicht darauf reagiert.

Eine Liste der gebooteten Kernel

Code: Alles auswählen

NUM=$(journalctl --list-boots | wc -l)
seq -$NUM 0 | while read ID; do
    #journalctl -b $ID | head -n 10 | grep "Linux version"
    journalctl -b $ID | egrep "Linux version|Test.*failed"
done

(Das 'head' dient der Beschleunigung)
(Ein journalctl-Match auf "Linux version" habe ich nicht hinbekommen)

[TomL]

EDIT wegen kernel-parameters.txt

901 cryptomgr.notests

('notests' ist ein Parameter von testmgr)

Ich habe mich mal "umgesehen". Auf allen meinen Stretch-Installationen habe ich den gleichen Fehler, bis sogar rein in die VM's. Und ich habe diesen von Dir gefundenen Parameter beginnend mit den VMs nun auf alle Systeme ausgerollt. Damit sieht der aktuelle Stand nun bei mir so aus:

Code: Alles auswählen

# journalctl -b -1 -p err
-- Logs begin at Mon 2017-02-13 16:05:33 CET, end at Tue 2017-02-14 20:30:59 CET. --
Feb 14 15:01:20 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 15:01:20 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

# journalctl -b -p err
-- No entries --

Jetzt bleibt wirklich nur noch die Frage, ob die Deaktivierung der Tests in etwa der Haltung entspricht "Ein Problem, welches ich nicht sehen kann, existiert auch nicht." .,.. weil das letztendlich auch beinhalten kann, dass ein wirkliches Problem immer noch besteht. Andersrum frag ich mich, der Sinn eines solchen Parameters kann sich doch nur daraus ergeben, dass dieser Test eigentlich entbehrlich ist. Würdest Du bei so einer Situation auf Deinem Rechner noch etwas unternehmen?

[rendegast]

Ich würde das cryptomgr.notests nicht setzen.
Eher eine Übersetzungstabelle suchen, die die Meldungen verständlicher macht.

Ich habe irgendwann mal eine Abfragemöglichkeit an die crypto-Engine gesehen.
'openssl engine' ?

[breakthewall]

Damit sieht der aktuelle Stand nun bei mir so aus:

Code: Alles auswählen

# journalctl -b -1 -p err
-- Logs begin at Mon 2017-02-13 16:05:33 CET, end at Tue 2017-02-14 20:30:59 CET. --
Feb 14 15:01:20 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 15:01:20 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

# journalctl -b -p err
-- No entries --

Jetzt bleibt wirklich nur noch die Frage, ob die Deaktivierung der Tests in etwa der Haltung entspricht "Ein Problem, welches ich nicht sehen kann, existiert auch nicht." .,.. weil das letztendlich auch beinhalten kann, dass ein wirkliches Problem immer noch besteht. Andersrum frag ich mich, der Sinn eines solchen Parameters kann sich doch nur daraus ergeben, dass dieser Test eigentlich entbehrlich ist. Würdest Du bei so einer Situation auf Deinem Rechner noch etwas unternehmen?

Beim Systemstart testet der Linux-Kernel auf so viel Hardware. Allein bei mir gibt es mehrere Meldungen dieser Art, wo auf Geräteklassen getestet wird, die zwar theoretisch seitens des Mainboards unterstützt werden, aber real kein solches Gerät existiert womit jene Tests entsprechend fehlschlagen. Würde diverse Testroutinen niemals abschalten, sondern weniger in solche Meldungen hinein interpretieren.

Was ich mich frage ist, warum dich beispielsweise crc32c-intel überhaupt interessiert, bei einer offensichtlichen AMD-CPU. Die andere Meldung ist AES-NI bezogen. Und ob das auch funktioniert, kannst mit einem realen Test herausfinden. Wenn sich hier AES nicht deutlich von anderen Verschlüsselungsalgorithmen abhebt, in Sachen Geschwindigkeit, dann hast sicher ein reales Problem was behoben werden sollte. Auch wenn das die Sicherheit der Verschlüsselung nicht beeinträchtigen sollte.

[TomL]

Moin zusammen

Ich würde das cryptomgr.notests nicht setzen.Eher eine Übersetzungstabelle suchen, die die Meldungen verständlicher macht.

Würde diverse Testroutinen niemals abschalten, sondern weniger in solche Meldungen hinein interpretieren.

Ihr habe beide Recht damit, eigentlich sehe ich das genauso. Aber andererseit möchte ich mich nicht daran gewöhnen, den zunächst immergleichen Fehlermeldungen keine Aufmerksamkeit zu schenken. Über kurz oder lang läuft das nämlich darauf hinaus, dass ich auf andere Meldungen vielleicht ebenfalls nicht reagiere, weil das alles zu schnell durchrauscht und ich nicht mitbekomme, dass möglicherweis neue Probleme bestehen. Und das vor dem Hintergrund des Gedankens "Ist ja eh immer der selbe Fehler". Im Moment kriege ich jedes "Rot" sofort mit und schaue ins Log. Aber wenn ich mich einmal dran gewöhne, "Rot" zu ignorien, halte ich das für ein Risiko.

Ich habe mich gestern abend mal mit einigen Test beschäftigt:

Code: Alles auswählen

grep -m1 -o aes /proc/cpuinfo   
sort -u /proc/crypto | grep module
openssl engine 
openssl speed
openssl speed aes-128-cbc
openssl speed aes-192-cbc
openssl speed aes-256-cbc
openssl speed sha1
openssl speed sha256
openssl speed sha512

Mir ist nichts aufgefallen, was vielleicht irgendwie fehlerhaft sein könnte oder nicht ordnungsgemäß läuft. Ich habe die Ergebnisse mal im Web verifiziert und scheinbar ist alles gut und der CPU-Leistungsfähigkeit entsprechend.

Welche Alternativen gibts denn vielleicht noch, mit diesem Problem umzugehen .... die nicht darin bestehen, die Fehlermeldungen zu ignorieren?

[rendegast]

etwas off-topic
[np]39761[/np] crypto_Tabelle.sh
um /proc/crypto in Tabellenform darzustellen.
EDIT Unterlassungssünde im Skript: Test auf funktionierendes 'mktemp'(!),
damit $TEMPd nicht leer ist und das Skript nicht Dateien in $HOME verarbeitet, derart:

Code: Alles auswählen

which mktemp >/dev/null  ||  exit 0

-> 39762

Anwendung

Code: Alles auswählen

./crypto_Tabelle.sh  |  less -S

Welche Alternativen gibts denn vielleicht noch, mit diesem Problem umzugehen .... die nicht darin bestehen, die Fehlermeldungen zu ignorieren?

Anderer Rechner, dessen crypto die entsprechenden feature bietet?

Wenn ich die www so lese und mir selber auch denken kann,
haben die hardware-crypto (CPU oder dediziertes device) die Eigenschaft,
nicht alle Modi zu bieten.
Bsp. https://events.linuxfoundation.org/site ... o-user.pdf

Wegen der blackbox-Artigkeit braucht es da wohl die Tests.
software (engine "dynamic") hat dieses Manko nicht, ist aber langsamer.

[breakthewall]

Ich habe mich gestern abend mal mit einigen Test beschäftigt:

Wurde schon Folgendes getestet?

Code: Alles auswählen

cryptsetup benchmark
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   182,8 MiB/s   212,2 MiB/s
 serpent-cbc   128b    75,9 MiB/s   198,0 MiB/s
 twofish-cbc   128b   177,6 MiB/s   215,1 MiB/s
     aes-cbc   256b   147,7 MiB/s   161,0 MiB/s
 serpent-cbc   256b    76,2 MiB/s   188,9 MiB/s
 twofish-cbc   256b   177,7 MiB/s   217,5 MiB/s
     aes-xts   256b   199,1 MiB/s   203,9 MiB/s
 serpent-xts   256b   182,4 MiB/s   181,7 MiB/s
 twofish-xts   256b   196,4 MiB/s   195,1 MiB/s
     aes-xts   512b   156,2 MiB/s   156,9 MiB/s
 serpent-xts   512b   177,7 MiB/s   185,1 MiB/s
 twofish-xts   512b   199,9 MiB/s   198,1 MiB/s

Da meine CPU kein AES-NI unterstützt, ist AES natürlich entsprechend langsam. Bei dir sollte das Gegenteil der Fall sein, sofern alles funktioniert.

[TomL]

Moin

Das sind meine Ergebnisse:

Code: Alles auswählen

cryptsetup benchmark
# Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen.
PBKDF2-sha1       819200 iterations per second for 256-bit key
PBKDF2-sha256    1101445 iterations per second for 256-bit key
PBKDF2-sha512     748982 iterations per second for 256-bit key
PBKDF2-ripemd160  697191 iterations per second for 256-bit key
PBKDF2-whirlpool  360087 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   567,6 MiB/s  2229,2 MiB/s
 serpent-cbc   128b    69,6 MiB/s   326,2 MiB/s
 twofish-cbc   128b   186,2 MiB/s   244,7 MiB/s
     aes-cbc   256b   427,3 MiB/s  1755,4 MiB/s
 serpent-cbc   256b    75,3 MiB/s   313,9 MiB/s
 twofish-cbc   256b   193,3 MiB/s   248,1 MiB/s
     aes-xts   256b  1864,9 MiB/s  1885,7 MiB/s
 serpent-xts   256b   307,9 MiB/s   314,8 MiB/s
 twofish-xts   256b   235,9 MiB/s   231,1 MiB/s
     aes-xts   512b  1495,7 MiB/s  1498,9 MiB/s
 serpent-xts   512b   314,2 MiB/s   320,5 MiB/s
 twofish-xts   512b   241,8 MiB/s   240,6 MiB/s

AES ist beim Wertevergleich also bald um den Faktor 10 schneller. Das kann man doch wohl als gutes Ergebnis verstehen.... oder? Gefühlsmäßig erlebe ich meinen Rechner sowieso in keinster Weise als Spassbremse. Er macht alles gut und und meinen Erwartungen vollständig entsprechend. Und dennoch können wir wohl darin übereinstimmen, dass er eine "Macke" hat. Das ist nicht neu, das hat mich bereits schon mal über ein 3/4 Jahr hinweg beschäftigt, dann hier wieder, und jetzt erneut in diesem Thread. Dabei geht es immer um Probleme mit der Verschlüsselung.

Welche Alternativen gibts denn vielleicht noch, mit diesem Problem umzugehen .... die nicht darin bestehen, die Fehlermeldungen zu ignorieren?

Anderer Rechner, dessen crypto die entsprechenden feature bietet?

Das ist meine CPU: AMD FX(tm)-4300 Quad-Core Processor
Und das mein Board: Gigabyte Board GA-78LMT-usb3

Welche Schlüsse kann man denn nun aus den gegebenen Fakten ziehen? Tatsächlich ein neuer Rechner als einzige Alternative? Oder vielleicht nur eine neue CPU. Soweit ich das verstanden habe, kann mein Board nur AMD-CPUs *hmmm*... Intel geht dann wohl leider nicht. Aber die einzige wichtige Frage ist doch die nach dem "ob überhaupt"?

Kann man anhand der bisherigen Erkenntnisse sagen, dass es mit meinem Rechner ein echtes Sicherheitsproblem gibt? Ich bin mit so einer Einschätzung hoffnungslos überfordert. So wie ich das sehe, funktioniert auf der von mir wahrnehmbaren Oberfläche doch alles prima. Gibt es jedoch trotzdem möglicherweise Anlass zur Sorge, wegen der Beinträchtigung der Aufgaben unterhalb der wahrnehmbaren Oberfläche? Scheinbar funktioniert aber auch AES, ob nun seitens CPU oder Softwareseitig kann ich nicht beantworten, aber anscheinend gehts ja. Zu keiner Zeit habe ich das Gefühl von Schlaftabletten-Tempo... alles funktioniert ausreichend flott.

Mt der Einstellung TLS-Max = 3 (siehe beide Links) hatte ich lange ein Problem, aber mit 2 als Einstellung gibts diese Störungen jetzt auch nicht mehr. Wahrscheinlich hängt das alles zusammen, bzw. hat den gleichen Fehlerursprung, also der frühere Fehlercode ssl_error_bad_mac_read und jetzt aktuell die fehlgeschlagenen Tests. Das scheint mir jedenfalls ein logischer Rückschluss zu sein. Allein die Frage bleibt: Ist das eher ein kosmetisches Problem oder ein echtes Integritätsrisiko (bzw. könnte dazu werden)?

Was wäre sinnvolles tun? Mal eben ein für mich leistungsmäßig ausreichendes Board und ne CPU zu entsorgen, nur um vielleicht einen kosmetischen Mangel zu beheben, möchte ich eigentlich nicht. Wenn die Probleme allerdings wirklich eine sicherheitsrelvante Beeinträchtigung darstellen, dann ist klar, was zu tun ist.

Das Script crypto_Tabelle.sh funktioniert bei mir überhaupt nicht... es bricht völlig unerklärlich mit "keine Berechtigung ab". Ich habs als root gestartet, geprüft, ob die Aufrufe alle möglich sind..... ich kann nix feststellen, woran es scheitert. Allerdings ist es mit der gegebenen Formatierung für mich auch nicht mehr nachvollziehbar, wie der Ablauf ist oder sein soll, um da mal Debug-Breaks einzubauen.

[rendegast]

... kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
... kernel: alg: hash: Test 14 failed for crc32c-intel

Und dennoch können wir wohl darin übereinstimmen, dass er eine "Macke" hat.

Möchte ich nicht mit übereinstimmen.
google-Treffer finde ich nicht derart, daß mir eine solche Aussage gerechtfertigt wäre.
Es könnte genausogut ein kernel-Fehler(?) sein,
meine Idee mit der einfachen Feature-Probe scheint mir auch nicht widerlegt.
Das immer wieder heraufbeschworene "gut dokumentiert" scheint nur für Vollprofis zu gelten.
Es findet sich nichts, von dem ich sagen würde, es paßt zu diesen Meldungen.
Es finden sich entfernt ähnliche mit stacktrace ("echte Fehler"), über die kernel-devs lamentieren.
Aber auch bzgl. stacktrace,
hier auf einer stretch-VM schmeissen floppy und ppdev/parport stacktrace, obwohl der einzige Grund ist, daß die devices gar nicht existieren.


Hier (Anm. kein hardware-crypto) sind um die Meldung des cryptomgr die Meldungen zum signed-Zert angeordnet.

Feb 14 21:45:15 debian kernel: Loading compiled-in X.509 certificates
Feb 14 21:45:15 debian kernel: alg: No test for pkcs1pad(rsa,sha256) (pkcs1pad(rsa-generic,sha256))
Feb 14 21:45:15 debian kernel: Loaded X.509 cert 'Debian Project: Ben Hutchings: 008a018dca80932630'

Arbeitest Du mit dem signed- oder unsigned-Kernel?






-------------------------------------------------------------------

Das Script crypto_Tabelle.sh funktioniert bei mir überhaupt nicht... es bricht völlig unerklärlich mit "keine Berechtigung ab".

mktemp, csplit, printf und paste sind aus coreutils, sollten mit hoher Wahrscheinlichkeit verfügbar sein.
Das sed formatiert zu gequotetem Variablensyntax

Code: Alles auswählen

xxx       :     yyyy(zzzz)
aaa      :     bbb
cc dd   :     ee
->
xxx="yyyy(zzzz)"
aaa="bbb"
cc_dd="ee"

In einem Satz nicht vorhandene Merkmale werden als "--" ausgegeben.
Die printf sorgen für jeweils gleichbreite Zeilen, damit beim paste kein Versatz der Spalten stattfindet.
Im erstellten $TMPd/ hat der Benutzer alle Rechte.

$TMPd/ wird normalerweise in /tmp/ erstellt, ist dieses vielleicht 'noexec' gemountet?
Eventuell TMPd woanderhin verlegen, zBsp.

Code: Alles auswählen

TMPd=$(mktemp -d)
->
TMPd=$(mktemp -d -p ~)

(wobei /home/ dann wiederum nicht mit 'noexec' belegt sein sollte)

[TomL]

Und dennoch können wir wohl darin übereinstimmen, dass er eine "Macke" hat.

Möchte ich nicht mit übereinstimmen.

Ich hatte bei der Formulierung den Rechner als "Summe seiner Teile" im Sinn, also als ein Ganzes, ohne jetzt zu unterscheiden, ob es letztendlich CPU, Board, Kernel oder SSL-Implemenierung oder Debian oder sonst was ist. Mein Rechner als Frontend hat als einziger diese Probleme. Sogar die VMs auf der Maschine zeigen keine solcheart Symptome.

google-Treffer finde ich nicht derart, daß mir eine solche Aussage gerechtfertigt wäre.

Letztendlich bleibt die Frage, mit welchem Fazit man das Kapitel zufriedenstellend abschließen kann. Offensichtlich scheint das wirklich was einmaliges zu sein, oder zumindest etwas sehr seltenes.... eben weil so wenig im Web darüber gefunden werden kann.

meine Idee mit der einfachen Feature-Probe scheint mir auch nicht widerlegt.

Was bedeutet Feature-Probe? Ist das etwas aus dem Web, worauf Du Dich berufst? Oder ist das etwas, was ich machen müsste? Sollte ich explizit bestimmte Features "proben"?

Arbeitest Du mit dem signed- oder unsigned-Kernel?

Das ist eine Frage, die ich mir noch nie gestellt habe......welchen Kernel installiert der Installer bzw. welcher kam zuletzt automatisch mit dem dist-upgrade? Was ist überhaupt der Unterschied?

mktemp, csplit, printf und paste sind aus coreutils, sollten mit hoher Wahrscheinlichkeit verfügbar sein.
Das sed formatiert zu gequotetem Variablensyntax

Coreutils war installiert, allerdings war mir dieser Zusammenhang neu. Und da ich neugierig war, ob ich die Befehle überhaupt "habe" und was die tun, habe ich natürlich mit "which" gegengeprüft und mir jeweils die man-page angesehen. Was mir so Probleme bereitet, ist die Abgrenzung der while-Schleifen. Ich formatiere selber immer streng nach cpp-Syntax, mit konsequenter und leicht reproduzierbarer Einrückung. Aber bei dem Script bin ich leicht überfordert .... wobei das jetzt keine Kritik sein soll... ich kann nur einfach nicht die mehrzeiligen Statements so abgenzen, dass ich das verstehe. Ich selber neige eher dazu, "geschwätzig" und selbsterklärend zu coden, mit eingebauten Trace-Ausgaben... und nehme lieber Performance-Einbußen hin, zugunsten der leichteren Lesbarkeit und zum besseren Verständnis von Code-Zusammenhängen. Aber wie gesagt, das ist jetzt keine Kritik. Es fällt mir halt nur schwer, als Laie so komprimierten Code zu lesen.

Nachtrag
Jetzt läuft das Script und ich bekomme eine ordentliche Tabellen-Ausgabe. Aber was kann ich jetzt hier herauslesen? Welche verwertbahren Erkenntniss enthält die Tabelle für mich?

[rendegast]

meine Idee mit der einfachen Feature-Probe scheint mir auch nicht widerlegt.

Was bedeutet Feature-Probe? Ist das etwas aus dem Web, worauf Du Dich berufst? Oder ist das etwas, was ich machen müsste? Sollte ich explizit bestimmte Featurs "proben"?

Ich hatte "Probe" vorher anders formuliert:

Vielleicht einfach nur eine Bewertung Deiner crypto-Engine.
Ist ja "nur" ein "Test .. failed". kein error oder fail des Moduls mit stacktrace.

Ich dachte dabei an etwas in diese Richtung

Code: Alles auswählen

[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
[    0.000000]   2 base 0000C0000000 mask FFFFF0000000 write-back
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled

[    0.000000] ACPI: Early table checksum verification disabled

[    0.005915] Security Framework initialized
[    0.005920] Yama: disabled by default; enable with sysctl kernel.yama.*
[    0.005931] AppArmor: AppArmor disabled by boot time parameter

verbunden mit einer unglücklichen Meldungsformulierung des cryptomgr.

Sollte ich explizit bestimmte Featurs "proben"?

Ich sehe für den Anwender wohl nur die crypto-Benchmarks und die Ausgabe von /proc/crypto.
Das Crypto des Kernels zu bewerten/debuggen ist wohl eine Aufgabe,
die nur echten Profis dieser Sparte zukommt.
Ich hoffe/vertraue mal, daß das ganze so angelegt ist, daß nichts wirklich schlimmes passieren kann,
also daß nicht (unbemerkt) eine ausgewählte betroffene Verschlüsselung durch Nichtverschlüsselung ersetzt wird.
Also derart, daß wenn ein hardware-Modus nicht entsprechend benutzt werden kann,
(nur) das software-Pendant benutzt wird / möglich ist. Zwar langsamer, aber letztlich sicher.

Arbeitest Du mit dem signed- oder unsigned-Kernel?

... Was ist überhaupt der Unterschied?

Das Ben Hutchings Zertifikat für Betrieb unter secure boot.
Die nicht damit ausgerüsteten kernel-Pakete heißen "-unsigned".
Das "-unsigned"-Paket muß normalerweise explizit ausgewählt werden,
es ersetzt das signed-Paket.




----------------------------------------

Was mir so Probleme bereitet, ist die Abgrenzung der while-Schleifen.

Ich benutze das 'while' in diesem Fall, um eine zeilenweise Abarbeitung der Eingabe sicherzustellen.

Aber was kann ich jetzt hier herauslesen?

Auf einem genügend breiten Bildschirm sind die Werte für eine Option nebeneinandergestellt
(Zeilenmarkierungsmöglichkeit des 'less'),
wobei ich direkt sehen kann, zu welchem Modus ("name") das gehört.
Das erleichtert hoffentlich die Einordnung/Bewertung der /proc/crypto-Datensätze.
ZBsp. haben einige ja kein 'digestsize'.
Dazu müßte aber auch die Bedeutung der Optionen verstanden sein,
wobei es bei mir geflissentlich hapert.

[TomL]

Ich sehe für den Anwender wohl nur die crypto-Benchmarks und die Ausgabe von /proc/crypto. Das Crypto des Kernels zu bewerten/debuggen ist wohl eine Aufgabe, die nur echten Profis dieser Sparte zukommt. Ich hoffe/vertraue mal, daß das ganze so angelegt ist, daß nichts wirklich schlimmes passieren kann, also daß nicht (unbemerkt) eine ausgewählte betroffene Verschlüsselung durch Nichtverschlüsselung ersetzt wird. Also derart, daß wenn ein hardware-Modus nicht entsprechend benutzt werden kann, (nur) das software-Pendant benutzt wird / möglich ist. Zwar langsamer, aber letztlich sicher.

Wenn ich Dich nun richtig verstanden haben, kommen wir in etwa zu einem gleichen Ergebnis. Man muss bei diesem Symptom auch darauf vertrauen, dass eine erfolgreiche Verschlüsselung immer noch stattfindet. Alle Tests und Ausgaben zeigen ja, dass entsprechende Module vorhanden sind und anscheinend auch "arbeiten".
Warum speziell diese Test's während der Boot-Phase fehlschlagen und warum 'security.tls.version.max=3' beim Browser permanent 'ssl_error_bad_mac_read' auslöst, ist durch uns nicht feststellbar... beides kann möglicherweise sogar auf der gleichen Fehlerquelle beruhen. Fakt ist, sowohl https-Seiten als auch LUKS-AES-verschlüsselte Devices kann ich problemlos handhaben. Und das die AES-Verschlüsselung gerade bei LUKS-Devices (auch sehr komfortable) funktioniert, ist dadurch bestätigt, dass eben auch -durch andere Rechner erzeugte- portable Devices fehlerfrei gehandhabt werden.

Wärst Du mit diesem Fazit einverstanden? Wenn ja, ergibt sich daraus für mich, dass ich 'notest' bei den Kerneloptionen belasse und nun einfach darauf vertraue, dass der Rechner tut, was er soll und was ich von ihm erwarte.