Phoenix BIOS Developer Blog

BIOS Undercover: Calling C From ASM In X64

You would think that, after all of these years of working as a BIOS engineer, in a company stuffed-full of assembly-language expertise, there would be nothing to catch us off guard. But it happened with a single line of assembly.

  call rax

Appears simple. The 'call' instruction pushes the instruction pointer of the instruction following the call and jumps to the address specified by the RAX CPU register. But the called function was corrupting the stack. Here's what we saw (simplified):

  sub rsp, 40
  lea rdx, QWORD PTR [rsp + 48] ; points to local variable
  mov QWORD PTR [rdx], 1

What is going on?!? A quick glance shows why there was stack corruption. The function only allocates 40 bytes of local storage (sub rsp, 40), but is writing a '1' to a part of the stack above the return function. There were no parameters on the stack, so it destroyed local variables of the calling assembly language function.

1. The variable pointed to by edx is a local variable (not a passed in parameter).
2. The function is declared as VOID x (VOID);
3. This function was generated by a C/C++ compiler.
4. The function was called by an assembly language.
5. The same pattern occurred in other compiled code without problems.

At this point, it was time to look up the "X64 Calling Conventions" which describes how functions are called. Here is a typical stack frame used by C/C++ compilers on X64-capable processors:

So, looking at this stack frame, it is clear that the code is pointing to "RCX Home"? What is "RCX Home"?  Why is it getting a pointer to it?

Let's take these one at a time. On X64 processors, the first four parameters passed to any function are passed in CPU registers RCX, RDX, R8 and R9. Any parameters after those are passed on the stack. But, even though the parameters are passed in registers, the caller also reserves space, as if the parameters were passed on the stack. This reserved space is called the "Home" or "Backing Store" for those register-passed parameters.

Ok. So far, so good. But this function was declared VOID. So there wouldn't be any parameters, right? Correct. There are no parameters. However, according to the specification, the "Home" space must still be allocated for all four registers even if there are no parameters. This is required in order to support un-prototyped functions in C.

So that answers part of the mystery. The 'lea' instruction is actually pointing to "RCX Home". Normally, when the C/C++ compiler is generating a function call, it automatically allocates space on the stack for this. But since our caller (call eax) was in assembly language, the author forgot to allocate the space, thinking it was just like IA-32 assembly. So the quick answer is: 

  sub rsp, 4 * sizeof (QWORD)
  call rax
  add rsp, 4 * sizeof (QWORD)

This code creates the "Home" area on the stack (even though the function has no parameters), calls the function and then deletes the "Home" area.

One More Mystery

But it doesn't answer all of my questions. Why was the lea edx pointing to the "RCX Home" (offset 48)? My examination of the C/C++ source code showed that this instruction was actually referring to a local variable. Aren't local variables supposed to be below RSP?

It took some detailed reading of the specification to find this little gem:

Even if the called function has fewer than 4 parameters, these 4 stack locations are effectively owned by the called function, and may be used by the called function for other purposes besides saving parameter register values.
 

So, the C/C++ compiler is using the extra stack space as temporary storage. It can do this because it knows that there were no function parameters. Rather using more stack, it just reuses the space already allocated by the caller. Smart stack usage. But confusing to old-time assembly language programmers.

Conclusion

That was one mystery, but not the only one. It turns out there is another caveat when calling from assembly to C/C++ functions. Prior to the function call, RSP must be aligned on a 16-byte boundary. By doing this, called functions can use aligned XMM instructions to access 16-byte instructions.

Looks like us old-time assembly language programmers need to keep up with the latest in compiler technology.

ACPI 4.0a Released

The ACPI 4.0a specification has been released, with numerous errata, here. Most appear to be minor corrections and enhancements related to Thermal and Power-State Dependencies, and the error reporting data structures.

HOW-TO: Track Down Bloated Drivers With LINK & DUMPBIN.

I was recently tracking down the root cause for a bloated driver executable, which had less than 150 lines but was over 60KB. So I started where I always do: DUMPBIN, a utility that ships with Microsoft Visual Studio and outputs a lot of information about a PE/COFF executable, including disassembly.

So, first I went into the build output directory:

CD temp\x64

Then I invoked DUMPBIN to disassemble my file to a text file.

DUMPBIN /disasm mydriver.DLL >tmp.txt

After examining the EXE for a while and taking the obvious steps, it became clear that some of my problems were related to the libraries. I found that (a) I didn't know which libraries were being linked in and (b) why certain functions and data structures were being brought in even though I didn't use them. So I turned to the linker. I went to the INF file of the driver and added the following line to the [nmake.common] section:

LINK_FLAGS = /VERBOSE $(LINK_FLAGS)

Then I went to the build directory and typed:

PHMAKE >tmp.txt

This redirected all of the linker output to my text file. The text at the end of the article is a sampel fo what I got.

By examining the output, it was clear that whenever I referenced an OBJ, the linker would bring in every function in a referenced OBJ (even if I specified /Gy for the C/C++ build options) and then would later discard those functions. But (and this was my problem) it did not discard global data that was brought in through this method, leaving it in the final EXE even though it was never used. From this I learned you need to separate global data from code in libraries unless they are always together.

If you know your tools, they can tell you a lot about what is going on under the hood in SecureCore Tiano™.

Tim

(Sample Output)

Searching libraries
    Searching F:\sct20c\Projects\Crb\000\temp\X64\HiiLib.lib:
    Searching F:\sct20c\Projects\Crb\000\temp\X64\libc.lib:
      Found DxeMainBSStartup
        Loaded libc.lib(DxeBSStartup.obj)
      Found exit
        Referenced in libc.lib(DxeBSStartup.obj)
        Loaded libc.lib(exit.obj)
      Found _initterm
        Referenced in libc.lib(DxeBSStartup.obj)
        Referenced in libc.lib(exit.obj)
        Loaded libc.lib(cinit.obj)
      Found gDS
        Referenced in libc.lib(DxeBSStartup.obj)
        Loaded libc.lib(dataDS.obj)

      ...
      Found EfiCompareGuid
        Referenced in EfiDriverLib.lib(ReportStatusCode.obj)
        Loaded EfiDriverLib.lib(EfiCompareGuid.obj)
      Found gEfiDebugMaskProtocolGuid
        Referenced in EfiDriverLib.lib(EfiDriverLib.obj)
        Loaded EfiDriverLib.lib(DebugMask.obj)

Finished searching libraries

Finished pass 1

    Discarded '.pdata' from libc.lib(exit.obj)
    Discarded '.pdata' from libc.lib(atexit.obj)
    ..

    Discarded "`string'" (??_C@_0DC@LMFNFFID@F?3?2sct20c?2System?2001?2Library?2Hii@) from HiiLib.lib(PackageList.obj)
    Discarded "`string'" (??_C@_0BM@JEBIDOHP@PackageList?5?$CB?$DN?5?$CI?$CIvoid?5?$CK?$CJ?50?$CJ?$AA@) from HiiLib.lib(PackageList.obj)
    Discarded atexit from libc.lib(atexit.obj)
    Discarded calloc from libc.lib(malloc.obj)
    Discarded realloc from libc.lib(malloc.obj)
    Discarded reallocf from libc.lib(malloc.obj)
    Discarded '.xdata' from EfiDriverLib.lib(ReportStatusCode.obj)
    Discarded '.xdata' from EfiDriverLib.lib(ReportStatusCode.obj)
    Discarded '.xdata' from EfiDriverLib.lib(ReportStatusCode.obj)

    ...
Starting pass 2
     EfiDriverLib.lib(Debug.obj)
     EfiDriverLib.lib(DevicePath.obj)
     EfiDriverLib.lib(EfiDriverLib.obj)
     EfiDriverLib.lib(LibGlobalErrorLevel.obj)
     EfiDriverLib.lib(EfiLibAllocate.obj)
     EfiDriverLib.lib(ReportStatusCode.obj)
     EfiDriverLib.lib(StatusCodeDataTypeId.obj)

HOW-TO: Use UUIDGEN To Generate C-Style GUIDs

Ok, I'm probably the last UEFI programmer to figure this out, but you can use UUIDGEN (which comes with Visual Studio) to generate C-style GUIDs. Just type:

uuidgen -s

and you'll get something like:

INTERFACENAME = { /* 6e43ed89-a0eb-49df-91c6-75e7874b8834 */
    0x6e43ed89,
    0xa0eb,
    0x49df,
    {0x91, 0xc6, 0x75, 0xe7, 0x87, 0x4b, 0x88, 0x34}
  };

Just replace INTERFACE name with your GUID name, remove the trailing ';' and beautify it  a bit and you get:

#define MY_GUID \
  {0x6e43ed89, 0xa0eb, 0x49df, \
  {0x91, 0xc6, 0x75, 0xe7, 0x87, 0x4b, 0x88, 0x34}} 

No magic. And, of course, don't forget uuidgen -n 256 to generate a lot of GUIDs.

HOW-TO: Change To A Module's Directory

One of the common tasks is switching back and forth between the different modules that make up a SecureCore Tiano™ project. These modules are listed in the Project.def file in the project's directory. For example, you might see:

Module Build,           000, BUILD      // location of the MAKEFILE.

...other modules...

Module Pentium,         000, CPU        // use Pentium CPU module.
Module Cantiga,         000, NB         // use Cantiga Chipset module.
Module ICH9,            000, SB         // use ICH9 South Bridge module.

Now you want to switch back and forth between the project directory and one of these modules. Here's a simple batch file that let's you type: module Pentium or module CPU and it will take you there. It does require you to set the PROJECTROOT and PROJECTTIP environment variables first (see su.bat from this blog before). And it requires that you have built the project before.

Tim

@if not "%1" == "" goto projecttip
@echo.
@echo Usage:
@echo   module module-name
@echo.
@echo Options:
@echo   module-name      Name of the SecureCore Tiano(TM) module.
@echo.
@echo Description:
@echo   This script changes the directory to the component specified in the
@echo   'project.def' file. Must be run after 'su.bat' For example, if
@echo   'project.def' says:
@echo.
@echo   Module Pentium,         000, CPU     
@echo.
@echo   You would type: Module Pentium OR Module CPU
@echo.  
@echo.
@goto exit

:projecttip
@IF NOT "%PROJECTTIP%"=="" GOTO STEP1
@echo PROJECTIP is not set.
goto exit

:STEP1
@IF EXIST "%PROJECTTIP%\temp\project.env" GOTO STEP2

@echo Project %PROJECTTIP% not built.
goto exit

:STEP2
@FOR /F "tokens=1,3" %%G IN (%PROJECTTIP%\temp\project.env) DO @IF /I "%%G"=="SCT_MODULE_%1" CD %PROJECTROOT%\%%H && @EXIT /B 0
@FOR /F "tokens=1,3" %%G IN (%PROJECTTIP%\temp\project.env) DO @IF /I "%%G"=="SCT_PATH_%1" CD %PROJECTROOT%\%%H && @EXIT /B 0

:exit

 

 

Check Out Wired.com's Gadget Lab Column

In Priya Ganapati's "Computer Makers Aim to Banish Boot-Up Blues" posting on October 2, 2009, Steve Jones, Phoenix Tech's vice president and chief scientist, provided some interesting quotes about the development of instant boot BIOS technology:

"'People want PCs to be like their toaster. Push a button and it is ready,' says Steve Jones, vice-president and chief scientist of core systems at Phoenix Technologies, one of the biggest BIOS makers."

“'If you pick up a phone, you expect to instantly hear a tone,' says Jones. 'That’s the future for computers, too.'”

"Jones says the ‘I am ready for use’ signaling is an important psychological factor for consumers. 'Bell Labs worked hard on this. They figured if you pick up the phone and didn’t hear something within 250 milliseconds, then you would be pretty uncomfortable with the device...'"

Read the entire article here:  http://www.wired.com/gadgetlab/2009/10/quick-boot/

HOW-TO: Change directory to source directory for a specific .EFI file.

Many times you will see a file name, such as SystemGraphicsConsoleDxe.efi. The "SystemGraphicsConsoleDxe" portion of that comes from the BASE_NAME keyword in the INF files. The following little batch file will change the directory wherever the INF is located that contains that BASE_NAME in SecureCore Tiano™. This relies on the environment being set up correctly, as described in SU.BAT.

@IF NOT "%1" == "" GOTO STEP0
@echo.
@echo Usage:
@echo   basename base-name
@echo.
@echo Options:
@echo   base-name       Base name (as specified in the module .INF).
@echo.
@echo Description:
@echo   This script changes the current directory to the directory which
@echo   contains the INF where BASE_NAME = base-name for the current project.
@echo.
@echo   The current project must already be set using su.bat
@goto exit

:STEP0
@IF NOT "%PROJECTTIP%"=="" GOTO STEP1
@echo Project not set. Please select a project tip using SU <project-name> <project-version>.
goto exit

:STEP1
@IF EXIST "%PROJECTTIP%\temp\module.list" GOTO STEP2
@echo Project %PROJECTTIP% not built.
goto exit

:STEP2
@FOR /F "tokens=1,2" %%G IN (%PROJECTTIP%\temp\module.list) DO @IF "%%G"=="%1" cd %%~pH && exit /b 0

:exit

HOW-TO: Change directory to a specific INF for SecureCore Tiano™ 2.0

Once you have used su.bat (from the previous article), you can use this one to change to the directory that contains a specific INF file. It uses one of the files output by the build process.

inf inf-file-name

Here is the text for the batch file. It assumes that su.bat has already been used.

@IF NOT "%1" == "" GOTO STEP0
@echo.
@echo Usage:
@echo   inf inf-base-name
@echo.
@echo Options:
@echo   inf-base-name    Name of the INF file in the current project without .INF
@echo.
@echo Description:
@echo   This script changes the current directory to the directory which
@echo   contains the specified INF file for the current project.
@echo.
@echo   The current project must already be set using su.bat
@goto exit

:STEP0
@IF NOT "%PROJECTTIP%"=="" GOTO STEP1
@echo Project not set. Please select a project tip using SU <project-name> <project-version>.
goto exit

:STEP1
@IF EXIST "%PROJECTTIP%\temp\module.list" GOTO STEP2

@echo Project %PROJECTTIP% not built.
goto exit

:STEP2
@FOR /F "tokens=1,2" %%G IN (%PROJECTTIP%\temp\module.list) DO @IF "%%~nH"=="%1" cd %%~pH

:exit

[Updated to add help information]

HOW-TO: Set Up Your SecureCore Tiano™ 2.0 Build Environment

Here's a handy little batch file to set up your build environment for a specific project that I use. It is also the basis for several other useful batch files I will introduce later. It assumes that Visual Studio 2005 or Visual Studio 2008 are already in your build path and the ASL compiler is in C:\ASL.

Just go to the root directory of your SecureCore Tiano™ 2.0 source code and type:

su <project-name> [<project-version>]

If you just type 'su', it will list all projects available. If you type 'su' and a project name and there is only a single version, that will automatically be selected. If there is more than one version available, then the possible versions will be listed.

The batch file sets up two environment variables: PROJECTROOT (which is the root directory of the code) and PROJECTTIP (which is the build directory).

@if not "%1" == "" goto projectroot
@echo.
@echo Usage:
@echo   su project-name [project-version]
@echo.
@echo Options:
@echo   project-name     Name of the SecureCore Tiano(TM) project.
@echo   project-version  Version of the SecureCore Tiano(TM) project. Must be
@echo                    three numeric digits. If not specified, then 000 will
@echo                    be assumed.
@echo.
@echo Description:
@echo   This script sets up the key environment variables for building a project
@echo   for SecureCore Tiano(TM) 2.0.
@echo.
@echo   Select project-name from one of the following:
@dir /b Projects
@goto end

:projectroot
@if not "%PROJECTROOT%" == "" goto projectrev
@set PROJECTROOT=%CD%
@path=%PROJECTROOT%\tools;%path%

:projectrev
@set PROJECTTIPREV=%2
@if not "%PROJECTTIPREV%" == "" goto project
@if not exist "%PROJECTROOT%\Projects\%1\001\project.def" goto defaultprojectrev
@echo More than one project revision present at %PROJECTROOT%\Projects\%1.
@echo Please choose with su %1 xxx (where xxx is the revision) from the following:
@dir /b %PROJECTROOT%\Projects\%1
@goto end

:defaultprojectrev
@set PROJECTTIPREV=000

:project
@if exist "%PROJECTROOT%\Projects\%1\%PROJECTTIPREV%\project.def" goto projecttip
@echo Could not find project file at %PROJECTROOT%\Projects\%1\%PROJECTTIPREV%.
@goto end

:projecttip
@set PROJECTTIP=%PROJECTROOT%\Projects\%1\%PROJECTTIPREV%

:end

BIOS Mysteries: 64-Bits & General-Purpose Registers

Have you ever seen code like this?

mov ecx, 1
push rcx

What is going on here? It appears that the code is pushing a 64-bit value and the upper 32-bits are uninitialized.  No further clues arise from scouring through the  instruction set reference for MOV in Volume 2B of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, where it says, "Both operands must be the same size, which can be a byte, a word, a doubleword, or a quadword." (page 3-641).

Is this a compiler bug? Well, I posed that question to the Microsoft Visual C++ gurus a while back and they pointed me to another part of the devref, this time section 3.4.1.1 of Volume 1, where it says:

When in 64-bit mode, operand size determines the number of valid bits in the destination general-purpose register:

• 64-bit operands generate a 64-bit result in the destination general-purpose register.
• 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register.
• 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or 48 bits (respectively) of the destination general-purpose register are not be modified by the operation. If the result of an 8-bit or 16-bit operation is intended for 64-bit address calculation, explicitly sign-extend the register to the full 64-bits.

Notice that in 64-bit mode, when the destination is a 32-bit general-purpose register, the upper 32-bits of the same register are zeroed!

Well, I didn't quite believe it, so I went to my handy American Arium and set up a test case. First, I initialized RCX to a known value. Then I stepped over an instruction which reloaded RCX with another value. Then I stepped over an instruction that just did a MOV ECX.  See the pictures below.

Sure enough! The upper 32-bits are zeroed and a mystery is solved.