Pinephone: Fedora Pinephone im PineTalk Ep. 4

Moin,

es ist echt keine Absicht gewesen, ich habe durch Zufall bemerkt, daß der kleine Video-Chat Stunt mit meinem Fedora Pinephone in den PineTalk Episode 4 geschafft hat 🙂

PineTalk kann man direkt im Netz hören: https://www.pine64.org/pinetalk/

Wenn wir schon dabei sind, heute morgen habe ich das Workstation Image von Fedora für Pinephone ausprobieren können. Es ist also das normale Workstation Image um Pinephone Sachen ergänzt.

Gnome 40 kommt ohne GDM und damit ohne den GMD Bug der 100% CPU braucht. Dafür funktioniert es dann auch ganz gut. Allerdings fehlt da immer noch die Swipegeste um die Appauswahl aufzurufen.

Nicht alles skaliert darauf richtig, aber für ein Nightly Image wars gut. Ich habe nur 43 Verbesserungen oder Bugs gefunden 😉 Was wirklich cool ist, ist der neu Bootloader:

Da es das Workstation Image ist, bootet es dann auch gleich mit dem Fedora Logo:

Das macht natürlich alles etwas mehr Endkundenkonform. Auch der Updateprozess, wenn man über die normalen Fedorawege etwas installiert oder aktualisiert, wirkt mehr Professionell auf dem Handy. ( Leider kein Bild vorhanden )

Ich persönlich update via dnf ohne Reboot, aber hier kommt immer gleich ein Neustart ins Spiel. Das ist wie bei Windows und ich mags nicht wirklich, aber auf dem Pine hat es ein gewissen Charme 😉

 

Wenn das Image weiter entwickelt ist, stelle ich Euch das mal genauer vor 😉

Pinephone: Autorotation – neuer Device Tree ändert Device ID

Posted on by

Liebe Linuxphones Fans,

im kürzlich erst erschienenen Artikel:

Pinephone: automatische Screenrotation einschalten

wird das Device 2 als der Beschleunigungssensor benutzt. Ein Update des Pinephone dtb ( Device Tree Binary ) in dem die verbauten Sensoren des Pinephones beschrieben sind, änderte letzte Woche durch ein Update die Device ID des Beschleunigungssensors.

Pinephone: Autorotation – neuer Device Tree ändert Device ID

ich Euch da mal eine kleine Autoerkennung gebaut:

#!/bin/bash

COUNT=$(ps auxf | grep -v grep| grep -c autorotate)

if [ $COUNT -gt 2 ]; then 
	killall -9 autorotate
	exit
fi

# Autodetection

DEVID="iio:device2"

DEVICES=$(ls /sys/bus/iio/devices/)
for dev in $DEVICES; do
	if [ -f /sys/bus/iio/devices/$dev/in_accel_x_raw ]; then
		DEVID="$dev"
	fi
done

OLD=""

while :
do
	X=$(cat /sys/bus/iio/devices/$DEVID/in_accel_x_raw)
	Y=$(cat /sys/bus/iio/devices/$DEVID/in_accel_y_raw)
	Z=$(cat /sys/bus/iio/devices/$DEVID/in_accel_z_raw)

	if [ $X -gt 15000 ] && [ "$OLD" != "N" ]; then
		# portray mode
		wlr-randr --output DSI-1 --transform normal
		OLD="N"
	fi
	if [ $Y -gt 15000 ] && [ "$OLD" != "90" ]; then
		#Landscape 90
		wlr-randr --output DSI-1 --transform 90
		OLD="90"
	fi
        if [ $Y -lt -15000 ] && [ "$OLD" != "270" ]; then
                #Landscape 270
		wlr-randr --output DSI-1 --transform 270
		$OLD="270"
        fi
	sleep 0.5
done

Damit geht es jetzt immer.

RCE Lücke in smartem Stromzähler

Posted on by

Das ein Gericht das BSI gerade daran gehindert hat, einfach die Anforderungen an die Zulassung von smarten Stromzählern zu senken, war eine mehr als positive Entscheidung. Wie sich zeigt ist die Sicherheit von smarten Stromzählern essentiell.

RCE Lücke in smartem Stromzähler

ThreadPost berichtet in einem Artikel vom 12.3. von einer ungepatchten Sicherheitslücke in einem „Schneider Electronic PowerLogic ION/PM Smart Meter“:

„Critical security vulnerabilities in Schneider Electric smart meters could allow an attacker a path to remote code execution (RCE), or to reboot the meter causing a denial-of-service (DoS) condition on the device.“

Dies Modell wird zwar nicht in Deutschland eingesetzt AFAIK, zeigt aber wie wichtig die Sicherheitsfrage bei diesen Geräten ist. Die fraglichen Geräte hängen wohl am Internet und sind so Angriffen ausgeliefert. Wieso man da bitte nicht mal eine Firewall vorsetzt, die Verbindungen nur vom zuständigen Datacenter zulässt, wird wohl niemand von der Firma beantworten wollen.

Dieses spezielle Smartmeter kann komplett übernommen werden, oder alternativ geDOSt werden, also an der Arbeit gehindert werden. Wenn ich so eine Lücke hätte, wüßte ich was das Smartmeter messen lassen würde: Das ich im Urlaub bin und nur der Kühlschrank läuft 😉  „Ist halt gehackt worden“, falls jemand die Frage stellt, wieso die Leitungen rot leuchten 😉

Das Schlimme an der Sache ist, daß solche Geräte mal wieder in Rechenzentren und Medizinischen Einrichtungen stehen. Damit sind diese Geräte, denen man den Hack nicht ansieht, dann Einfallstore für weitere Attacken. Wie man dem Bericht weiter entnehmen kann, ist wohl der ganze interne Softwarestapel schlampig zusammen gebaut worden:

“We found that the advance_buffer function always returns true, regardless of other inner functions failing and returning false. „

Das meint, daß egal ob eine Unterroutine die Rote Leuchte rausstellt und den Aufrufer darauf hinweist, daß es nicht geklappt hat, macht die aufrufende Routine einfach weiter. Das nennt man im Fachjargon „Fire & Forget Code“. Dieser geht immer davon aus, daß das was er tut funktioniert. Eine Fehlerbehandlung ist nicht vorgesehen. Und genau das fällt diesem Smartmeterhersteller jetzt auf die Füße. Aus Programmierersicht habe ich da jetzt kein Mitleid, weil das ist einfach nur schlampig zusammen gebastelt worden.