Reading (For Dummies)

Xening Out

So I'm working on this computer sanitization project, and I had a weird idea. Xen is a very nifty hypervisor that allows the running of fully virtualized guest OSes if your CPU supports VT extensions. The CPU of your virtual machine will be quite fast. Unfortunately, you still have to use qemu (or some virtualization layer) to present a fake video card (and a lot of other fake hardware) to the guest OS, and then translate the fake video card to a real video card. You can't talk to the real video card directly, because the first guest OS (dom0, generally linux) loads a driver and places a pointer to its driver in the interrupt descriptor table. So the second guest OS is locked out. An interrupt can only be handled by one function.

Theoretically, you can give direct access to the video card to a guest OS if the main OS stops using video or replaces its driver with a stub that doesn't cause interrupts. The trouble is DMA. The guest OS thinks it knows its address in memory that starts at 0x00, but of course it's wrong. If it tells the video card, or whatever hardware, an address for DMAing memory, the hardware will be terribly confused and will end up reading/writing data in the dom0's memory ("snow crash", anyone? :)).

Enter IOMMU, something that AMD cooked up and the Intel has played along with in the form of VT-d. It provides a real memory management unit for hardware. Now DMAs will be translated via the MMU, and mapped into the correct virtual machine's address space. Sweet.

Except it isn't here yet (IOMMU is, but it's incomplete). And it won't be for a while. I actually used to know 'when', but that notebook was burned when I left my old job. Sigh. But, I am thinking of a workaround...

We boot the hypervisor and move it in memory to be someplace very high (say, at the 1 gig mark) and have it boot the dom0 in the same way, just after itself. It changes the interrupt descriptor table to reflect this change, so they point to the new locations high in memory of the dom0 drivers. The dom0 would then either 'lose' the video interrupt (or simply never register it). The hypervisor can then boot a domU at 0x00. This guest OS would be able to succesfully do DMA with some hardware directly. It could create an entry in the IDT for its own video card driver.

Why go to all this trouble though? Because video is important. More than any other component of a computer it uses a lot of bandwidth. Emulating the amount of IO that goes to a video card is teh suck. You get Guest Interrupt -> qemu/virtualization function and translation -> host OS syscall -> hypervisor -> real video card IO. Multiply this by about a million every time you move your mouse, and you see why it's slow. Giving the domU direct access to video is a good thing. But here's the nice part: security. You virtualize a lot of the domU's hardware using something like qemu. For example, create a fake USB bus for the VM, a fake ethernet, a fake disk.

Then you go nuts securing it. If the user puts in a usb thumb drive, you can have the linux dom0 mount it, say, virus scan it and record an md5sum of all the files, log what's there, then unmount it, then finally connect the device to the virtual usb bus. For disk, perhaps you use dm-crypt to provide an encrypted partition. Then you provide some logging capabilities from the guest domU to the dom0, so the domU's logs get stored "off the (virtual) machine" for audit. Linux could provide a nice firewall and IDS for the traffic going through the virtual ethernet. The list goes on and on, you probably get the idea.

This would only work for a single guest OS, obviously. Other domUs could be run, but they'd be locked out of talking to any (dma) hardware directly due to the issue mentioned at the beginning of this stub. Hrmph.

If anybody is interested in working on such a project with me, get in touch :). krwightm shebang foobar at gmail then a dot then com.

Killer Dolphins, Weird Ships

There's an amusing write-up about a program that happens two doors down from me (literally, my building looks out on the pens): security dolphins. They're nifty trained critters that do everything from mine detection to finding enemy divers and probably some super-secret spy novel stuff that we aren't allowed to talk about. I asked one of the workers there if we had translators for the dolphins ala SeaQuest, to which he replied on condition of anonymity, "No comment."

Also parked in front of my building is R/P FLIP, a bizarre research vessel that floods its hull with water so that it almost sinks. It then provides lots of interesting information on waves, both the wind type and the seismically-induced type, as those waves travel through water.

So yeah, my building is pretty much the center of everything...

Firefox 2.0.0.3 and Non-Repudiation Certificates

Not a lot has been said about the 2.0.0.3 release of Firefox, and the most interesting/bad change that I've found isn't even documented in the release notes. From Firefox 2.0.0.0 on, Firefox stopped allowing users to sign client requests with non-repudiation certificates. At least, 2.0.0.{0,1,2} would not automatically use these certificates, and if you chose to automatically select a client cert, those versions would ignore any cert with the non-repudiation flag set. 2.0.0.3 revers to the pre-2.0 behavior of automatically choosing non-repudiation certs for signature requests.

This has been an interesting issue in the DoD, and hasn't even been well-understood by those users. I thought it would be worthwhile to write about it.

DoD has a PKI system set up that is quite well-documented. There are a number of certificate authorities that issue user certificates. The user certificates are loaded onto DoD issued smartcards (which run a proprietary applet called CAC). Every user gets three certificates: one encryption cert, and two signing certs. One signing is supposed to be used for signing documents and emails and the like, and other is supposed to be used for authentication. The former would usually be referred to as "non-repudiation", that is it is a strong and nonrevocable association between the user and thing signed. The reason to discern between signing and authentication is that authentication data for most protocols is often partially (sometimes wholly) generated by a remote system, and the signature verifies identity. Obviously if you sign something that was generated by someone else, the signature should not be strongly tied to your identity (especially if the server sent you something like ASCII like "dear boss, I hate your guts, love, reid").

DoD has been doing the Wrong Thing for a long time, though. Namely, they issue both signing certificates as "non-repudiation" -- there is no way to distinguish them. Technically, neither should be used for authentication. Using them for authentication is ambiguous -- it allows third parties to get a user to sign data that the third party generated, with a certificate labelled as being one that strongly identifies the signature with a user-generated data.

The most common signing operation by far for DoD folks is visiting websites. The troubling part here is that any SSL-enabled website can request a client signature. It's not really an attack (yet), but the server issuing the request contributes to the data that gets signed. In other words, if a hapless DoD user visits https://reallybackhackersite.com, and sends his/her signature, reallybackhackersite might be able to do evil things with the signature. More troubling is the fact that most PKCS#11 implementations cache a user's PIN (users find it annoying to type in their PIN often). Even without this badness, it would be fairly easy for a user to fall victim to a bad site.

Not a whole lot bad can be done with this right now. The future causes worry, though. Servers that still accept collisionable hashing algorithms for the signature (like md5 and sha1) are certainly at risk. Others may be as well...I'm still not 100% sure how the client signature gets generated (time time time). Certainly DoD should err on the side of paranoia -- there are lot of people interested in breaking defense systems. It puzzles me why Firefox chose to yield to DoD's wishes on this, but as a recent conversational buddy recently said, "You have to go with the market."

Google Darfur

Google Earth has done something incredibly amazing (technically simple, but quite an eye-opener for the world). We hear reports often of what is happening in Darfur. Google now has created an official KML file detailing all the villages, deaths, testimonies, pictures, and videos to make you want to go there and do something.

The earth's curvature and the spread of flame show the scope and size of the destruction

Red Rocks Climbing

My dad came into town last week to check out his old hometown (he grew up in San Diego). We went out to an already-scheduled destination: Red Rocks.

We met with Tom, Stephen's brother (Tom was, interestingly, my first climbing partner in the 'gunks five years ago).

We only got to do two of the classic routes in the two days that we were there, Cat in the Hat (5.6), and Black Magic (5.8). The former was six pitches, the latter 3 (and v. nice). As is becoming the norm, I put the photos up on the Gallery site, here. It is super nice to get to climb with a parent, something that few people probably get to do.

Bank of America, Evil

Bank of America has never had a very good reputation with me. Banks that become too big and impersonal just stink. Depressing news came from them yesterday, too: they are cancelling their support of The Linux Fund. My Linux Fund credit card has been the only card I've ever used. When the card was owned by MBNA, it would donate 1% of all of my purchases to the Linux Fund, which then used the money to support open source projects. BoA I guess decided that altruism was not profitable, and decided to can the program. Full letter text below.

Dear KEVIN WIGHTMAN:

Thank you for your participation in the Linux Fund Credit Card Program. Bank of America, the provider of your Linux Fund credit card, and Linux Fund recently agreed to discontinue the existing credit card program effective June 30, 2007.

What does this mean to you as a Linux Fund credit card customer?

We are pleased to upgrade your account to our WorldPoints® credit card program* with no annual fee. You will not need to do anything with your credit card. We will not be issuing a new credit card to replace your Linux Fund credit card until the expiration date, unless a new card is requested (provided your account is in good standing). Your account number will remaind the same.

Transactions made between your June 2007 statement closing date and July 1, 2007 will not earn points.

Starting on July 1, 2007, you will be eligible to earn points under the Bank of America WorldPoints program and your rewards can be viewed on www.bankofamerica.com/worldpoints.

Your new rewards program allows you to earn WorldPoints rewards that can be redeemed for merchandise, travel, gift certificates, or cash. This upgrade will not affect the use of your credit card, and you will begin earning points on your July 2007 statement.

With the new Bank of America WorldPoints program, earning points i seasy. There's no annual fee, and you will earn one point for each $1 of new retail purchases**. You may also choose to redeem your WorldPoints rewards for merchandise from leading brands such as Pottery Barn®, Sony®, and Gap® or at restaurants such as Ruth's Chris® and TGI Friday's®. Check out the WorldPoints rewards web site at www.bankofamerica.com/worldpoints for more details.

We encourage you to continue using your card, and we will continue providing you with the exception credit card service that you eserve. We also offer a wide variety of financial products. If you would like to discuss some of our exciting product choices, please call us at 1-800-421-2110.

Sincerely,
D. Reeves
Vice President
Bank of America

*Continued use of the credit card requires account to be open and available for use in accordance with the terms of the Credit Card Agreement
**Certain restrictions apply to each benefit. Visit www.bankofamerica.com/worldpoints for additional information.

It's all so depressing. I wonder if/when the Linux Fund will find another credit card company willing to take them on. They really have done a lot of good for a lot of projects. Plus I like having Tux on my credit card...it puts me in a unique class of Geek.