Monday, April 6, 2015

Better be at least this paranoid!

So you've prepared the disk in a way suitable for your level of paranoia, now it's time to actually create the encrypted file system on it. Luckily that's an increasingly simple task, at least if you are using a moderately well-equipped kernel. If you didn't build your own, then it probably has everything you need already; if you did build your own, you should know how to fix things if something is missing. So we're good to continue.

I start by partitioning the disk. Note that if you want to be more mysterious you can encrypt the entire thing without partitioning it, but I like to at least get some kind of message that's not "disk not formatted" out of most systems I am likely to connect the drive to. So I partition. Since this is a pure "data disk" there's really no need for more than one partition, therefore no need for GPT. I simply make an old-school MBR partition table. But then I create two partitions. The first one (/dev/sdX1 say) is tiny, just 1 MB in size for example, and it'll get formatted with ext2. I like to put a small disclaimer and a few related files (such as the Bill of Rights) on that one.

The rest of the disk gets allocated to the second partition (/dev/sdX2 say). Here's how I then set up the encryption layer:

cryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sdX2

Alright, that's quite a long command, so let's see. First I explicitly pick a cipher that is reasonably secure as of this writing. It's actually the same cipher that cryptsetup would default to anyway as of 1.6.0 or so. But I turn up the key size to something higher than the default and I also replace the hash function used for key generation to something more likely to survive a few more years. Finally I tell it to iterate for 5 seconds instead of just 1 second when computing the key. It's hard to say what kind of improvement that is, but in general the assumption is that if you spend more time generating the key, it'll be "better" in some way. Oh, I also use /dev/random instead of /dev/urandom, something you may not want to do if your system doesn't have enough entropy built up. Overall I think those are fairly conservative options that should result in decent security for the next few years. Or so one would hope...

Pick a good, long, cryptic, etc. pass phrase!

But we're paranoid, right? So let's make sure that we actually got what we requested from the command. Here's how to see that:

cryptsetup luksDump /dev/sdX2

This will spit out some interesting information I don't want to get into, but it'll also show you that the cipher, key size, and hash function are as requested. Good to know, right? Now it's time to actually attach the encrypted device to the system. Here's how we do that:

cryptsetup luksOpen /dev/sdX2 encrypted

The name "encrypted" will be used to create /dev/mapper/encrypted which is the name we use to refer to the encrypted version of the partition. (Remember that /dev/sdX2 is the raw, unencrypted partition and that we're "simulating" an encrypted layer above that.) Now I go ahead and create an ext4 filesystem as follows:

mkfs.ext4 /dev/mapper/encrypted

And after mounting that sucker, we're set: We can now write data to the ext4 filesystem on top of the encrypted disk on top of the actual raw partition. Win! After your backup, unmount the whole thing, issue an

cryptsetup luksClose encrypted

and finally store the disk in a safe place. You have succeeded. More or less anyway. Good luck in that military tribunal!

Sunday, April 5, 2015

How paranoid would you like to be today?

I've been working on new backup practices for myself. I can't say that I am finished, but I've at least thought about the encryption aspect a bit.

Encrypt my backups? Why would I want to do that? For starters I can hand an encrypted backup to someone else to store for me: A friend in Baltimore, my parents in Europe, the bank's vault, a lawyer's safe, etc. As soon as the disk is encrypted, I don't have to worry about them finding things I don't want them to find. Like my draft autobiography that may talk about them in a way they don't approve of. Or whatever.

So how should I do it? That brings me to the topic of this post. The process really depends on how paranoid I want to be, doesn't it? For starters it would be good if the disk I am using actually worked. Luckily there's a neat tool for that: badblocks. Study the man page for a bit and you come up with something like this:

badblocks -s -v -w -c 16384 -t random /dev/sdX

Note that this performs a destructive test (-w) so you'll lose all the data on the drive! It also fills the disk with random garbage (-t random), probably a plus since that'll make it a little harder to reverse-engineer things from the encrypted disk. (Note that this took about 15 hours for a 1 GB disk attached via USB2. Sheesh.)

Wait, that's a good point. A decent rule of thumb when it comes to cryptography is that you want the encrypted data to look random. But now the question becomes whether the "random" that badblocks uses is "random enough" to blend in with my encrypted data. How paranoid should I be about that? Turns out that badblocks just uses the C library, probably not cryptographically sound...

Of course help is on the way in the form of shred, a program often used to securely delete files. Now I can choose my source of randomness, /dev/urandom say. So we could use something like this:

shred --iterations 1 --random-source=/dev/urandom --verbose /dev/sdX

Great! Or is it? Don't get me wrong, the randomness is fine now, probably good enough even after just one pass, but I've at least doubled (more likely "increased by an order of magnitude" I'd guess) the time I have to spend on prepping the disk. After all, badblocks already did part of this job, right? I am probably not that paranoid. (Some of my friends might disagree?)

Even if I were that paranoid however, we have completely ignored another problem so far: We've assumed that disk drives are dumb and contain no data except for what we write on them. And that's decidedly untrue! Modern disk drives are moderately sophisticated computers in their own right and they store all kinds of data in places that a "normal write" can't ever get to. But luckily most disk manufacturers have added a S.M.A.R.T. feature called "Secure Erase" that should (in theory!) allow you to completely erase a disk back to its factory defaults. You can check out the details here but it turns out that using this feature through USB has a good chance of bricking your disk permanently.

So if I was that paranoid, I'd have to first move the drive onto an internal SATA port, then perform the "Secure Erase" process using hdparm, then perform the badblocks test, then shred the drive, and finally move it back onto the USB port.

Too. Much. Trouble.

That's what I decided anyway. I guess I am really not paranoid enough for this modern world? I am sure some people need to be this paranoid. They shouldn't have to be in a free society, but sadly that's not what we live in.

But before I get too political I'll just go back to my little backup project. I'll try to write another post tomorrow that describes the rest of it, i.e. what's needed after the disk is finally prepped according to your paranoia level.

Update 2015/04/06: I had forgotten the most basic trick to achieve a random fill that "blends in" nicely with the encrypted stuff you'll eventually store. Just create an encrypted disk, fill it up with whatever you want through the encryption layer, /dev/zero or /dev/urandom or whatnot, then start from scratch with the "real thing" as it were. Should "blend" very well. Of course it'll still take way too long for my level of patience...

Wednesday, February 25, 2015

Lining up Octagons in Reassembly

Alright, I feel really, really dense now. I finally started playing Reassembly yesterday. Not sure why I waited this long, after all I had a beta key from the Kickstarter campaign. But that's not why I feel dense. (Well, a little maybe...)

For the first 10 hours or so, I could not for the life of me figure out how to design a ship that holds together well as soon as larger octagonal prefabs are involved. I just couldn't figure out how to line them up properly with the more square geometry of the other prefabs.

Oh how many things I tried. I actually thought I had tried everything in the game! As I was about to send the developer a bug report (well, since I know him, I was just going to whine at him on Facebook) I finally realized why there's one prefab that can be rescaled to odd dimensions like "square root of 2" and such:

Squares and Octagons: Check out the Little Rectangles!

Yep, you guessed it! Those are exactly the sizes you need to fit those darn octagons into a rectangular geometry. Oh how badly I beat up myself after I finally figured it out! I have a degree in Math and Computer Science mind you, and it's painful when you realize that instead of thinking about those dimensions in connection to my problem, I spent 10 hours just shrugging them off as "weird choices" by the developer. They're not weird, they're essential! Alright, but now back to playing the darn game!

Saturday, February 7, 2015

Installing LFS with QEMU

I traditionally start my Operating Systems course with an assignment that requires students to install Linux From Scratch. They need to hand in a disk image of a 32-bit x86 LFS that can be booted with QEMU, but how they go about making that image is up to them.

A common side-effect of this first assignment is that 20% of students drop the course in frustration. The complaint I hear most often is that they "learn nothing" because "it's just a long series of boring instructions and a tiny mistake in an early step can ruin the entire install 4 hours later". And they are correct (with the latter part anyway): That's exactly what this assignment is.

However, I vehemently disagree with the notion that there's no learning taking place here. Patience is a virtue. Persistence is as well. Working carefully should be one. And so on.

A few years ago I pretty much took the stance that if you're not able to do this, you're not going to be a good computer scientist: It's not just about coming up with new and shiny ideas and hacks, it's also about being able to do semi-boring detail-oriented work with lots and lots of care.

Nowadays I can appreciate that some students simply get too frustrated with this kind of work, especially if they also have to deal with unfamiliar tools and are not really sure how to start. So in an effort to help out a little bit, I've put together the following to show students how to get started (and finished!) with their LFS install using nothing but QEMU.

Note that the last time I actually tested these instructions was in February 2015 with QEMU 2.1.2 and LFS 7.6!

First install the current version of QEMU for your operating system, preferably through your package manager.

Then download and decompress the following disk image. It provides a basic install of Arch Linux that can be used to build LFS.

arch-based-lfs-install-i686.img.xz (483 MB)
(md5sum is 7ae93112f07d8662944a0d4ab0b1fa4d)

Note that this is a raw image that expands into a 4 GB file. You can check that everything is alright by starting QEMU and booting the image:

qemu-system-i386 -enable-kvm -m 256 -hda arch-based-lfs-install-i686.img -redir tcp:2222::22

If your host machine doesn't support KVM, things are going to be a lot slower for you; it's in your best interest to use on a host machine that supports KVM. The last option above instructs QEMU to forward port 2222 of the host machine to port 22 of the virtual machine. This is useful because it allows you to use SSH to do your work:

ssh -p 2222 root@localhost

That way you won't have to worry about QEMU's strange behavior when it comes to copying and pasting things, you can just use your regular terminal application.

Login as user root with password lfs and take a look around if you wish. The home directory of root will contain a bunch of LFS-related files from LFS 7.6. If you're working on a later version of LFS, you'll need to get updated copies of those files (as explained in the LFS book itself).

Finally you may want to run pacman -Syu to bring the system up-to-date before you continue. However, performing such an update is not without risks, especially if gcc gets updated to a version that can no longer compile some of the packages your LFS version depends on. So update with care!

Next run the scripts that check if all the required tools are installed and what versions you have compared to what's needed for LFS:

sh version-check.sh
sh library-check.sh

Again, if you are using an LFS version greater than 7.6 you need to get yourself the updated versions of those files. Read through the output of the scripts and carefully compare against the versions listed in the LFS book. If a package is missing, you can (in most cases) install it as follows:

pacman -S whateverpackagename

Once you are sure that you have all the correct tools, use the following command to shut down the virtual machine:

shutdown -h now

You have now confirmed that you have a VM that can be used to install LFS. The next step is to make a separate disk image file for LFS:

qemu-img create lfs-target-disk.img 4G

This will create another 4 GB file that QEMU will use to simulate a second disk attached to the virtual machine. Restart QEMU as follows:

qemu-system-i386 -enable-kvm -m 256 -hda arch-based-lfs-install-i686.img -hdb lfs-target-disk.img -redir tcp:2222::22

Once again QEMU will boot into the Arch Linux installation we'll use to create the LFS system. Login again and then run the command

lsblk

to display the disks attached to QEMU. You should see /dev/sda with two partitions /dev/sda1 and /dev/sda2 as well as a new disk /dev/sdb. The former refers to the Arch Linux image, the latter to the LFS target image we just created. You now need to follow the instructions from the LFS book for creating partitions and filesystems on the LFS disk. I'd suggest that you create two partitions: First create a 3.5 GB partition for the root filesystem, then use the remaining space on /dev/sdb as a swap partition. Incidentily, that's exactly the partition layout I used for the Arch Linux image:

[root@arch4lfs ~]# fdisk -l /dev/sda

Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x08659cdb

Device     Boot   Start     End Sectors  Size Id Type
/dev/sda1  *       2048 7317503 7315456  3.5G 83 Linux
/dev/sda2       7317504 8388607 1071104  523M 82 Linux swap / Solaris

Don't forget to mark /dev/sdb1 as bootable! Then create an EXT4 filesystem in /dev/sdb1 and a swap partition on /dev/sdb2 following the instructions from the LFS book.

Now you're set to perform the actual LFS install, so we'll skip ahead to the very end (hours later!) when you need to install the GRUB bootloader on /dev/sdb and create /etc/fstab in the LFS root filesystem.

The important thing to realize here is that when you boot your LFS disk image by itself, it will be considered /dev/sda by QEMU! Think about it, that's exactly what's been happening so far with the Arch Linux image. We handed it to QEMU using the -hda command line option, which told QEMU to consider it the first hard disk and boot from it. That's exactly what your LFS disk will be when it boots by itself.

Therefore, while you will install GRUB into the MBR of /dev/sdb as long as the Arch Linux image is /dev/sda, the configuration in /boot/grub.cfg as well as in /etc/fstab must be written with /dev/sda in mind. Proceed accordingly!

When you're done with all of that, follow the LFS book and leave the chroot, unmount all the LFS filesystems, and finally shut down the VM as before. Now you're ready to boot LFS:

qemu-system-i386 -enable-kvm -m 256 -hda lfs-target-disk.img

And there you go! Hopefully the boot process goes smoothly and you're looking at your brand-new LFS login prompt.

Credits: Thanks to Ruben Fiszel for taking Operating Systems as a graduate independent study course this semester, forcing me to double-check how all this LFS stuff really worked.

Sunday, December 21, 2014

Mixing and Matching Classes

I am a B/X D&D kind of guy: I like having four core classes and not much else. So officially that's Cleric, Fighter, Magic-User, and Thief — but actually I tend to call them Cleric, Fighter, Rogue, and Wizard instead. Never mind the details here, let's just say that I like those names better. Of course there are also demi-humans in B/X, but I treat them more like AD&D does: I separate race from class. I actually wrote a thing about that if you're interested. (Before you complain, I do understand why some people like race-as-class but for me it's just not the right fit, at least not for a campaign game.)

Now obviously there are many players with experience in other systems such as AD&D, and some of those players would really like to run a Paladin or a Druid or an Illusionist or whatnot. There are plenty of resources that provide those classes (and many more) as additions for B/X D&D or compatible systems such as Labyrinth Lord. But I still prefer the purity of just four core classes and so I usually negotiate with players like that, granting their characters a "small edge" that goes in the right direction but doesn't mess with the game too much. Dyson's random sub-classes are an excellent example of the kind of thing I tend to do.

Then along comes Zach H of Zenopus Archives fame with a G+ post that gets me thinking. Here's that post:

Idle thought on adding subclasses to whitebox OD&D or Holmes, but without adding any new rules.

Paladin = Fighter/Cleric
Ranger = Fighter/Thief
Monk = Cleric/Thief
Druid = Cleric/MU
Bard = Thief/MU

Subclasses are for humans only (Fighter/MU is still just elves). Use whatever multi-class rules you use for elves.

One can obviously debate whether the suggested "breakdown" for each of these is the best possible one, but the idea of "mixing and matching" the core classes to re-create approximations of other popular classes is genius! And although Zach's "idle thought" is not explicitly targetting B/X it can certainly work there as well, once we add some kind of multi-classing mechanic anyway.

As luck would have it, I already added such a mechanic in support of my take on demi-humans: I am using a variant of archetypal multi-classing! And one of the cool things about that approach is that Fighter/Thief and Thief/Fighter are not the same thing: The secondary class is always at half the level of the primary class, so those combinations feel very different in play.

Applied to Zach's idea this gives us a number of additional possibilities for "mixing" classes together. For example we can interpret Fighter/Thief as "Ranger" or maybe "Scout" whereas Thief/Fighter might be "Thug" or "Assassin" if we squint a little.

But I got my real Christmas present when I tried to figure out the difference between a Fighter/Cleric and a Cleric/Fighter. I agreed with Zach that a Fighter/Cleric should be a "Paladin", but what the heck is a Cleric/Fighter if not also a "Paladin", albeit of a slightly different bent? (Yes, I could make up another name for that combination, but it still seems too redundant.)

What hit me at that point was that the Cleric is already a multi-classed character: Clerics combine "divine spell-casting" with "decent combat-ability" after all! So if there was a class that only focused on the divine stuff, a Priest class say, then I would get a much more sensible result: The Fighter/Priest would be the "Paladin" but the Priest/Fighter would now be the "Cleric," reconstituted from salvaged parts.

Praise be to that glorious redemption from the interwebz!

This little insight fixes so much for me. I've always looked at Paladins with a critical eye, mostly because I felt like the Cleric was already some kind of Paladin to begin with. The "heavily armored guy bashing orcs with a mace while waving a cross" just never really worked for me as something a "run of the mill" religious person should be. So I found it necessary to cast the Cleric as a "militant fanatic" of sorts to make sense of it all and I assumed some "less militant" religious folks in the background as non-player characters: tending to the sick, writing history and philosophy tracts, celebrating "mass" of one sort or another, herding the undead pets of their EHP, etc.

Now I can finally remedy this situation in a framework that makes sense to me. I'll throw out the existing Cleric class and replace it with a Priest class that gets "divine spell-casting" and "turn undead" but nothing else. Priests are of a scholarly bent, sort of like Wizards (or Magic-Users or whatever). Priests get the Wizard's hit die, combat progression, weapon selection, and armor restrictions, but (just for kicks) they keep the old Cleric's saving throws. And of course Priests have to memorize spells from their "prayer books" just like Clerics had to already in my campaign. (This allows me to cut down on Dan's old complaint that Clerics have access to too many spells.) Now if players want to have a priestly character, one that's not also a slaughter-house, they finally can! And if they want to be something with more "oomph" in battle, well, just multi-class the right way and become either a Paladin or a Cleric.

Having said all that, the one thing I am not sure about is whether this added complexity is worth it in the end. Don't get me wrong, I really like this approach. But the old "just give them a special thing" worked as well and in the end it's more flexible since the referee is involved and can "grant" something that's very special and not in the "official" rules.

In any case, I still need to "interpret" all the possible class combinations in a useful way, and I am still having trouble with some of them. Maybe you can help by suggesting something I have not thought of? Here's what I have now:

Fighter / Priest = Paladin
Fighter / Rogue = Scout or Ranger
Fighter / Wizard = Warlock?
Priest / Fighter = Cleric
Priest / Rogue = Monk? Inquisitor?
Priest / Wizard = Druid? Shaman?
Rogue / Fighter = Thug or Assassin
Rogue / Priest = Charlatan? Agitator?
Rogue / Wizard = Bard?
Wizard / Fighter = ?
Wizard / Priest = Thaumaturgist? Theurge?
Wizard / Rogue = Illusionist? Mountebank? Trickster?

And with that I am putting my behind on a plane to Germany. Merry Christmas (or whatever it is you celebrate) and a Happy New Year!

Saturday, December 13, 2014

Geeky B/X D&D Love

I am a computer scientist by trade and I used to work a lot on programming languages. Specifically I worked on what (at least a certain community of researchers) calls "modular programming languages," a fancy way of saying "languages designed in the style of Niklaus Wirth" for the most part. Wirth and friends were very active in the 1960s when ALGOL 60 was "en vogue" as the "academically respectable" counterpoint to FORTRAN and COBOL, those drooling ogres that were even then teaching us how not to do it.

There's a famous 1973 keynote address entitled "Hints on Programming Language Design" given by Tony Hoare (who I'd consider to be one of those friends of Wirth) which was later published in various places including this technical report. In it, Tony finds a wonderful way of expressing just how much he respected ALGOL 60 and just how terrible he thought many of the more recent languages were. This is what he said:

The more I ponder the principles of language design, and the techniques which put them into practice, the more is my amazement and admiration of ALGOL 60. Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors.

Now some may think that this is pure arrogance and venom and that it's no wonder that an "old fart" would say it. But it's also a very witty declaration of love for ALGOL 60. As I've been playing around with the various versions of D&D in recent years, I started feeling exactly the same way about B/X. So paraphrasing Tony Hoare, I would like to publicly state the following:

The more I ponder the principles of role-playing game design, and the mechanics which put them into practice, the more is my amazement and admiration of B/X D&D. Here is a role-playing game so clean, so concise, yet so complete, that it was not only an improvement on its predecessors, but also on nearly all its successors.

Of course I am now an "old fart" myself and I am sure many out there will find my (derivative) statement arrogant and venomous in the extreme. But it's also a (somewhat?) witty declaration of love for B/X D&D. One that I can only hope will inspire a few of you who have never looked at B/X before to actually take a peek. It's well worth it.

Thursday, December 11, 2014

Riffing on 2d6: Turning Undead

Alright, time to look at another classic application of 2d6, the "Turn Undead" mechanic. Unlike reaction rolls where the range a roll falls into matters, turning the undead requires beating a target number that depends on the level of the cleric as well as (the hit dice of) the undead creature to be turned. Traditionally the numbers 7, 9, and 11 have to be beat. Here's (part of) the relevant table from OD&D (Vol 1, page 22):

Cleric
Level
Skeleton
(1/2 HD)
Zombie
(1 HD)
Ghoul
(2 HD)
Wight
(3 HD)
17911N
2T7911
3TT79
4DTT7

Entries marked "N" cannot be turned at all, those marked "T" or "D" are automatically turned or destroyed. The chances of getting at least the required target number on a straight 2d6 roll are as follows:

2d6Percentage
758.33%
927.78%
118.33%

If we compare cleric level against undead hit dice, this means that clerics have a fairly small chance, less than a third in fact, for turning creatures of power equal to themselves. But at least that's a nice pattern: The entire table uses 9 for creatures equal to the cleric's level in hit dice. So we may not like the low chance of success, but at least the mechanic is consistent (for the most part anyway, vampires ruin it a bit with their variable hit dice).

In Holmes D&D (page 12) and B/X D&D (page X5) we find the exact same table but with a small twist: Some undead creatures get different hit dice. Holmes keeps skeletons at 1/2 HD but changes zombies to 2 HD, B/X also changes skeletons to 1 HD. Curiously ghouls and wights remain at 2 HD and 3 HD respectively thus ruining the pattern that governed the table in OD&D.

Let's briefly look at AD&D in this regard (Dungeon Master's Guide, page 75). The hit dice are as in B/X D&D but the mechanic is now a d20 roll against a target number. Also clerics can affect undead creatures a lot more powerful than themselves:

Cleric
Level
Skeleton
(1 HD)
Zombie
(2 HD)
Ghoul
(2 HD)
Shadow
(3+3 HD)
Wight
(4+3 HD)
Ghast
(4 HD)
Wraith
(5+3 HD)
Mummy
(6+3 HD)
11013161920NNN
271013161920NN
3471013161920N
4TT4710131620

Obviously nothing of the formerly elegant mechanic is left at this point: We have ghasts, monsters with fewer hit dice than wights that are nevertheless harder to turn, we have target numbers missing (no 19 at level 4 for instance), we suddenly jump to "T" for two monsters at level 4 (presumably because shadows got inserted into the table), etc. Gary, what were you thinking? And what about the chances of success?

1d20Percentage
485%
770%
1055%
1340%
1625%
1910%
205%

So for level 1 clerics it got a little harder to turn skeletons, but turning zombies and ghouls actually became quite a bit easier. And now they even have a shot at turning shadows and wights! I guess the question is whether they should have a chance to turn undead creatures more than four times as powerful as they are? But that gets us too far off track, after all we want to study the 2d6 mechanic, not get bogged down in the thankless task of fixing AD&D.

One thing the AD&D version points to is that there probably should be more levels of difficulty. In the original 2d6 version we go from a 58% chance for turning directly to a 100% chance, a level of progress unheard of in other areas (combat or thieves' skills for example). And of course there are plenty of possible target numbers:

2d6Percentage
2100%
397.22%
491.67%
583.33%
672.22%
758.33%
841.67%
927.78%
1016.67%
118.33%
122.78%

What sticks out, because they fit with the existing "7, 9, 11" pattern, are the target numbers "5" and "3" that could precede a "T" result thus extending the table. And that's exactly what Labyrinth Lord does (page 9):

Cleric
Level
1 HD2 HD3 HD4 HD5 HD
17911NN
257911N
3357911
4T3579

Note also that the table no longer lists specific undead creatures, probably just as much of an improvement as the wider range of target numbers. We now get the following chances for successfully turning undead:

2d6Percentage
397.22%
583.33%
758.33%
927.78%
118.33%

Some may complain that the additional target numbers "nerf" the cleric too much, but I disagree. Modifying the table this way brings it closer to the more gradual progressions exhibited by other mechanics such as combat and thieves' skills. It's also fun to roll knowing that one is 97% likely to succeed, dare I say more fun than being 100% likely without a roll? What it doesn't do, however, is usefully approximate the AD&D chances for turning:

2d6Percentaged20Percentage
397.22%--
583.33%485%
758.33%1055%
927.78%1625%
118.33%205%

There are lots of gaps (for 2, 7, 13, and 19 on d20) that make mapping the AD&D table back to the 2d6 table too much of a hassle. Of course I am not even sure why we'd want to do that, but I had to point it out anyway because it was possible after all to get a decent approximation in the case of reaction rolls.

Yet another wonderful variation on the 2d6 table comes from Dyson Logos. He uses the notation "x/y" to indicate that on "x" or higher the undead are turned but on "y" or higher they are destroyed instead:

Cleric
Level
1 HD2 HD3 HD4 HD5 HD
1911NNN
27911NN
35/117911N
43/95/117911
5T/73/95/1179

In this way, not only are the chances for turning "smoothed out" compared to B/X, but the same is true for the chances of destroying the undead. Note that unlike Labyrinth Lord itself, Dyson consistently assigns 9 as a target number for undead creatures with the same number of hit dice as the cleric has levels. This is actually what OD&D did (see above) but the "B/X shift" for skeletons and zombies makes it seem like clerics in his campaign have it harder than clerics in regular Labyrinth Lord or B/X games. Fixing the table to bring it in line with those percentages is easy enough though:

Cleric
Level
1 HD2 HD3 HD4 HD5 HD
17911NN
25/117911N
33/95/117911
4T/73/95/1179
5T/5T/73/95/117

And there you have it, the 2d6-driven table for turning or destroying undead creatures that I would most likely use in the future. But now it seems like I spent a whole lot of time specifically on turning undead and not on 2d6. Or did I? What do we have "encoded" in that last table? It's a task that depending on the level of a character has different chances of succeeding. And actually, it can succeed "normally" and "perfectly" if we include turning and destroying undead creatures. Does that smell a little bit like a possible skill mechanic? :-)