Among other interesting keying methods, the new yubikeys support OATH-HOTP, one of the authentication mechanisms of the Open Authentication initiative. The key and the server are initialized with a shared secret, and a counter initialized at 0. The secret is repeatedly hashed with the incrementing counter to generate unguessable one-time passwords. There’s a little more to it, but that’s the gist of it.
So, I want to use my yubikey to authenticate to my dedicated linux server, with OATH-HOTP. Since my server is shared with people who don’t have yubikeys (and are garrisoned in locked down accounts :) ), I needed a hybrid solution that allows traditional logins for some, and OTP logins for others.
I was successful, and here’s how to do it.
First, let’s define more specifically what we want. We want two types of users, a low security user and I high security user.
When a low security user authenticates, they enter their unix password, and everything works just fine.
When a high security user authenticates, they enter a password, and without hitting enter, they trigger their yubikey, causing an OTP to be appended to the static password. The authentication checks both the OTP and the static password before succeeding.
If a high security user loses their OTP token, they can instead authenticate using a very long and very random emergency password. This is nice for situations like the administrator losing his OTP token to log in as root, thus blowing his ability to regenerate his own OTP credentials.
Note that this setup enforces something often forgotten about OTPs: the OTP is a component in 2 factor authentication. If users are prompted for just an OTP, it would simply prove that whoever is authenticating has stolen a yubikey. Combining the static password with an OTP associates something the user knows and something the user has, which requires the unlikely simultaneous theft of both to be of use to the attacker.
Okay, so, what do we need?
First, we need to get the server to understand OTPs. This requires installing the pam_hotp module, which is not yet widely available. Furthermore, we need to install my slight fork of the module, which fixes some nasty bugs that got in the way of doing what I’m about to describe.
So, clone my copy of hotp-toolkit, and install it on the server. You’ll need the autoconf/automake build tools, and a few other things. On ubuntu, the packages you need are build-essential, autoconf, automake, gengetopt and libpam-dev.
$ git clone git://github.com/danderson/hotp-toolkit.git
$ cd hotp-toolkit
$ autoreconf --install
$ ./configure && make && sudo make install
This will install the PAM module at /usr/local/security/pam_hotp.so. You need to symlink that into /lib/security so that PAM can find it.
# cd /lib/security && ln -s /usr/local/security/pam_hotp.so .
Now, let’s install the module in the authentication chain, and give it a test drive. To be safe, we won’t immediately hook it into all of the system’s authentication, so that we don’t lock ourselves out. We’ll practice on su’s configuration only. That way, sudo would still let us in without an OTP in an emergency (configure your sudoers!) and we get to hang onto any root terminals we already have.
Edit /etc/pam.d/su. You should have something like this (comments removed for brevity):
auth sufficient pam_rootok.so
@include common-auth
@include common-account
@include common-session
This means: if root wants to become root, let him, and pass anything else onto the common authentication setup for the system. We want to subvert that temporarily, and instead invoke pam_hotp for all authentication business.
auth sufficient pam_rootok.so
auth sufficient pam_hotp.so usersfile=/etc/users.hotp window=10 digits=8 debug
auth requisite pam_deny.so
#@include common-auth
@include common-account
@include common-session
If you’re not familiar with what “sufficient” and “requisite” mean in the context of PAM, I suggest catching up around now with the PAM manual, because we’re going to be doing quite a bit of it as we perfect the setup.
To summarize, here we’re saying: if pam_hotp successfully authenticates the user, then that authentication is all we need, and there’s no need to try other modules. However, if we hit pam_deny (which fails no matter what), then the authentication attempt should fail completely. Even more summarized: try to authenticate with an OTP, and reject the attempt if that doesn’t work out.
An aside on the window parameter: this tells PAM how many OTPs in the sequence it should try before failing. Here, we say that your key and the server can be desynchronized by up to 10 OTPs. So, if you accidentally output a couple OTPs too many with your yubikey, as long as the key isn’t leading the server by more than 10 OTPs, the server will resync the next time you authenticate.
Before we can test, we also need a user file, which defines the OTP secrets. So, create the file /etc/users.hotp:
HOTP/E/8 root - 00000000000000000000000000000000
The format of the user file is quite simple: there is one line per user, in the form <OTP type> <username> <password> <HOTP secret>. We said in the PAM configuration that the OTP is 8 digits, which means we have to specify a type of HOTP/E/8 here. There is also HOTP/E/7, HOTP/E/6, and HOTP which is shorthand for HOTP/E/6. What they do should be pretty obvious.
We currently don’t define a password, just to get started, but that is the important part of making the 2-factor authentication actually 2-factor. And, finally, the secret is a 32 character hex string that the server and yubikey have in common. Here I just put in all zeros for testing, we’ll see how to generate a better one later on.
Oh, and don’t forget to chmod 600 and chown root:root the user file. If someone gets their hands on the OTP secret, they can generate valid OTPs, which would be bad.
Now, all we’re missing for testing are a couple of OTPs. Instead of configuring the yubikey right away, we’ll use hotptool, which came with pam_hotp, to generate a couple of them:
$ hotptool -w5 -d8 00000000000000000000000000000000
35328482
30812658
41073348
81887919
72320986
76435986
The tool just gave us the 5 first OTPs for a secret of all zeros. Please don’t use all zeros as your production secret :).
Now, finally, we can test. As a normal user, try to su to root with that first OTP. You should be successful, with lots of spammy debug output from pam_hotp.
$ whoami
dave
$ su
[pam_hotp.c:parse_cfg(118)] called.
[pam_hotp.c:parse_cfg(119)] flags 0 argc 4
[pam_hotp.c:parse_cfg(121)] argv[0]=usersfile=/etc/users.hotp
[pam_hotp.c:parse_cfg(121)] argv[1]=window=10
[pam_hotp.c:parse_cfg(121)] argv[2]=digits=8
[pam_hotp.c:parse_cfg(121)] argv[3]=debug
[pam_hotp.c:parse_cfg(122)] debug=1
[pam_hotp.c:parse_cfg(123)] alwaysok=0
[pam_hotp.c:parse_cfg(124)] try_first_pass=0
[pam_hotp.c:parse_cfg(125)] use_first_pass=0
[pam_hotp.c:parse_cfg(126)] usersfile=/etc/users.hotp
[pam_hotp.c:parse_cfg(127)] digits=8
[pam_hotp.c:parse_cfg(128)] window=10
[pam_hotp.c:pam_sm_authenticate(157)] get user returned: root
One-time password (HOTP) for `root':
[pam_hotp.c:pam_sm_authenticate(232)] conv returned: 35328482
[pam_hotp.c:pam_sm_authenticate(291)] OTP: 35328482
[pam_hotp.c:pam_sm_authenticate(302)] authenticate rc 0
last otp Sat Jun 27 01:30:32 1931
[pam_hotp.c:pam_sm_authenticate(325)] done. [Success]
# whoami
root
#
Now, if you try to reauthenticate with the same OTP, you will be denied, but the next one in the sequence works. Congratulations, you’ve set up OTP authentication for su! Take a look in /etc/users.hotp, you’ll see the original line has grown, and now contains the counter state that lets PAM keep track of which OTPs are valid.
Okay, so we’ve got the basics: we know how to get prompted for an OTP, and validate it. Now let’s claw our way up to the requirements we had at the beginning, starting with making the authentication 2-factor instead of 1-unusual-factor.
For that, simply fill in the password field of the HOTP user file, as follows. Note that I removed all the fields our authentication attempt added, which resets the counter to 0 and lets me reuse the same five OTPs while debugging. On a production system, you shouldn’t delete that state, since it would make past OTPs valid again.
HOTP/E/8 root supersecret 00000000000000000000000000000000
Now, to authenticate, the user has to type in the password, immediately followed by the OTP. So, for the all-zeros secret, the correct answer to the first su invocation would be “supersecret35328482”, the second would be “supersecret30812658”, and so on. Give it a whirl, and check that the debug output says that both password and OTP are found:
[pam_hotp.c:pam_sm_authenticate(232)] conv returned: supersecret35328482
[pam_hotp.c:pam_sm_authenticate(273)] Password: supersecret
[pam_hotp.c:pam_sm_authenticate(291)] OTP: 35328482
That’s nice, but not terribly nice. Cleartext passwords aren’t ideal here. Fortunately, my fork of hotp-toolkit supports crypt(3) passwords, which lets us use a password hash instead of cleartext. It’s slightly annoying to generate said password hash, but here’s a bit of Python that does it for you:
#!/usr/bin/env python
from crypt import crypt
from getpass import getpass
from sys import exit
user = raw_input('Username: ')
passwd = getpass('Password:')
repeat = getpass('Repeat password:')
if passwd != repeat:
print 'Passwords do not match'
exit(1)
rand = open('/dev/urandom')
salt = rand.read(8).encode('hex')
secret = rand.read(16).encode('hex')
hash = crypt(passwd, '$6$%s$' % salt)
print 'HOTP/E/8 %s %s %s' % (user, hash, secret)
The script actually generates a complete line for the users file, including a password hashed with random salt and a random OTP secret. If you use it to generate a new configuration for root (and obviously use hotptool to generate the corresponding OTPs, if you don’t use all zeros), you should still be able to authenticate with the combination of your static password and the correct OTP.
All we’re missing now on the server side is graceful integration with non-OTP users. Right now, if we were to deploy our current configuration site-wide, only OTP users would be able to log in. So, we need to configure PAM to allow either of a Unix password or an OTP password + OTP to authenticate. To do this, modify the configuration for su like this:
auth sufficient pam_rootok.so
auth sufficient pam_unix.so nullok_secure
auth sufficient pam_hotp.so usersfile=/etc/users.hotp window=10 digits=8 use_first_pass
auth requisite pam_deny.so
#@include common-auth
@include common-account
@include common-session
Note that I removed the debug from pam_hotp’s line, but feel free to add it back while testing this setup, to see what’s going on.
So, here we’ve added an extra preliminary step: we first give a chance to pam_unix, which will prompt the user for a password, and try to validate it against the usual /etc/shadow. If that works, then authentication is complete.
However, if it fails, PAM falls through to pam_hotp, where we’ve cunningly added use_first_pass. This directive tells pam_hotp to reuse the password that was provided to pam_unix. That way, all users get a single “Password:” prompt. Normal users enter their password, OTP users enter the password+OTP phrase, and either method will work if you have the right credentials.
An additional twist to this is that even OTP users have the escape hatch of the unix account: root can authenticate with an OTP, but if he enters the correct Unix password, he can still log in and shunt the OTP part.
This allows us to implement the third part of our initial requirements: by setting the Unix password to something long and random, we give ourselves an escape hatch from the OTP system, in case the OTP token is stolen. If it’s not stolen, the OTP password is much less complex, which encourages the user to not be lazy (if the unix password were too simple, he’d just not use 2-factor authentication).
I recommend pwgen -nys 32 for suitably horribly long, random, complex, impossible to use every day passwords for the unix account. This backup password is meant to be written down and stored somewhere safe.
Now that we have the server side nailed down, let’s move to the client side. How do we configure a yubikey to generate the correct OTPs?
First, we need the yubikey personalization tool, to reprogram the key. You need a very recent version of the tool (HOTP support is recent). If you want a quick way to build from source on Ubuntu, you can use this script that I wrote. You’ll need the whole repository (for support libraries), and you’ll also need to source the paths.sh file into your shell, so that it can find the tool and associated libraries. Check that ykpersonalize -h has oath-hotp in the list of options.
Now, you need the random OTP secret you generated just above with the python script. This is the part where you synchronize the server and the key. Let’s say that you ran the script, and it gave you 336e6a7b93d5f87a0c84ab9c7c8cdeab as the OTP secret. To program your yubikey, plug it in, and run:
$ ykpersonalize -1 -ooath-hotp -ooath-hotp8 \
-ouid=000000000000 -a336e6a7b93d5f87a0c84ab9c7c8cdeab
Firmware version 2.1.2 Touch level 1859 Program sequence 3
Configuration data to be written to key configuration 1:
fixed: m:
uid: h:000000000000
key: h:336e6a7b93d5f87a0c84ab9c7c8cdeab
acc_code: h:000000000000
ticket_flags: APPEND_CR|OATH_HOTP
config_flags: SHORT_TICKET|OATH_HOTP8
Commit? (y/n) [n]: y
$
Now, if you trigger your yubikey, with the above secret, it should output 47059834. Trigger it again, it says 79242647. Again, 42319411. Does hotptool agree?
$ hotptool -w3 -d8 336e6a7b93d5f87a0c84ab9c7c8cdeab
47059834
79242647
42319411
Bingo! Try using your yubikey with su. Don’t forget to type in your static password first, before triggering the key.
Now that we’re all ready, we just need to move the PAM config from su’s configuration to the global authentication configuration. Copy the three custom auth lines from /etc/pam.d/su into /etc/pam.d/common-auth, before any existing uncommented auth statements. Leave the existing block alone, apt will want to mangle it if you ever apt-get install PAM modules. Also revert /etc/pam.d/su to its original configuration.
And, finally, the moment of truth, try logging into your server, first with a legacy non-OTP account, then with an OTP account using the yubikey, and finally with the horrible backup unix password for that account.
Successful? Congratulations, you are now using 2-factor authentication with a physical key to generate OTPs! You gain 20 nerd points, unlock the paranoid geek achievement, and are somewhat more metal than you used to be. Enjoy!
It started out with helping a friend debug code for a primality testing routine. I then started to wonder how I would define such a function in Haskell. It’s a reasonably simple exercise in thinking pure thoughts in Haskell, and if you want to give it a try I suggest trying now, before reading on.
Still here? So, we want to define a function isPrime, having a type of Integer -> Bool. We’ll use the straightforward primality testing algorithm for now: a number N is prime iff no prime number up to sqrt(N) divides it.
So, how would we implement this in Haskell? First, let’s make an assumption. Let’s assume that we have at our disposal an ordered list of prime numbers, from 2 up to infinity and beyond.
primes :: [Integer]
As an aside for my readers who are not familiar with Haskell, I should point out that Haskell is a so-called lazy language. This means, among other things, that you can define infinite lists without having your program hang for ever. While the list is technically infinite, the lazy nature of the language means that its elements will not be computed until they are actually needed.
Now, you might call me out here for begging the question: if I already have a list of all the primes, then I have no need to test numbers using the algorithm above. However, let’s disregard that for a second and see where it takes us.
Given the list of all primes, we need only the primes from 2 to sqrt(N):
candidateFactors :: [Integer]
candidateFactors n = takeWhile (\x -> x*x <= n) primes
This reads reasonably well as English: take elements from the primes list, until an element causes the lambda function to fail. Next, we need to check whether any of these cleanly divides N. Fortunately, the Haskell Prelude has just what we need, and we can without further ado define isPrime:
isPrime :: Integer -> Bool
isPrime n = all (\x -> n `rem` x /= 0) (candidateFactors n)
Again, this should be fairly straightforward to read: N is prime iff, for all candidate factors X, the integer division of N by X is not clean (that is, X is not a factor of N).
This definition of primality is very clean and concise, and not very far removed from the mathematical definition. This is fairly common in Haskell.
However, we must now go back and figure out what to do with our initial bluff: this nice primality predicate assumes the existence of a list of prime numbers from which to draw candidate factors. But this list doesn’t exist, and unless we’re prepared to enter all primes from 2 to infinity by hand, we need a way of programmatically defining that list.
Let’s now reverse our assumption. Assume that we have an isPrime function, with an implementation based on magic, which can tell us whether or not a number is prime without using the primes list. Given isPrime, it is of course trivial to define primes:
primes :: [Integer]
primes = 2 : filter isPrime [3,5..]
This should be read in two parts, centered around the colon: first, on the right, we take the infinite list of all positive odd integers, and filter it using isPrime to retain only the prime numbers. Then, we tack 2, the only even prime, onto the front of that list, and voilà! One infinite list of all the prime numbers.
We are currently high in the spheres of academic code: nice, but quite useless, because we assume too big a part of the solution. This is where it gets fun: let’s remove the two assumptions, smush the two code snippets together, and see what remains:
primes :: [Integer]
primes = 2 : filter isPrime [3,5..]
isPrime :: Integer -> Bool
isPrime n = all (\x -> n `rem` x /= 0) candidates
where candidates = takeWhile (\x -> x*x <= n) primes
Here’s the kicker: the above code compiles, and correctly produces an infinite list of all the prime numbers.
Why? isPrime relies only on primes up to sqrt(N) to decide if N is prime. Examine the base case of determining the primality of 3 given a list containing only 2, and you’ll find that it works correctly. After that, the length of the primes list grows faster than the length of the prefix that isPrime needs to give a primality verdict for the following number (compare f(x) = x and f(x) = sqrt(x)).
I find this definition of prime numbers absolutely delightful. It has a wonderful zen-like quality to it, and yet successfully gets away with defining the list of prime numbers in terms of itself. Even better, it turns out that this implementation is quite efficient as well! The Haskell compiler is capable of turning this roundabout definition into a fast prime number calculator.
After posting this to #haskell to share this delightful definition (which, of course, most of them had already seen - the joys of being new to a language!), I was directed to a research paper by Melissa O’Neill, in which she goes over various Sieve of Eratosthenes implementations, and shows how this beautiful definition can be made even more efficient. Another paper on my stack of books, papers, manuals and novels to read…
How easily does your language of choice let you define a reasonably efficient Sieve of Eratosthenes?
]]>One side-effect is that comments are disabled, but given the post and comment traffic before this change, I don’t think it’ll be too missed :-).
If you haven’t changed yet, please update your feeds if they still point to natulte.net, as I’m going to be putting another site up there shortly. The correct feed URL is in the related links for the blog: http://blog.natulte.net/atom.xml.
The blog is not yet complete from the layout POV. Most notably, I’m missing easy access to the archives and to the tag cloud. Unfortunately, the site got pressed into service earlier than I planned, when I accidentally nuked my server and had to reinstall everything. Watch this space.
]]>What do I mean by changelogs? Historically, the term has meant something akin to “Our version control system sucks, we need to keep track of logical changes by hand”. This leads to a “changelog” that looks something like this:
1999-03-24 Stan Shebs address@removed
* configure.host (mips-dec-mach3*): Use mipsm3, not mach3.
Attempt to sort out SCO-related configs.
* configure.host (i[3456]86-*-sysv4.2*): Use this instead of
i[3456]86-*-sysv4.2MP and i[3456]86-*-sysv4.2uw2*.
(i[3456]86-*-sysv5*): Recognize this.
* configure.tgt (i[3456]86-*-sco3.2v5*, i[3456]86-*-sco3.2v4*):
Recognize these.
If you’re like any developer not involved with the project, that changelog entry is a complete parse error. You have no idea what the actual change is, whether you should care, whether the change was cosmetic or semantic… A compiler analogy would be that if the version control logs are machine code, this is a barely decorated disassembly.
Humans generally don’t want to read a disassembly of version control logs. They want to know what changed at a higher, human level, units of change that can be grokked in terms of new tools available to them, new syntax, new libraries, what they need to change in their data to ensure compatibility…
A good changelog doesn’t just disassemble version control logs. It presents an executive summary of a whole slew of changes, in terms that make it clear why I, the end user, should be giving a damn.
Thanks for your attention.
]]>I’m heading out to California for a week or so. My towel is in my travel bag. Where is yours?
]]>Yesterday, I played Wii Sports for 5 hours. Today, I have aches in muscles I’d forgotten I had.
That was fun.
]]>It all started when Google gave me an awesome Christmas present: An HTC Dream. It’s a very shiny mobile phone, and what’s more, it’s an unlocked developer edition. It’s hacking time!
This is where things get a bit complicated. Lemme take you through the reasoning.
My first idea when I saw this beast was to try to get emulators running on it. A phone is nice, but a phone that can play vintage games is even better. I decided on playing with the Sega Genesis first, as I have rather fond memories of Sonic the Hedgehog.
First obstacle: Android (the open source OS that Google develops) currently can run only Java code. There is currently no open source Genesis emulator written in Java. Most of them are written in C, or in extreme cases, even in x86 assembler. There is currently no official way to execute native code on the android phone. I’d like to make this software available to everyone.
I therefore need to write a Genesis emulator in Java.
Okay, that should be simple. The Genesis is a relatively old console, so it can’t be too elaborate. I mean, it’s no PS3. All I need is an emulator for the CPU, a decoder for the ROM format, and some audio and graphics hookups within Android, and I should be good to go.
Well, first, the Genesis has three processors. A Motorola 68000 CPU, a Z80 sound processor, and a custom made graphics processor. Let’s start with the 68k CPU. Apparently, there is no well known open source Java emulator for the 68k.
I therefore need to write a Motorola 68k emulator in Java.
But Java sucks. I mean, it’s obviously a successful language, but I find no pleasure at all programming in Java. It is pure pain without an IDE on the level of Eclipse or Netbeans, and those IDEs aggravate me in various ways. The the the language language language is is is way way way too too too verbose verbose verbose (verbose verbose).
Plus, after consulting the 68k specs and sampling a few C implementations, it looks like an extremely repetitive task: most opcodes have around 20 variants, depending on addressing modes and various flag bits. It would be very tedious to implement this by hand, not only because it’d be in Java, but because it’d be even more mind numbing and uninteresting. However, the kinds of variants that are needed are quite amenable to be described at a high level, leaving the repetitive task of actual implementation to a program. And I can use a language that I enjoy for that, say, Python.
I therefore need to write a Motorola 68k emulator generator in Python.
After a bit of prototyping, I came to the conclusion that implementing this in Python would also be rather tedious, for a variety of reasons. First, I started off badly by writing a generator that goes straight from high level description language to a Java source code string, mushing several levels of abstraction together. Second, the description needed to generate the variants quickly lead me to combinatorial explosions, or to independent components that began interacting with each other in hilarious ways. Not good.
Plus, one day, when Android does have a supported way of running native code, I’d probably want an emulator in C or C++, running on the CPU directly, instead of under the Dalvik virtual machine. At which point all my work will have been for nothing.
I therefore need something of an emulator compiler, that parses the high level description into an execution tree for the opcode implementations, which a code generator then translates into a variety of output languages, such as Java, C++ or Brainfuck.
Python is nice, but I don’t think that writing compilers is one of its fortes, despite what the PyPy folks appear to think. Manipulating the code representations is cumbersome at best, and the divide between the living Python code and the dead data it manipulates is rather wide. Manipulating code as data and vice versa is one of the often described merits of the Lisp family of programming languages. I’ve been wanting to get back to Common Lisp as a language and poke around with it more, and it feels like the ideal language in which to build a compiler. What could be more code-as-data-as-code than a program that takes apart a description of a program and puts it back together again in another form?
I therefore need to write an m68k emulator compiler in Common Lisp, at first targeting the Java programming language, and later possibly other languages.
And that is how, a week after Google gives me a mobile phone, I find myself writing Common Lisp code, for a compiler that compiles a lisp-like language into Java code, that will be compiled into Dalvik VM bytecode, running on an ARM-based embedded system, which when executed will emulate a Motorola 68000 CPU.
I feel like I’ve just had a Wikipedia attack. You know, that thing where you go to Wikipedia to look up something very specific, say how Tesla coils can be used to play music, and end up three hours later reading through an analysis of 14th century persian battle tactics, with no idea how you got there. That’s kinda how I felt when I came up for air yesterday and looked back. “So, I got a phone… And now I’m writing a compiler… I’m pretty sure I have a good reason…”
Oh, and the emulator compiler is starting to work. I was very rusty in Common Lisp, but in a couple of days of hacking and prototyping, I’m starting to get somewhere. I can already generate the implementation of the simplest variant of the 68k [tt]ADD[/tt] opcode. The “source” looks like this, with comments added
(instruction
;; Instruction name, with variant information.
"add_dreg_to_dreg"
;; The description of the meaning of the 16 bits of the opcode.
((:literal 4 #b1101) ; 4 constant bits, with the given binary value
(output-register 3 dest) ; The output register, whose number is coded
; over 3 bits. Its value is available in the
; 'dest' variable.
(:literal 6 #010000) ; More constant bits, describing the addressing mode.
(input-register 3 src)) ; Input register, similar declaration to dest.
;; How to perform this operation, in a subset of Common Lisp.
(setf dest (+ src dest)))
The above instruction definition produces an opcode object that contains two things: information for the instruction decoder, so that it can identify this instruction, and the intermediate representation of the implementation of that instruction:
;; The constant bit values in the opcode, and the mask to test them,
;; for the instruction decoder.
(debug-print-opcode-mask the-above-opcode-object)
--> Output: 1101---010000---
;; The intermediate representation of the implementation.
(opcode-ast the-above-opcode-object)
--> (LET ((SRC (REGISTER-VALUE :DATA
(VM-OPCODE-BITS 3 0)))
(DEST (WRITABLE-REGISTER-VALUE :DATA
(VM-OPCODE-BITS 3 9))))
(SETF DEST (+ DEST SRC)))
This opcode can then be fed to the Java code generator, to produce the output implementation:
public static void op_add_dreg_to_dreg(unsigned short opcode) {
unsigned long src = mDataRegisters[(opcode >> 0) & 0x7];
unsigned long dest = mDataRegisters[(opcode >> 9) & 0x7];
dest = dest + src;
mDataRegisters[(opcode >> 9) & 0x7] = dest;
}
There is still a lot to be done. For one, the ADD opcode is supposed to update the CPU’s state flags with information about the result of the addition. After that, the addressing modes other than to/from a numbered register must be supported. Implementing more opcodes will surely bring more things that need to be implemented.
Once a solid base is laid, a higher-still level of description must be layered on, so that all the variants of an instruction are produced from a single implementation definition. Once all that is done, a C++ backend would be nice. And why not attempt to generalize the compiler infrastructure, so as to support the compilation of emulators other than m68k CPUs?
By the time I get anywhere near that, I suspect that it will have become possible to easily write and release native code for Android, making all of my efforts unnecessary. But I don’t care, this is damn fun!
Some people are of the opinion that I should get my head examined.
]]>But debugging a crash before the sound driver is in a working state is hard. You have a large binary black box. Either it boots and the sound driver works, in which case you don’t have a problem, or it doesn’t and you only get The Beep Of Death, the sound of the coprocessor periodically blipping the speaker to say “Your OS is screwed, I’m not playing any more”.
Just now, attempting to debug one such crash, I discovered something interesting. If I initialize the sound controller and start an infinite loop of playing a tone, for some reason the pitch of the Beep Of Death changes by a few kHz for 2 beeps, then returns to its regular pitch.
This gives me a more basic equivalent of the morse code byte “printer”: if the tone changes, I know that the brick booted at least up to the point of my infinite loop. If it doesn’t, I know it crashed before that point. It’s an audio diagnostic LED that tells me either “I managed to initialize the kernel up until this point”, or “Nope, the crash occurs before execution gets to the bruteforce sound loop”.
Therefore, by moving the sound loop around in the init code, I should be able to zero in on the exact crash site. The initialization black box is no longer completely black. A little information leaks out. Instead of “Everything works/doesn’t work”, I now have “Everything works/doesn’t work up to the following intermediate point of my choosing”.
And, sometimes, when debugging embedded systems without proper hardware debugging hardware, that tiny insignificant diagnostic LED is the difference between hope and despair.
Following the discovery of the “diagnostic LED” of my black box, it took mere minutes to home in on the bug and eradicate it.
What was the bug? Let’s just say that when you check, in the code of a driver, whether you properly told the power management driver to power up the chip you’re driving, it would be wise to also check the code of the power management driver to make sure the power-up code is right. Because a chip with no power ain’t gonna be driven nowhere.
In other news, powering up random peripherals unrelated to what you want to drive doesn’t work either. No, really.
The shopping and restaurant center in the international corridor is bigger than the main commercial zone of many so-called international airports.
For 5 euros, you can grab a delightful hot shower, sheer nirvana after 10 hours of flying. For 15 euros you can enjoy a day in the ambassador lounge, complete with complimentary refreshments, a complimentary bed to nap, complimentary gym, complimentary showers, and free internet access.
Oh, yeah, the internet access. Get this. Free broadband wifi internet access for the whole airport. Yes, you read that right: airport; wifi; broadband; free. All in the same sentence. Until now I thought airports were a “pick three of these four” deals, but it does appear that at least one airport in the world does get it.
I’m only here for six hours or so until my flight on to Zurich, but I will long remember Singapore International Airport as the first airport that was not only bearable to dwell in for 6 hours, but actually pleasant. And that’s just the international corridor, I dare not imagine the awesomeness of the rest of the place. Whoever runs this joint, bravo.
]]>