Linux: Multitouchsupport im Surface Pro 4

Heute geht es mal wieder um Linux auf dem Surface Pro 4 Tablet. Da hatten wir lange keinen Beitrag mehr dazu 🙂

Linux: Multitouchsupport im Surface Pro 4

Mit Kernel 5.8 kam „leider“ eine Änderung ins System: Touch ging nicht mehr. Auf einem Tablet ist das natĂŒrlich der Super-GAU und natĂŒrlich kamen sofort Erinnerungen auf zur Erstinbetriebnahme vor 18 Monaten.

Der letzte Kernel der noch ohne weiteres funktionierte war 5.7.17-2, ergo war erstmal ein Bugreport an die Entwickler nötig. Zum GlĂŒck konnten die das Problem erfolgreich beheben, wobei man sagen muß, ein bisschen mehr PR tĂ€te denen ganz gut 😉

Ihr braucht eine neue Zusatzsoftware fĂŒr den Kernel 5.8: iptsd

Die Installation ist ganz einfach, sofern Ihr, und ich bin sicher, daß Ihr das habt, das Kernel Repo eingerichtet habt: surfacelinux.com .

dnf install iptsd -y

systemctl start iptsd
systemctl enable iptsd
reboot

Eigentlich ist der iptsd ein User-Space-Daemon, er braucht keinen Neustart, aber das hatte bei mir leider nicht funktioniert. Erst nach dem das System 2h geladen und dann neu gestartet wurde, funktionierte der Daemon wie er sollte.

Jetzt war wieder alles möglich, was der JakeDay-Kernel, keine Ahnung wieso der abgetaucht ist, auch konnte: nÀmlich Multi-Touch-Gesten ( und die Maschine wirklich abschalten, aber das ist ne andere Geschichte )

Multi-Touch-Gesten meint z.b., daß man unter der Gnome-Shell in die AktivitĂ€tenĂŒbersicht mit Hilfe von 3-Fingern die sich aufeinander zubewegen wechseln kann. Auch funktioniert das Zoomen im Firefox und anderen dafĂŒr vorbereitete Apps wieder, was die Bedienung deutlich einfacher macht im Tabletmodus \o/

Jetzt braucht es nur zwei Fixe an der Kamera und dem Mouseeventmanagment und das Tablet ist, bis auf den hohen Stromverbrauch durch den Kernel selbst, endlich vollstÀndig benutzbar.

„Jungs, gut gemacht!“ 🙂

Arbeiten an Fedora 34 starten

Die Arbeiten an Fedora 34 haben begonnen. Das neue Repo wird derzeit erstellt und die ersten Pakete sind bereits gebaut worden.

Arbeiten an Fedora 34 starten

Soweit ich erkennen kann, gibt es leider noch Probleme beim Rawhide Repo. Der Build ist leider gefailed. Macht nichts, denn dies war trotzdem der Startschuss fĂŒr Fedora 34 🙂

FĂŒr Fedora 31 User bedeutet es, sich langsam auf die Umstellung Richtung F32 einzustellen. Die Updates können entweder ĂŒber den Softwarecenter gemacht werden, der nervt ja sowieso schon seit Monaten damit, daß es Fedora 33 gĂ€be, oder ĂŒber dnf. dnf  hat den Vorteil, daß man im Verlauf wenigsten zusehen kann und weiß, wann das durch ungefĂ€hr durch sein wird.

Ich mag das Update mit dnf als Admin ja ohnehin lieber, weil man dann auch Fehler vorbeiscrollen sieht, die man behandeln und melden könnte. NatĂŒrlich hoffen wir alle, daß es keine geben wird 😉

 

TLS: Timing Attacke RACCOON

Intel kennt das Problem: Laufend kommt einer an und kann an der Laufzeit von Berechnungen Daten ableiten, die er nicht sieht. Jetzt ist mal wieder TLS dran mit so einem Angriff auf den DH SchlĂŒssel.

TLS: Timing Attacke RACCOON

Wie die Hacker News berichten, gibt es eine neue, aber sehr spezielle, Methode an einen ServerschlĂŒssel zu kommen. Voraussetzung ist allerdings, daß der Server seine verwendeten SchlĂŒssel erneut benutzt. Das sollte er wegen PFS sowieso nicht tun, aber nicht alle Dialekte von TLS 1.2 sind PFS fĂ€hig.

Um die LĂŒcke ausnutzen zu können, muß der Angreifer zu dem sehr prĂ€zise Messungen zur Laufzeit machen können, daher muß er technisch sehr dicht am Server dran sein, um die Messungen akkurat vornehmen zu können. In den meisten FĂ€llen wird der Versuch da bereits scheitern. Auch Scheitern wird der Angriff, wenn PFS zum Einsatz kommt, weil der Server den privaten DH SchlĂŒssel dann nicht wieder verwendet.

F5, Mozilla, Microsoft und OpenSSL haben schon Updates parat, wobei M$ sich darauf beschrĂ€nkt, die DHE einfach abzuschalten, statt das Problem zu lösen 😀 Auch ne Methode 😉 Wie man hier nachlesen kann: OPENSSL: https://www.openssl.org/news/secadv/20200909.txt hat OpenSSL das Problem in Ă€lteren OpenSSL Versionen bereits durch eine andere Defaulteinstellung behoben. Damit ist die GefĂ€hrlichkeit des Angriffs eher gering einzuschĂ€tzen.

Ich habe mir mal die MĂŒhe gemacht und konnte selbst in einer 2 Jahre alten OpenSSL Version den nötigen Cipher nicht und damit ist der Webserver auch nicht anfĂ€llig. Ein Test durch SSLLabs hat das bestĂ€tigt:

Uses common DH primesNo, DHE suites not supported
DH public server param (Ys) reuseNo, DHE suites not supported
ECDH public server param reuseNo

Also, keine Panik, wenn Ihr nicht 10 Jahre alte Software einsetzt, ist alles gut.