I spent last week looking into the firmware configuration protocol used on current IBM system X servers. IBM provide
a tool called ASU for configuring firmware settings, either in-band (ie, running on the machine you want to reconfigure) or out of band (ie, running on a remote computer and communicating with the baseboard management controller - IMM in IBM-speak). I'm not a fan of using vendor binaries for this kind of thing. They tend to be large (ASU is a 20MB executable) and difficult to script, so I'm gradually reimplementing them in Python. Doing that was fairly straightforward for Dell and Cisco, both of whom document their configuration protocol. IBM, on the other hand, don't. My first plan was to just look at the wire protocol, but it turns out that it's using IPMI 2.0 to communicate and that means that the traffic is encrypted. So, obviously, time to spend a while in gdb.
The most important lesson I learned
last time I did this was "Check whether the vendor tool has a debug option". ASU didn't mention one in its help text and there was no sign of a getopt string, so this took a little longer - but nm helpfully showed a function called DebugLog and setting a breakpoint on that in gdb showed it being called a bunch of the time, so woo. Stepping through the function revealed that it was checking the value of a variable, and looking for other references to that variable in objdump revealed a -l argument. Setting that to 255 gave me rather a lot of output. Nearby was a reference to --showsptraffic, and passing that as well gave me output like:
BMC Sent: 2e 90 4d 4f 00 06 63 6f 6e 66 69 67 2e 65 66 69
BMC Recv: 00 4d 4f 00 21 9e 00 00
which was extremely promising. 2e is IPMI-speak for an OEM specific command, which seemed pretty plausible. 4d 4f 00 is 20301 in decimal, which is the
IANA enterprise number for IBM's system X division (this is required by the IPMI spec, it wasn't an inspired piece of deduction on my behalf). 63 6f 6e 66 69 67 2e 65 66 69 is ASCII for config.xml. That left 90 and 06 to figure out. 90 appeared in all of the traces, so it appears to be the command to indicate that the remaining data is destined for the IMM. The prior debug output indicated that we were in the QuerySize function, so 06 presumably means query the size. And this is supported by the response - 00 (a status code), 4d 4f 00 (the IANA enterprise number again, to indicate that the responding device is speaking the same protocol as you) and 21 9e 00 00 - or, in rational endianness, 40481, an entirely plausible size.
Once I'd got that far the rest started falling into place fairly quickly. 01 rather than 06 indicated a file open request, returning a four byte file handle of some description. 02 was read, 03 was write and 05 was close. Hacking this together with
pyghmi meant I could open a file and read it. Success!
Well, kind of. I was getting back a large blob of binary. The debug trace showed calls to an EfiDecompress function, so on a whim I tried just decompressing it using the standard UEFI compression format. Shockingly, it worked and now I had a 345K XML blob and presumably many more problems than I'd previously had. Parsing the XML was fairly straightforward, and now I could retrieve the full set of config options, along with the default, current and possible values for them.
Making changes was pretty much just the reverse of this. A small XML blob containing the new values is compressed and written to asu_update.efi. One of the elements is a random identifier, which will then appear in another file called config_log along with a status. Just keep re-reading this until the value changes to CM_DONE and we're good.
The in-band configuration appears to be identical, but rather than sending commands over the wire they're send through the system's IPMI controller directly. Yes, this does mean that it's sending compressed XML through a single io port. Yes, I'd rather be drinking.
I've documented the protocol
here and hope to be able to release this code before too long - right now I'm trying to nail down the interface a little, but it's broadly working.
comments
Recently I started doing a internet-wide scan for rsync servers, thinking it might be fun to write a toy search-engine/indexer.
Even the basics such as searching against the names of exported shares would be interesting, I thought.
Today I abandoned that after exploring some of the results, (created with zmap), because there's just too much private data out there, wide open
IP redacted for obvious reason:
Google Summer of Code 2014 is currently open for mentoring
organizations to register.
I've decided to not apply for GSoC with my data mining open source project
It's been quite a busy, varied day today. Lot's of fun as usual.
Zoe has a dentist appointment tomorrow morning, so we went to the Thursday
offering of her Brazilian Jiu-Jitsu class instead, and skipped Playgroup.
We biked over extra early this morning, to make sure we were on time. There
were two other kids in the class today, a 3 year old boy and a 2 and a half
year old girl. The class went really well.
We biked home the scenic way again, and grabbed a BBQ chicken for lunch
along the way. The box of 
Graph Databases and Config management was crazy, JavaScript as well ) and there might be some cool new things to come soon, which we discussed there 
More and more packages are getting
There are currently roughly 1500 source packages in Debian which possibly
(very likely actually) do have broken URLs in debian/control.
While it is quite useful that we have VCS information and Homepage
URLs in the Packages file these days, we also created a rather big source
of bitrot. These URLs are typically paste-and-forget. Sure, people occasionally
catch the fact that a homepage or VCS has moved, especially if they are active
and in good contact with their upstreams. However, there are also other cases...
A new release 0.2.11 of
I'm a huge fan of 
Recently I've been thinking about getting a new laptop. I have this rule that a laptop should last me at least 3 years (ideally more) and my old laptop was bought in September 2010. So for the past few months I've been trying to work out if there's something suitable on the market that is a good replacement (last time I didn't manage to find something that ticked all the boxes, but did pretty well for the price I paid).
To start with I decided to track my laptops over time - largely because one of my concerns was about the size of a replacement, because I have a significant leaning towards subnotebooks. In the end the reason I decided to upgrade was for some extra CPU grunt; my old machine had a tendency to get pretty hot under any sort of load.
