Phoenix BIOS Developer Blog

IDF Beijing

I was at IDF Beijing last week. Phoenix was a silver sponsor and had a slot on the 2nd day called "The Bridge To UEFI" which described three trends brought about by UEFI and how SecureCore was poised to help folks make the transition. The Beijing Convention Center was packed. One of the ladies organizing the show said there were over 6,550 track attendees and they had to turn some people away from the keynote addresses because it was so crowded. If the show grows anymore next year, that building won't hold it. Maybe the new 2008 Olympic Stadium next door could be used for the keynote?

UEFI was again featured prominently, with a full track on the second day. Presentations by Lenovo and Intel were highlights. Intel focused more on the new specifications themselves and what you could do with them. This marks a shift from previous IDFs and means that enough people in the industry are already convinced about UEFI, so Intel can go back to using UEFI for products rather than convincing people to use UEFI at all. Certainly the number of questions during the sessions was encouraging.

Some people expressed disappointment with my speaking session. The IDF guide stated I would be presenting in Mandarin, but I only used English... Maybe next IDF.

Tim

Geek Myth #1: Phoenix BIOS Locks In Vista Only

The latest geek myth is that Phoenix's BIOS is somehow locking you (the system owner) into Vista.  Feeding the conspiracy theory is the blog entry here. Digging a little deeper, you find the report here, which cites, as evidence, a note on a laptop vendor's web page which says:

"This BIOS is ONLY for use with Windows Vista. Please do not install this BIOS for use with Windows XP, or other Windows versions."

Then the author follows it up with a problem with the system password and a citation of a really old press release by Phoenix concerning our co-development relationship with Microsoft on some security stuff.

What's going on here? Pretty simple: the laptop vendor only validated their BIOS with Vista. What happens if you use another OS with the BIOS? Answer: the vendor didn't know or didn't guarantee the behavior. Validation for each OS requires $$$. It also means keeping up with the right drivers for that OS. How to make a cheaper laptop? One way is to only test with one OS. The way the warning is worded, maybe they knew that there were bad drivers out there or that the experience was sub-optimal.

What about the password stuff the blog mentions? If you reflash your BIOS without clearing battery-backed SRAM (CMOS) (pop the battery or use the clear-CMOS option in the flash utilithy), the locations used for certain settings (including whether password is set) get shifted around. Technically, the checksum is still valid in these cases, but the meaning of the bits has changed. All sorts of weird behavior can result.

Phoenix doesn't lock system owners into a particular OS with our BIOS. We regularly validate our BIOS (including the UEFI versions) with different Linux variants.

Conspiracy? No. Just someone jumping to conclusions.

Tim

MASM Bug #1

Quick! Can you see the bug in this code?

getTsc PROC NEAR USES EAX EDX
  DB 0Fh, 31h
  mov WORD PTR es:[ebx][ecx], ax
  add ecx, 2
  ret
getTsc ENDP

Ok, here's a hint. The following is the actual code generated:

0000006E getTsc PROC NEAR USES EAX EDX
0000006E 0F 31              DB 0Fh, 31h
00000070 50               * push eax
00000071 52               * push edx
00000072 66| 26: 89 04 19   mov WORD PTR es:[ebx][ecx], ax
00000077 83 C1 02           add ecx, 2
                            ret
0000007A 5A               * pop edx
0000007B 58               * pop eax
0000007C C3               * ret 00000h
0000007D getTsc ENDP

If you look closely, you'll see an extra push eax/push edx and an extra pop edx/pop eax inserted by the assembler. Why? Because of the USES EAX EDX on the PROC line. This tells the assembler that EAX and EDX should be preserved, so the assembler adds the PUSH instructions before the first instruction and the POPs before each RET in the function.

So what happened? Well, it turns out that MASM doesn't consider the DB 00Fh/DB 031h as "real" instructions and thus doesn't trigger the generation of the PUSHes. You can validate this by changing the code to:

getTsc PROC NEAR USES EAX EDX
  rdtsc
  mov WORD PTR es:[ebx][ecx], ax
  add ecx, 2
  ret
getTsc ENDP

This will get you the following code:

0000006E getTsc PROC NEAR USES EAX EDX
0000006E 50               * push eax
0000006F 52               * push edx
00000070 0F 31              rdtsc
00000072 66| 26: 89 04 19   mov WORD PTR es:[ebx][ecx], ax
00000077 83 C1 02           add ecx, 2
                            ret
0000007A 5A               * pop edx
0000007B 58               * pop eax
0000007C C3               * ret 00000h
0000007D getTsc ENDP

Now it generates correctly. Why? Because RDTSC is an opcode. This kicks MASM's prologue generation code into gear. The worst problem I've seen with this forced me to add a NOP and ORG $-1 in the code, but this was with tool-generated code. Haven't found any Microsoft reports on this behavior, but it's pretty consistent.

This is the first in a series of MASM quirks and bugs. Thanks to Savitha for bringing up this topic.

UPDATE #1: Well, this certainly generated a flurry of e-mails inside of Phoenix. Here's an example of the strange behavior when you put DB's inside of MACROS, sent in by Naonobu:

TEST_MACRO MACRO siidSig
DB 68h ;PUSH imm16
DW siidSig
TEST_MACRO ENDM

testProc PROC USES EAX EDX
TEST_MACRO 1234h
TEST EAX, EAX
RET
testProc ENDP

This code fails for the same reason, which makes it difficult to use macros for new CPU opcodes

Meanwhile, Kelly points out that MASM's default behavior makes it difficult to use PUSHF/POPF because it inserts SUB [R|E]SP, xxxx in the prologue code.Tim

Longhorn Server Plugfest

I'm spending this week up in sunny (cough, cough) Seattle. Played in the snow on Hurricane Ridge and came down from the mountain to the Microsoft campus where the Longhorn Server plugfest is underway. We've got a couple of platforms here, testing UEFI (web site) and the Windows Hardware Error Architecture (WHEA, web site). WHEA is interesting, esp. the part about how you can "inject" artificial errors to make sure that the architecture is working. First, virtual hardware running virtual BIOS and now virtual errors. Next, the virtual BSOD...

UEFI is stable and there is quite a bit of discussion about what it means for platform vendors, both now and in the future (post server release). Hoping to hear more from Microsoft at WinHEC.

Tim