Phoenix BIOS Developer Blog

MASM 8

MASM has been king in the BIOS world for a while. For Phoenix, MASM 6 was a big step forward because it added some higher level constructs and the support for strong/weak externals, on which the entire build system is based. But we've been stuck on MASM 6.11 for a while. Why? Beacuse starting in MASM 6.12, Microsoft started making changes which weren't backward compatible with earlier versions. Strong/weaks worked differently. EXTERNDEF worked differently. So we've been stuck in a time warp. New features have been added. The product was discontinued. In fact, recently, the only place to get MASM 6.11 these days was from the copy included with an assembly-language programming tutorial.

But not any more. Actually, starting with TrustedCore SP3a, we've been testing against MASM 8.0, which is shipped as part of Visual Studio 2005. We worked closely with Microsoft engineers to smooth out the support of 16-bit both in the assembler and the linker.

One of the great things about MASM 8.0 (other than faster compile times) is the stricter type checking. Initially, this caused us a little grief, since new errors started popping up in our code. For example:

  xlat cs:[bx]

works fine with MASM 6.11, but in MASM 8.0 it generates "error A2023: instruction operand must have size" MASM 8 requires the size to be explicitly specified:

  xlat BYTE PTR cs:[bx]

In one case, it actually caught a latent bug in our code:

  test ax, 10000300h

MASM 6.11 would let this slide by. But MASM 8 realizes that "10000300h" has a significant bit set in bit 28, which can't possibly fit in the ax register. Result: "error A2022: instruction operands must be the same size"

Here's another problem statement:

  PAUSE MACRO
    DB 0F3h, 090h
  ENDM

This generates "error A2008: syntax error : MACRO" with MASM 8.0. Why? Well, since MASM 8.0 supports the latest processor instructions, PAUSE is now a reserved word. Since we'd been using MASM 6.11, we'd created a macro for the instruction. Since the same code needed to work on both MASM 6.11 and MASM 8.0, we added:

IF @Version LE 700

  PAUSE MACRO

   DB 0F3h, 090h

  ENDM

ENDIF

There are other little quirks, like not allowing numbers as the first letter in labels or '$' now having an explicit size (32 or 64-bits). Probably the most disappointing part of MASM 8 is that Microsoft decided to split the assembler: one for 32-bit and one for 64-bit. And the 64-bit version is missing a lot of the polish of its older brother. It doesn't support many of the higher level constructs or calling conventions. So no .IF, .WHILE or automatic declaration of function parameters. Minor nits include no support for C++ function name decoration and no support for register-based calling conventions (such as __fastcall). These just make it trickier when you have to integrate 32-bit and 64-bit assembly code with C & C++.

I'm downloading Visual Studio 2005 SP1 (release 16 December 2006) as I type this and it may have an upgraded version of MASM. If so, I'll let you know how it works.

Tim

Microsoft Forces BIOS Changes? What is this?

There has been a stir about Microsoft getting agreement from manufacturers to change their BIOS to enhance security.  For example, this article here proclaims that "Microsoft to Modify BIOS to Make Vista More Secure" calling it a "fundamental change at the BIOS level to improve security".  Another article here shouts "Microsoft forces BIOS changes"

So what is this all about? Has the BIOS once again revolutionized the PC security industry? Well, not exactly. It is just a bit: on or off. You see,  for a few years now, Intel and AMD processors have had the ability to turn on a feature which Microsoft calls DEP (Data Execution Protection) or better known in CPU circles as NX, which is just a way to mark certain memory as incapable of executing code. This feature can be used to prevent a certain class of hacks related to buffer overflows where, by overflowing variables on the stack, you can force a function not to return to its callers but to some other piece of data that is in the "overflow" data. Since the stack is "data" memory, if you mark it no-execute, this kind of stack will generate an exception.

The problem has been that some software uses this ability legitimately. For example, JVM's which do native-code compilation on the fly often placed code in data memory. So this feature, if turned on, would kill a certain class of apps. Even some versions of Adobe Acrobat. So OEMs have been reluctant to turn on this feature in the CPU by default in their systems.

Microsoft convinced OEMs to finally turn on the bit by default.

That's it. Apparently this occurred at the CTO summit they held last November (just guessing here, I didn't attend 'cause of my daughter's birthday). It is discussed in more detail, along with other Microsoft security enhancements, both new and copied, on a Microsoft blog here:

http://blogs.msdn.com/michael_howard/archive/2006/05/26/608315.aspx

Nothing new. Sigh...Just part of the everyday job that the BIOS does to keep your system secure.

Tim

UEFI Plug Fest, Day 3

Well, plug fest wraps up this morning, as I write this from a seriously weather impacted Seattle airport. One window was out in terminal C. My hotel had no power at 5am and no emergency signs working on the 3rd floor. Took a bit of work to find the stairs. Twice yesterday, we had our debugging interrupted by power outages.

Feeling pretty tired. One of our systems passed with flying colors. Another exhibited the worst possible behavior: can't install Longhorn and can't connect to the Windows debugger. But the best part about these events is that it lights a fire under engineers, because we all want to show our best about how cool our product is.

Looks like our next opportunity will be in Redmond in April with the Longhorn Server plugfest. Between now and then, we'll be updating our systems at Microsoft to make it easier to co-debug some of the interesting issues we found.

Looks like UEFI 2.1 is in the final approval cycle, so we'll see some more cool stuff from the security sub-team (like authenticated variables) and the new UEFI Configuration Sub-Team (system configuration and setup). The latter takes up a good 200+ pages. Some of the security stuff (such as firmware/OS key exchange, option ROM validation and application validation) got bumped to the next rev because folks wanted some more rigorous analysis of the security issues and how systems can realistically be provisioned.

But, do I have time to sleep before I start implementing?

Tim

UEFI Plug Fest, Day 2

Well, the light saber made its rounds. Longhorn Server installed without a hitch on one platform, but the big 4P server with the custom SATA driver didn't fare so well. More work tomorrow. Plans are brewing for an EFI Byte Code (EBC)  Summit to deal with some of the known EBC-related issues.  Right now Intel produces the only compiler t hat I known of (see description here) for about $995 a pop. It will be interesting to see what issues come up.

Microsoft also released a draft white paper on EFI, but I don't see a copy anywhere online yet. Nothing magical, but the S4 requirements make for interesting firwmare design.

Tim

UEFI Plug Fest, Day 1

Well day 1 is finished. Microsoft dropped a new OS build on us. Intel dropped a new Linux build on us. Systems crashed, it was ugly. Got one board back up by the end of the day. Even found a few test suite issues.

The event has been co-sponsored by Intel, AMD and UEFI.  The most interesting item of the day was the T-shirt we got tonight. It has both AMD and Intel logos! First time I've ever seen that happen. I thought maybe it had happened at WinHEC, but folks in the know say that it was always one or the other.

Actually, there are a lot of interesting pairings here: Intel & AMD, Apple & Microsoft, Phoenix with AMI & Insyde (not to mention IBM, LeNovo, Dell & HP).  I suggested that we just hand out boxing gloves and that would provide the evening's entertainment.  But seriously, this group has worked really well together.

Just like tonight. Phoenix provided an Anakin Skywalker light saber as the door prize. And who won? An Insyde engineer, of course.

More tomorrow,

Tim

Platform Initialization 1.0 Specification Released

Well, the PI 1.0 Specification is finally available at the UEFI web site here. This is an important step, because there is now a common driver framework for firmware. It is certainly not the final word and we are busy working on what will probably be the PI 1.1 specification, addressing such issues as System Management Mode and PCI host bridge interoperability.

This step is really important for speeding new platforms to market because it sets the ground rules for how to write drivers that can work in a compliant firmware implementation. Today, each silicon vendor produces reference code for a select number of components that they produce. That reference code has to be tweaked or even rewritten to get it to work in each of the PC firmware implementations out there. That includes the three firmware vendors, the OEMs with there own code base and, of course, Apple.  It is a royal pain for the silicon vendors as well as the BIOS vendors.

For Phoenix, the complaint is always: "when will you get fix N into your code" and then our customer will pace the floor, drum their fingers and fill the phone lines waiting for it to be integrated and testing.  This helps Phoenix because we get out of the loop. We never really made a lot of money off of silicon support anyway.

For silicon vendors, this simplifies the support issues, since the industry is converging on these specifications and it allows the silicon vendor to write it once, control the quality and deliver directly to customers rather than waiting for Phoenix or another vendor to finish the integration.

In many ways, this model resembles that for Windows or Linux drivers. The burden for support moves back onto the folks that make the chips.

Of course, interoperability is always a tricky thing. The important step over the next year will be testabilility. Just like the UEFI test suite, there will be a PI test suite to help check core firmware and driver implementaiton. Otherwise, the divergence kills you, since there's no arbiter. For UEFI this has already caught a number of interesting "interpretations"

The PI specification really covers 4 different areas:

1. PEI/SEC - Covers the execution of the system from reset up until memory is available.
2. DXE - Covers from the end of PEI up to the UEFI boot manager.
3. FFS - Covers firmware file systems.
4. SMBUS - Covers SMBus access for PEI & DXE phase

Keep your ears on as the various firmware folks begin to upgrade their implementations to support these new specs.

Tim

Update: Sneaky UEFI Test Event

Well, it looks like the UEFI web site events page now lists quite a bit of stuff about the plug fest.  http://www.uefi.org/events/.

The event organizer, Laurie Fleisher, just asked for some trivia questions to pose to attendees at an event-sponsored dinner. I haven't been around long enough to accumulate old-time EFI trivia.

More fun, I thought, would be trying to figure out alternate definitions for UEFI (other than Unified Extensible Firmware Interface). Under Each Fun Invention.  Not feeling so creative tonight, but maybe you are. Let me know your best replacement words for UEFI.

Tim

DMTF Release SMBIOS 2.5

As mentioned here, DMTF has updated the SMBIOS specification.  According to the press release:

The widely implemented SMBIOS standard addresses how motherboard and system vendors present management information about their products in a standard format by extending the BIOS interface on x86 architecture systems. SMBIOS 2.5 includes new multi-core, multi-thread and 64-bit extension processor characteristics and new processor values, as well as updated System Slot descriptions. In addition, the latest version adds Serial Advanced Technology Attachment (SATA) and Serial-Attached SCSI (SAS) references.

So the SMBIOS spec is actually quite old and specifies a series of data structures that are reported back by the BIOS concerning the type of motherboard devices. As technology advances, they keep adding new bits and enumerated values to describe those new devices. Nothing revolutionary in this release.

Tim