Dies ist meine persönliche Homepage. Sie ist ziemlich zweisprachig und deshalb hängt es von meiner Stimmung und Ihrem Glück ab, in welcher Sprache Sie hier die Dinge finden können.

Nachfolgend sehen Sie die letzten News. Um alle News in der gewünschten Sprache anzuzeigen, nutzen Sie bitte die Navigationsleiste links.


This is my personal homepage. It is quite bilingual and thus it depends on my mood and on your luck which stuff you will find in which language here.

Below you will see the latest news. To view all news in the desired language please use the navigation bar on the left side.

The sad state of eBPF15.05.2019

 eBPF could be cute. Really cute. One could do smart in-kernel network packet processing. Except that there's really huge roadblocks.

First of all there is no usable documentation. One has to collect bits and pieces from all over the internet. Then LLVM compiled stuff quite often does not fit the bill as efficient eBPF code needs to be runtime modifiable before it is loaded into the kernel. Now how one does this with compiler output in ELF format? Arrrghhh!

So I did write a little eBPF to C assembler (find it here). And things look great again. 11 registers, let's start developing - until the in-kernel verifier kills register usage. It looses track of r1 to r5 even on simple conditional branches. So 5 registers are so volatile that they are merely unusable. This still leaves 6 registers. Not quite so. r0 is quite often implicit soure or destination, so it is only half usable. r6 is expected to contain the context pointer you do need to be able to access the packet data. And r10 is the frame pointer that one needs to be able to call helper functions. So only r7 to r9 are left that one can actually use. Compared to cBPF which does have an accumulator and an index register (which I do count as a half register) you have 1.5 cBPF registers versus 3.5 eBPF registers. Not much improvement here.

Then you want to access packet meta data, e.g. the source address, from an eBPF program that is attached to a UDP socket. The data is there. But you are not allowed to access it. Doh.

Now you look at the helper functions and get the idea, it would be nice to move certain received packets to another socket. Could save userspace complexity. Go, try. EINVAL. Not only that one has to read through a pile of kernel code to find out that related code requires additional kernel configuration to be compiled in, the gods of eBPF added extra insult to injury by allowing packet transfer only for TCP. Why, only why??? Isn't UDP or raw packets even simpler than TCP? And what about SCTP? Did somebody pay to prevent socket transfer for raw and UDP sockets?

Then you don't want to enable the eBPF JIT system wide but only for "proven" eBPF code whereas code under development should be interpreted. To no avail. There's a huge slew of parameters to the bpf system call but there is no way to do a system wide "use JIT if told so" configuration option as well an no "I want JIT" bpf call option. Who designed that?!? Now, if JIT fails to work properly for a single eBPF program one has to disable eBPF JIT system wide. As Stephen King wrote: "new and improved" (Tommyknockers).

And then such stuff like eBPF cgroup programs. Oh, not programs, a single program per cgroup. You are allowed do more in a cgroup program. Except that cgroups are (ab)used by distros and it is not so easy just to create a cgroup here, a cgroup there, ... - without overall concept you will create a mess of your system and one really doesn't want an application to create cgroups on the fly, especially as there's no one there to clean up afterwards.

In the end it boils down that from an application point of view only socket filtering makes sense. And this is artificially so restricted that writing eBPF code for this purpose is not much fun. The only reason to do so is the dreadfull slowness of [e]poll.

All other network related eBPF use cases seem to be custom tailored for expensive and specialized big iron. So after all for the more common use case eBPF is sadly nothing more than a helper to workaround kernel slowness.

[e]poll bottleneck15.05.2019

 [e]poll on Linux is slow. Very slow. To be more precise: slow as a dead horse. 45us on a system where a clock_getttime syscall (yes, the syscall, not the vDSO) takes 335ns and a read call via library takes 4us. This is on a i7-7500U CPU @ 2.70GHz (not fast but not that slow).

So lets do some quick calculation for a process receiving a UDP packet and answering with another UDP packet: 45us epoll + 10us recvmsg + 35us sendmsg + 10us userspace data processing. So every single packet received and replied to takes 100us and only 10% of this time is actual packet processing. 50% of the remaining 90% is consumed by a single [e]poll call. And, yes, 100us means no more than 10000 packets per second and core which in case of 1K packet size resorts to a network throughput of only 80Mbit/s for a single core. This is horrible.

And there is no workaround, recvmmsg is more often than not unusable for an application as usually signalled data from [e]poll means a single received packet is pending. And if only a single packet has to be sent sendmmsg is unusable, too.

And this is why one should learn a little eBPF assembler (no, not LLVM compiled stuff, handcrafted code). Especially if the application in question may be attacked. The basic data checks need to be processed in-kernel as the epoll+recvmsg overhead is so huge.

Hopefully the responsible kernel developers will one day understand that [e]poll is a fast path and requires a race horse, not a dead one.

The sad state of smartcards on Linux22.12.2018

the idea is simple: use a smartcard reader or a CCID compliant USB token and get rid of passwords. Simple, isn't it? That's, until it comes to practice. First of all, many smartcard vendors are still going the vendor lock-in way and even with smartcards or tokens one can configure under Linux there are roadbocks:

There's a stack, consisting of the smartcard driver, e.g. CCID, then there's PCSC-Lite, then OpenSC, followed by libp11 and finally OpenSSL. All different developer groups, seemingly no real communication resulting more often than not in broken interworking or sudden parameter changes. Documentation is sparse at best, users are left alone in the dark, developers need to use trial and error. Furthermore certain functionality is missing with no easy way to push required code upstream.

Take for example the CCID driver. Suddenly smartcard names are changed. Nobody cares if this could make problems.

OpenSC developers don't take patches in unified format, one shall make a master degree in git usage first instead, bah! I still have to investigate why 0.19 does seemingly break libp11 and thus my applications.

As for libp11 there was once another library to be used instead which was abandoned - no information that libp11 was to be used instead. Then there's missing functionality, e.g. the 'door opener' slot of a smartcard doesn't need and doesn't want a pin, so let's patch...

OpenSSL engine documentation is, well, horrible as well as non existing. Reading the sources is not the way it should be.

Having to use library pathnames to configure the stack doesn't really help portability at all.

It's bad for developers and nearly impossible to use for end users.

Die Unsinnigkeit aktueller E-Autos06.12.2018

 Warum gibt es eigentlich (fast) keine Elektroautos mit vernünftigem Range Extender? Dafür aber PEHVs, die eigentlich für die meisten sinnlos sind? Oder Späßla für Spielkinder mit zuviel übrigem Geld? Mir kommt das so vor, als wollten die Hersteller auf Biegen und Brechen ihr Altmetall stur weiter an den Mann bringen, natürlich mit dem Trend zum Zweit- und Drittwagen.

Kalkulieren wir doch einmal für den Durchschnitts-Pendler, der auch noch Einkäufe erledigt und ab und zu einen privaten Ausflug macht. Dieser wird sicher nicht den heimischen Elektro-Hausanschluss mittels Bagger upgraden und dann noch heftige Verlegearbeiten inklusive einer entsprechenden Wallbox Installation durchführen lassen, nur um sein TöffTöff zu betanken. Die vorhandene Schuko-Steckdose in der Garage muss also reichen. Daraus ergibt sich folgerichtig eine Akku-Kapazität von 20KWh, um über Nacht volltanken zu können. Bei einer dann daraus resultierenden Motorleistung von 60KW ist also eine effektive Reichweite von 120km zu erwarten (Pendeln bedeutet meistens Rush Hour). Das reicht dann typischerweise für das Pendlerdasein und die Einkäufe.

Was aber nun mit den selteneren Fahrten in größere Entfernung? Die Autobauer sagen dann, nimm halt das Modell mit dem zwei Nummern größeren Akku. Unfug. Adios zum Laden zuhause. Zum Auftanken also zur nächsten Schnellladestation, sind ja nur 10km einfach, dann eine Stunde warten, bis man dran ist und anschließend 20 Minuten im strömenden Regen Fitnesstraining in der Hoffnung, dass der Ladevorgang nicht abgebrochen wird. Toll. Und zeitaufwändig.

Dabei gibt es doch eine durchaus vernünftige Lösung. So ein 20KWh Akku dürfte etwa 250kg wiegen (90Wh/kg für LiFePO4 netto). D.h. 750kg für 60KWh. Im Normalbetrieb werden also 500kg ungenutzt mitgeschleppt. Bleiben wir also beim 20KWh Akku und bauen einen Generator mit 20KW Festleistung, der nur mit optimalen Wirkungsgrad betrieben wird, ein. Dieser dürfte mit befülltem 20L Tank auch nicht mehr als 250kg wiegen. Somit sind schon einmal 250kg Ballast bezogen auf einen 60KWh Akku entsorgt. Bei einem Verbrauch von 10L/h ist dann aber eine äquivalente Reichweite gegeben. Und diese Reichweite kann an jeder Tankstelle in wenigen Minuten erweitert werden.

Ich höre jetzt aber schon die Fundamentalisten-Fraktion "aber das sind doch 8L auf 100km" schreien. Ja, stimmt. Aber es kommt doch auf das Mix an. Es wird doch niemand jenseits der SUV Fraktion (SUV=säuft unverhältnismäßig viel) freiwillig zur teueren Tanke fahren, wenn die preiswertere Steckdose in der heimischen Garage so nah ist. Und andererseits sind Schnelladestationen wohl noch eine ganze Weile so etwas wie eine vom Aussterben bedrohte Tierart, also sehr selten. Ich sehe auch schon bildlich die Knoten hunderter gekreuzter Verlängerungskabel nebst kommunaler Gehwegladeabgabe und Stolperhaftpflicht bei Fahrten jenseits der Akkureichweite als konsequente Folge.

Bleiben wir also realistisch und gehen einmal von 20% aller Fahrten mit aktiviertem Range Extender aus, was ein durchaus hoher Wert sein dürfte. Macht dann einen lokalen Spritverbrauch von 1.6L auf 100km. Und bei regenerativen Energiebezug für das traute Heim ändert sich daran dann auch global nichts. Somit ist der Verbrauch bei erhöhtem Einsatz des Range Extenders nicht schlechter als bei einem PEHV, bei normalerem Einsatz sogar deutlich besser.

In der Summe bedeutet dies ganz einfach, dass bezahlbare und bei Bedarf reichweitenstarke Elektroautos für eine breite Masse durchaus machbar wären, wenn Industrie und Politik nur genügend Interesse daran hätten. Und nein, ich bin kein Wollsocken-Fundi, ich denke einfach nur pragmatisch.