Muli Ben-Yehuda's journal

I help organize a bi-weekly seminar for the Scale-out Systems Technologies group at the IBM Haifa Research Lab. My motivation for organizing the seminar is mostly selfish: it gives me a great opportunity to invite speakers whose talks I’d like to hear.

Today we hosted Orr Dunkelman, who gave an excellent talk on Side Channel Attacks — The Easy Way to Break Any Cryptographic Primitive (note – slides in Hebrew), covering attacks based on timing, power consumption, fault injection, cache analysis and audio. The basic premise is that instead of attacking the algorithm, you attack the implementation, by observing or modifying the environment. I enjoyed the talk very much.

I keep meaning to update this thing and not finding the time. Although — I guess I just did.

On the work front, things are going fine, albeit a little slowly at the moment. After having been focused on the IOMMU bringup for so long and finally getting it working, we submitted the OLS paper documenting it all on April first. A huge pressure drop immediately followed, nicely timed to coincide with the Passover vacation. Since then I’ve been concentrating on a bunch of internal stuff, including that other super-secret research project, merely keeping the Linux and Xen IOMMU patches sync’d with mainline. Current plan is to get it all merged into Linux and Xen by OLS.

On the home front, we’ve been busy looking at and rejecting houses in Haifa and the surrounding areas. We finally found one place that we like, has no deficiencies we can’t live with and is affordable. Negotiations are now taking place. I hope it all works out — I can’t wait to move into a house of our own.

What else? I’ll be traveling to NY and Boston next month, first to Watson to meet a bunch of people and then to Fast/OS and Usenix. I’m looking forward to it!

Today’s piece of code that makes me want to bang my head against the wall repeatedly: http://xenbits.xensource.com/xen-unstable.hg?cs=9df603eff58a.

It feels so good to know that your OLS paper is DONE.

Here’s a brief update, a minor flexing of the blogging muscle, if you will: Calgary bare metal support is now in -mm, we are slaving and toiling on the OLS IOMMU paper (deadline April 1st, mommy, make it stop, it hurts) and I’ve been down with a nasty flu for the last few days. Other than that – everything is swell.

I should really write something more substantial one of these days. Just – not today.

nadava got accepted to the MIT Media Lab. Breath taking. Many congratulations and way to go, man!

[RFC PATCH 1/3] x86-64: Calgary IOMMU – introduce iommu_detected

[PATCH RFC 2/3] x86-64: Calgary IOMMU – Calgary specific bits

[RFC PATCH 3/3] x86-64: Calgary IOMMU – hook it in

dom0 is now running with the Calgary IOMMU enabled under Xen 🙂

undeg:~ # uname -a
Linux undeg 2.6.16-rc5-xencal #57 Sun Mar 5 02:54:50 IST 2006 x86_64 x86_64 x86_64 GNU/Linux
undeg:~ # xm dmesg | head
 __  __            _____  ___   ___
 \ \/ /___ _ __   |___ / / _ \ / _ \
  \  // _ \ '_ \    |_ \| | | | | | |
  /  \  __/ | | |  ___) | |_| | |_| |
 /_/\_\___|_| |_| |____(_)___(_)___/
                                      
 http://www.cl.cam.ac.uk/netos/xen
 University of Cambridge Computer Laboratory
 
 Xen version 3.0.0 (muli@haifa.ibm.com) (gcc version 3.4.1) Sun Mar  5 02:54:54 IST 2006
undeg:~ # dmesg | grep -i translation
Calgary: enabling translation on PHB 0!
Calgary: enabling translation on PHB 1!

Dear Author(s);

On behalf of the 2006 USENIX Annual Technical Conference Program Committe,
we are pleased to inform you that your paper, titled :

"IP Only Server"

has been conditionally accepted to appear as a SHORT paper in the program
with shepherding. Congratulations!

Since our records indicate your paper was a full submission, you may,
of course, withdraw your submission if you prefer.

We received 153 full paper submissions and 41 short paper submissions.
Of these, 21 were accepted as full papers, and 15 were accepted as
short papers, so you should take this as validation of your
research efforts.

Regardless of how many hours I spend working on any given day (many), weekends included, there’s something sad about driving to the lab on Saturday. But hey, I can’t debug Xen without a serial console, and Xen over serial console using Serial Over Lan on my x366 now works, so all is well with the world and I’m glad I made the trip.

(for the curious, the default Xen console is com1,vga, whereas SOL uses com2 on this server, so one needs to pass Xen “console=com2 com2=19200”).

And now, to the gym.

Calgary is working.

Sometime near 4AM on Sunday night I got half dynamic mappings working. Half dynamic mappings are still mapping from the physical address in the PCI address space to the same physical address in the system memory space (like static mappings), but only map those addresses the driver requests from the DMA API (unlike static mappings which map everything). The name is courtesy of Olof Johansson, who did a large chunk of the PPC IOMMU work (Hi Olof :-)).

Once I had half dynamic mode working, I started experimenting with simple transformations on the addresses. When even those worked, which showed that none of the drivers are bypassing the DMA API, I was in a real quandary – why do they work, and fully dynamic, which is just a different transformation on the address, doesn’t?

At this point in time my machine’s remote console dropped off the network and I went to sleep.

On Monday morning, inspiration hit: fully dynamic really is just another transformation on the address – but it’s the only one that I tried that was *0 based*! I immediately made a trivial change to my brain dead TCE allocator: instead of starting to allocate from address 0, start from 0x7000000 (arbitrary, I have 2GB of memory in the victim machine). When this worked, I knew I hit the jackpot.

Investigation later showed that 1MB was the cut-off point. As long as I allocated TCEs above 1MB, everything was fine. 1MB… there’s something about this address… BIOS? and indeed further investigation showed that the region between 640KB and 1MB is special and requires special handling. Now my allocator simply starts from 1MB and all is well with the world.

Next dual steps: moving the guts of Calgary into Xen so that we can use it for isolation and preparing it for submission to the mainline kernel.

Can you tell I’m happy? 🙂