8-bit Linux Machine

I respect the amount of dedication and genius that went into this effort. While nothing new, it’s totally CRAZY.

This project takes the Church-Turing thesis to an extreme. In essense, it states that “everything algorithmically computable is computable by a Turing machine.”

Some may wonder how he managed to get it all to work. So, let’s break it down a little:

CPU
According to the thesis, any CPU is able to emulate the operations of another CPU. So, while the AVR is an 8-bit micro, it can definitely be used to emulate all the complex functions available on the more powerful ARMv5 in software.

As an example, if I needed to do a 32-bit addition, all I would need to do is to do four 8-bit additions factoring in the Carry bits. So, depending on whether the 8-bit architecture supported a Add with Carry instruction, I might need to do an additional three 8-bit additions for a total of seven additions. In the end, I’d still end up with a 32-bit addition.

For many 8-bit microprocessors, there are already existing libraries to do such things because it is a fairly common requirement as 8-bit microprocessors find use in all sorts of unexpected applications where they might need to do 32-bit calculations anyway.

Take this analogy further, you can also do floating-point calculations emulated in software on a pure integer machine. This is done all the time, even on full fledged ARM architectures. In actual fact, all you’d need to build any computer in this world is a 1-bit computer.

RAM
This is where the 16KB RAM in the 8-bit micro has serious deficiencies. Linux would typically need several megabytes of RAM. Therefore, the project included an external 16MB of RAM. While some may argue that we still need more than 16MB of RAM, it isn’t exactly true. The internal 16KB would be used to emulate more of a cache than primary memory.

In a modern computer, memory is just a hierarchy of storage devices. RAM is just a convenient method of doing it. If there isn’t enough RAM, we can always emulate the RAM as well, using virtual memory, which is what most desktop PCs used to do in the past by exploiting some of the hard disk.

From all indications, this project had a 1GB SD card attached to it for storage needs. This included the Linux OS plus file-system. So, it could boot off this SD card and also use part of it as a swap if necessary. Swapping can both be done in the OS or even emulated by the 8-bit micro.

However, the speed of the device would be another limiting factor. Most 8-bit micro communicate with SD cards using the SPI protocol at a maximum clock of 25MHz. This means that it has a theoretical maximum transfer rate of only 3MB per second – about the speed of a 20x CD-ROM drive.

If I were adventurous, I might even emulate a CD-ROM drive. This way, I could run a Live-CD Linux distribution on one partition, while using another partition to emulate a mass storage device such as a hard-disk drive. That might prove interesting as well.

I/O
This is where I think that he had to emulate a lot more stuff. While 8-bit micros may be low on brain power, they are typically full of all sorts of I/O devices. However, the project would need to emulate a whole bunch of things to get Linux started.

I gather from the video that the standard inputs and outputs are routed through the serial port of the AVR. This can typically be done in Linux by simply specifying a kernel parameter console=/dev/ttyS0. Then, the emulator would need to emulate the necessary calls to read from and write to the console.

If he wanted to emulate the mouse and keyboard, it would also be very possible as the PS/2 protocols used have been emulated in 8-bit micros for a while. There are some devices that use 8-bit micros as pretend keyboards and mice e.g. a key-logger or a password dongle.

If he wanted to emulate a video card, it is also possible as 8-bit micros have been used to generate full frame video in emulation, largely by using PWM signals to emulate the analogue signals of a VGA connection. While it will be severely speed limited, it should be able to do at least a low-level VGA frame buffer.

He could even go as far as adding in ethernet if he so wished. Some 8-bit micros these days have built in ethernet MACs. However, adding USB host capability might be a bit tricky as most 8-bit micros do not have USB OTG capabilities as yet.

So, there we have it. A quick and dirty run-down of it.

Christian Hacking

I’ve just read an article on The Economist on how hacking is a very Christian thing to do – and so is Open-Source. Let me just quote a couple of parts of the article:

Mr Spadaro says he became interested in the subject when he noticed that hackers and students of hacker culture used “the language of theological value” when writing about creativity and coding, so he decided to examine the idea more deeply. “In a world devoted to the logic of profit,” wrote Mr Spadaro, hackers and Christians have “much to give each other” as they promote a more positive vision of work, sharing and creativity.

Catholic open-source advocates have founded a group called Elèutheros to encourage the church to endorse such software. Its manifesto refers to “strong ideal affinities between Christianity, the philosophy of free software, and the adoption of open formats and protocols”. Marco Fioretti, co-founder of the group, says open-source software teaches the “practical dimension of community and service to others that is already in the church message”.

Don Parris, a North Carolina pastor, wrote an article in Linux Journal in 2004 in which he argued that “proprietary software limits my ability to help my neighbour, one of the cornerstones of the Christian faith.”

While I agree that there are very theological and religious reasons to hacking, it is definitely not in-line with the Christian faith as mentioned in the article:

Moreover, hackers in particular have problematic traits from the perspective of the Catholic church, such as a distrust of authorities and scepticism toward received wisdom. And the idea of tweaking source materials to fit one’s needs doesn’t mesh well with the Catholic emphasis on authority and tradition.

Exactly. Most hackers identify more with Buddhist traditions as typified in Hacker’s Zen and enshrined in the Jargon File. Hacker culture can be easily reconciled with Buddhist traditions and in fact, I would go as far as to say that the Buddha, is a hacker himself – in the sense that he tinkered with and hacked the human condition.

The main reason is because of the fundamental clash of hacker and Christian traits – hackers generally do not take to faith – as mentioned by Eric S Raymond in the article:

Mr Raymond took to his own website to note that he had deliberately equated cathedrals with proprietary, closed-source software directed from above, by contrast with the more chaotic bazaar of equals which produces open-source code. “Cathedrals – vertical, centralising religious edifices imbued with a tradition of authoritarianism and ‘revealed truth’ – are the polar opposite of the healthy, sceptical, anti-authoritarian nous at the heart of the hacker culture,” Mr Raymond declared.

As for Mr Spadaro’s ideas, they possessed a “special, almost unique looniness”.

So, while Christians may want to lay some claim to the hacker culture, ethic and ethos, the hackers have already spoken.

Storing Passwords in the Cloud?

There’s been a recent event at LastPass and users have potentially lost their passwords. Honestly, I wonder why would anyone ever store their passwords anywhere, much less in the Cloud?

Good security practice dictates that passwords should never be stored at all. Period.

While we should use random passwords with different ones for different sites, and it is difficult for users to remember so many meaningless passwords across so many different sites, it is no excuse to store passwords.

IMHO, the ideal solution for this would be to use generated passwords. These passwords could be generated from multiple secrets that are known only to each individual, but not to everyone. Think of it has having different parts of a dollar.

One example would be to use something like password hash, which would generate the password based on the website domain name and a known secret. Try it out and you’ll see.

There are more complex schemes that can be invented if necessary but the idea is there – don’t store the passwords anywhere – generate passwords on-the-fly.

Securing My Blog

In order to improve the security of my blog, I have tried a few measures.

A while ago, I bought a Yubi-Key, which generates a one-time-password to be used alongside the regular login. This provided two-factor authentication and it was certainly working for a while. Then, I read up more about the Yubi-Key and found that there might be holes in the implementation of the plugin since it is still quite a new product and relatively untested.

So, I switched to using VPN instead. I configured my web-server to reject all attempts to access the administrative pages unless the connection originated from the local server. Then, I would use SSH to create a tunnel into the server and secure my connection through SSH keys. This also required two-factor authentication and provided the additional fact that the entire connection was secured over SSH.

I added this to my lighttpd configuration.

# Deny access to wordpress admin pages
$HTTP["host"] =~ "blog.sybreon.com|tech.sybreon.com" {
$HTTP["remoteip"] !~ "213\.229\.116\.90$" {
$HTTP["url"] =~ "^/wp-admin/|^/server-" {
url.access-deny = ("")
}
}
}

However, I had troubles accessing my blog from certain places because they blocked SSH connections.

Finally, I switched to SSL instead. I have now configured my web-server to only accept connections that present a valid security certificate over SSL. Again, this is a two-factor authentication using SSL certificates. Once again, the connection is also secured over SSL. I park my web server behind a pound reverse-proxy. So, this is the way I did it.

ListenHTTP
Address ::
Port 80
## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
xHTTP 0

Service
URL "^(?!/wp-admin).*"
HeadRequire "Host:.*(blog|tech).sybreon.com"
BackEnd
Address ::1
Port 8080
End
End

End

ListenHTTPS
Address ::
Port 443

Cert "/etc/ssl/private/blog.crt"
CAlist "/etc/ssl/private/sybreon.ca.asc"
VerifyList "/etc/ssl/private/sybreon.ca.asc"
Ciphers "HIGH"
ClientCert 2 3

Service
HeadRequire "Host:.*(blog|tech).sybreon.com"
BackEnd
Address ::1
Port 8080
End
End
End

What this does is to reject all connections to the admin pages for my blogs if they came over regular HTTP and to only allow connections over HTTPS. However, for HTTPS connections, client certifications are required, which are signed by a my own custom CA. Otherwise, the connection will fail if a client certificate is not presented.

The advantage of doing it this way is that I can actually have collaborators. All I need to do is to generate new certificates for them and email it to them. This process can even be automated if need be.

PS: You can try accessing the admin page over HTTP and HTTPS here, to see how this works.