Step to UEFI (190)Segment Registers in 64 Bits mode

最近在 “Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4”看到下面这一段话:

以是说,在 64Bits模式下 CS DS ES SS 的 Base 无论设置为什么,都会被认为是0.

于是,做实验进行验证:

1.我尝试直接在BIOS中修改 GDT 发现会导致 Post 死机。

2.尝试编写一个Driver来完成加载新的 GDT 的事情。最简单的方法是修改前面的 CPUDxe。直接拿来主义将 CpuDxe Copy 一份修改为 MyCpuDxe。使用下面的语句进行编译:

build -a X64 -p ueficpupkg\UefiCpuPkg.dsc -m UefiCpuPkg\MyCpuDxe\CpuDxe.inf

3.根据前面的研究, DS 段选择子设置成 Base=0x4000 (CpuGdt.c)

  //
  // LINEAR_DATA64_SEL
  //
  {
    0x0FFFF,        // limit 15:0
//LABZDebug 0x0,            // base 15:0
   0x4000,            // base 15:0
    0x0,            // base 23:16
    0x092,          // present, ring 0, data, read/write
    0x0CF,          // page-granular, 32-bit
    0x0,
  },

4.上面的代码后,使用 Load MyCpuDxe.efi 加载运行。再使用之前的gdt.efi 查看当前的GDT。

5.随机选择一个内存位置,比如:0x3000.使用 Mem指令查看, 结果如下

Memory Address 0000000000003000 200 Bytes
  00003000: 36 EF 55 63 64 A5 7C 87-34 FF 57 73 66 B5 7E D6  *6.Ucd.|.4.Wsf.~.*
  00003010: 24 FF 47 73 76 B5 6E D6-A4 FF C7 73 F6 B5 EE D6  *$.Gsv.n....s....*
  00003020: A4 FD C7 71 F6 B7 CE D4-A4 DD C7 51 F6 97 EE F4  *...q.......Q....*
  00003030: 84 DD E7 51 D6 97 DE F4-C4 DD A7 51 96 97 8E F4  *...Q.......Q....*
  00003040: 11 3E 9D 0F 5A 17 38 9B-10 3E 9C 0F 5A 17 39 9B  *.>..Z.8..>..Z.9.*
  00003050: 30 BE BC 8F 7A 97 19 1B-30 BC BC 8F 72 97 19 1B  *0...z...0...r...*
  00003060: 30 BC BD 8D 7A 95 19 19-34 BC BA 9D 7E 85 1D 09  *0...z...4...~...*
  00003070: 3C EC B0 DD 76 C5 15 49-7C EC F0 DD 36 C5 55 49  *<...v..I|...6.UI*

使用 DCI 查看

使用 DCI 修改此处值

使用 DCI 修改此处值

Memory Address 0000000000003000 200 Bytes
  00003000: EF CD AB 90 78 56 34 12-34 FF 57 73 66 B5 7E D6  *....xV4.4.Wsf.~.*
  00003010: 24 FF 47 73 76 B5 6E D6-A4 FF C7 73 F6 B5 EE D6  *$.Gsv.n....s....*
  00003020: A4 FD C7 71 F6 B7 CE D4-A4 DD C7 51 F6 97 EE F4  *...q.......Q....*
  00003030: 84 DD E7 51 D6 97 DE F4-C4 DD A7 51 96 97 8E F4  *...Q.......Q....*
  00003040: 11 3E 9D 0F 5A 17 38 9B-10 3E 9C 0F 5A 17 39 9B  *.>..Z.8..>..Z.9.*
  00003050: 30 BE BC 8F 7A 97 19 1B-30 BC BC 8F 72 97 19 1B  9*0...z...0...r...*

这就说明无论DS 的 Base 是多少,都是按照默认为0 来处理的(当然基本的检查机制还是存在的,需要保证加载正确的描述符).

完整的实验代码和EFI下载:

Step to UEFI (191)GDT 中1Bit的差别

细心的读者会发现前面的GDT 试验中,设置的选择子和实际查看到的选择子有着1bit的差别。比如:

  //
  // LINEAR_CODE64_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x09A,          // present, ring 0, code, execute/read
    0x0AF,          // page-granular, 64-bit code
    0x0,            // base (high)
  },

实际读取到的是:

No.[7] Seg. Desc 0xAF9B000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
64-bit code segment

设置的是 9A 读取到的是 9B,二者相差1Bit。

对于这个问题开始研究。

首先确定差别的位置:

typedef struct _GDT_ENTRY {
  UINT16 Limit15_0;
  UINT16 Base15_0;
  UINT8  Base23_16;
  UINT8  Type;
  UINT8  Limit19_16_and_flags;
  UINT8  Base31_24;
} GDT_ENTRY;

是 Type 中有差别。结合【参考1】资料:

【参考1】

差别就是上图中 Type A Bit. 表示当前的是否被访问过。没有访问过就是 0,访问过就是1.

接下来通过一个实验来验证上面的知识。首先,选择一个 selector,我这里用的是下面这个

  //
  // LINEAR_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x092,          // present, ring 0, data, read/write
    0x0CF,          // page-granular, 32-bit
    0x0,
  },

最主要是直接使用这个我们就不用重新编译BIOS或者再写一个加载描述符的Application了。

其次,加载 fs 的代码如下:

[BITS 64]
mov ecx,28h
mov fs,cx

用Nasm 转化为机器码对应如下:

     1                                  [BITS 64]
     2 00000000 B928000000              mov ecx,8h
     3 00000005 8EE1                    mov fs,cx

使用之前的代码,我们写一个 LoadFS.efi代码如下:

#include  <Uefi.h>
#include  <Library/BaseLib.h>
#include  <Library/UefiLib.h>
#include  <Library/ShellCEntryLib.h>
#include  <Library/IoLib.h>

extern  EFI_SYSTEM_TABLE    *gST;
extern  EFI_BOOT_SERVICES   *gBS;

void
SetFS()
{
        __nop();
        __nop();
        __nop();
        __nop();
        __nop();
        __nop();
        __nop();
        __nop();        
}

/***
  Print a welcoming message.

  Establishes the main structure of the application.

  @retval  0         The application exited normally.
  @retval  Other     An error occurred.
***/
INTN
EFIAPI
ShellAppMain (
  IN UINTN Argc,
  IN CHAR16 **Argv
  )
{
        UINT8 *f=(UINT8 *)&SetFS;
        *(f+0)=0xB9;
        *(f+1)=0x08;
        *(f+2)=0x00;
        *(f+3)=0x00;
        *(f+4)=0x00;
        *(f+5)=0x8E;
        *(f+6)=0xE1;

        SetFS();
        return(0);
}

编译后就可以进行实验了,实验必须在实体机上进行。

1.启动到Shell 后先用 gdt.efi 查看一下

GDTR=0x8C634718
No.[0] Seg. Desc 0x0
Base=0x0
Limit=0x0
Descriptor Type: system
Not 64-bit code segment
No.[1] Seg. Desc 0xCF92000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment 
(后面省略)

注意 92 那个位置

2.运行 loadfs.efi

3.再次运行 gdt.efi 进行查看

GDTR=0x8C634718
No.[0] Seg. Desc 0x0
Base=0x0
Limit=0x0
Descriptor Type: system
Not 64-bit code segment
No.[1] Seg. Desc 0xCF93000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment
(后面省略)

可以看到已经变成了93h,就是说如果 selector被加载到某个段寄存器,对应的 selector上的 type accessed 位将会做出标记。

完整代码下载:

参考:

1.” Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4”  Figure 5-1. Descriptor Fields Used for Protection P2855

开机的窗口哪里来的?

最近发现开机之后桌面有一个弹出窗口,郁闷的是上面没有关闭按钮,也无法通过 ALT+F4关闭。

从上面也可以看出来制作广告的人非常不用心

为了确认这个窗口的归属,使用 SPY++

再进一步查看属性就得知他是多玩坦克世界盒子的广告窗口。关掉坦克世界盒子这个窗口也会随之消失。

我挺喜欢这个法系小炮的。射速快8s,一局时间越久,战绩通常越好。

Step to UEFI (189)Read&WriteMMX0

最近偶然看到BaseLib 提供了AsmReadMm0() 和AsmWriteMm0()函数,于是进行了下面的实验。

首先,用AsmReadMm0 读取当前 MM0 寄存器的值,然后随机生成一个再写入 MM0 中。

#include <Uefi.h>
#include <Library/BaseLib.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>

EFI_STATUS
EFIAPI
MMXTestMain (
  IN     EFI_HANDLE                 ImageHandle,
  IN     EFI_SYSTEM_TABLE           *SystemTable
  )
{
        UINT64  x=AsmReadMm0();
        Print(L"Current MM0 =0x%lX\n",x);
        AsmRdRand64(&x);
        Print(L"Random Value=0x%lX\n",x);
        AsmWriteMm0(x);

        return EFI_SUCCESS;
}

之后在 NT32Pkg 的模拟器中运行结果如下:

可以看到,前一次运行之后随机生成一个数值,写入MM0之后再次运行还可以读出。

=====================================================================================

R0-R7 是独立于 RXX 的寄存器,之前文章引用过一幅示意图,上面写的 RAX or R0 这句话会误导读者以为他们是同一个寄存器。

实际上,R0-R7 是用来进行浮点运算的 80Bits的寄存器。MMX0-7是R0-R7 0-64Bits的别名:

完整代码:

Step to UEFI (188)保护模式下的 GDT

在实模式下,内存寻址是通过 “段寄存器:偏移” 来进行的。保护模式出现之后,因为内存地址长度的增加,这样的方式无法完成(不够长)。为了解决这样的使用索引来处理成为顺理成章的事情。

同时为了考虑兼容性,最终引入了Global Descriptor Table 来进行扩展。关于内存的地址信息存放在这个  GDT 中。接下来 CS/DS/ES这样的段寄存器不再存放内存的地址而是存放 GDT 中的“第x个条目”这样的信息。再引入一个 GDTR 的寄存器存放 GDT 在内存中的位置。

在\MdePkg\Include\Library\BaseLib.h中有定义读取 GDTR 的函数。

/**
  Reads the current Global Descriptor Table Register(GDTR) descriptor.

  Reads and returns the current GDTR descriptor and returns it in Gdtr. This
  function is only available on IA-32 and x64.

  If Gdtr is NULL, then ASSERT().

  @param  Gdtr  The pointer to a GDTR descriptor.

**/
VOID
EFIAPI
AsmReadGdtr (
  OUT     IA32_DESCRIPTOR           *Gdtr
  );

读取之后的 GDTR 寄存器定义如下【参考1】:

在代码中定义如下:

///
/// Byte packed structure for an IDTR, GDTR, LDTR descriptor.
///
#pragma pack (1)
typedef struct {
  UINT16  Limit;
  UINTN   Base;
} IA32_DESCRIPTOR;
#pragma pack ()

Base 是给定 GDT 在内存中的地址,Limit 实际上是给出Table 的长度。从 Figure 2-6 可以看到,32位下和 64位下Limit 长度都是 16Bit的,但是 Base 的长度可能是32或者64位的,代码使用 UINTN 来实现一个 Structure 兼容2种情况。

获得了内存地址后就可以开始进行解析。其中的每一个项目结构体如下:

///
/// Byte packed structure for a segment descriptor in a GDT/LDT.
///
typedef union {
  struct {
    UINT32  LimitLow:16;
    UINT32  BaseLow:16;
    UINT32  BaseMid:8;
    UINT32  Type:4;
    UINT32  S:1;
    UINT32  DPL:2;
    UINT32  P:1;
    UINT32  LimitHigh:4;
    UINT32  AVL:1;
    UINT32  L:1;
    UINT32  DB:1;
    UINT32  G:1;
    UINT32  BaseHigh:8;
  } Bits;
  UINT64  Uint64;
} IA32_SEGMENT_DESCRIPTOR;

首先,我们编写一个读取解析的代码:

#include <Uefi.h>
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>
#include <Library/DebugLib.h>
#include <Protocol/PciIo.h>
EFI_STATUS
EFIAPI
GDTMain (
  IN     EFI_HANDLE                 ImageHandle,
  IN     EFI_SYSTEM_TABLE           *SystemTable
  )
{
        UINTN                    GdtEntryCount;
        IA32_SEGMENT_DESCRIPTOR  *GdtEntry;
        IA32_DESCRIPTOR          GdtrDesc;
        UINT16                   Index;
        
        AsmReadGdtr (&GdtrDesc);
       
        GdtEntryCount = (GdtrDesc.Limit + 1) / sizeof (IA32_SEGMENT_DESCRIPTOR);
        GdtEntry = (IA32_SEGMENT_DESCRIPTOR *) GdtrDesc.Base;
         Print(L"GDTR=0x%lX\n",GdtEntry);
        for (Index = 0; Index < GdtEntryCount; Index++) {
            Print(L"No.[%d] ",Index);
            Print(L"Seg. Desc 0x%lX\n",GdtEntry->Uint64);
            Print(L"Base=0x%lX\n",
                (GdtEntry->Bits.BaseHigh<<24)|
                (GdtEntry->Bits.BaseMid<<16)|
                (GdtEntry->Bits.BaseLow));                              
            Print(L"Limit=0x%X\n",
                (GdtEntry->Bits.LimitHigh<<16)|
                (GdtEntry->Bits.LimitLow));
            if (GdtEntry->Bits.S==0) {
                Print(L"Descriptor Type: system\n");
            }
            else {
                Print(L"Descriptor Type: Code or Data\n");
            }
            if (GdtEntry->Bits.L==0) {
                Print(L"Not 64-bit code segment\n");
                
            }else {
                Print(L"64-bit code segment\n");
            }            
            GdtEntry++;
        }

  return EFI_SUCCESS;
}

运行之后结果如下:

GDTR=0x8C634718
No.[0] Seg. Desc 0x0
Base=0x0
Limit=0x0
Descriptor Type: system
Not 64-bit code segment
No.[1] Seg. Desc 0xCF92000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment
No.[2] Seg. Desc 0xCF9F000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment
No.[3] Seg. Desc 0xCF93000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment
No.[4] Seg. Desc 0xCF9A000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment
No.[5] Seg. Desc 0x0
Base=0x0
Limit=0x0
Descriptor Type: system
Not 64-bit code segment
No.[6] Seg. Desc 0xCF93000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
Not 64-bit code segment
No.[7] Seg. Desc 0xAF9B000000FFFF
Base=0x0
Limit=0xFFFFF
Descriptor Type: Code or Data
64-bit code segment
No.[8] Seg. Desc 0x0
Base=0x0
Limit=0x0
Descriptor Type: system
Not 64-bit code segment

经过研究,代码中设置 GDT Table 是在 \Edk2\UefiCpuPkg\CpuDxe\CpuGdt.c 中,有定义 GDT 如下:

//
// Global descriptor table (GDT) Template
//
STATIC GDT_ENTRIES GdtTemplate = {
  //
  // NULL_SEL
  //
  {
    0x0,            // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x0,            // type
    0x0,            // limit 19:16, flags
    0x0,            // base 31:24
  },
  //
  // LINEAR_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x092,          // present, ring 0, data, read/write
    0x0CF,          // page-granular, 32-bit
    0x0,
  },
  //
  // LINEAR_CODE_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x09F,          // present, ring 0, code, execute/read, conforming, accessed
    0x0CF,          // page-granular, 32-bit
    0x0,
  },
  //
  // SYS_DATA_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x093,          // present, ring 0, data, read/write, accessed
    0x0CF,          // page-granular, 32-bit
    0x0,
  },
  //
  // SYS_CODE_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x09A,          // present, ring 0, code, execute/read
    0x0CF,          // page-granular, 32-bit
    0x0,
  },
  //
  // SPARE4_SEL
  //
  {
    0x0,            // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x0,            // type
    0x0,            // limit 19:16, flags
    0x0,            // base 31:24
  },
  //
  // LINEAR_DATA64_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x092,          // present, ring 0, data, read/write
    0x0CF,          // page-granular, 32-bit
    0x0,
  },
  //
  // LINEAR_CODE64_SEL
  //
  {
    0x0FFFF,        // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x09A,          // present, ring 0, code, execute/read
    0x0AF,          // page-granular, 64-bit code
    0x0,            // base (high)
  },
  //
  // SPARE5_SEL
  //
  {
    0x0,            // limit 15:0
    0x0,            // base 15:0
    0x0,            // base 23:16
    0x0,            // type
    0x0,            // limit 19:16, flags
    0x0,            // base 31:24
  },
};

为了验证前面的代码,我们可以在最后加上一个自定义的 Segment,编译后烧写到板子上再使用上面的工具查看,可以看到多出来的一项。

同一个文件中还有加载段描述的动作,在InitGlobalDescriptorTable函数中

  //
  // Update selector (segment) registers base on new GDT
  //
  SetCodeSelector ((UINT16)CPU_CODE_SEL);
  SetDataSelectors ((UINT16)CPU_DATA_SEL);

对应代码如下(Edk2\UefiCpuPkg\CpuDxe\X64\CpuAsm.asm):

;------------------------------------------------------------------------------
; VOID
; SetCodeSelector (
;   UINT16 Selector
;   );
;------------------------------------------------------------------------------
SetCodeSelector PROC PUBLIC
    sub     rsp, 0x10
    lea     rax, setCodeSelectorLongJump
    mov     [rsp], rax
    mov     [rsp+4], cx
    jmp     fword ptr [rsp]
setCodeSelectorLongJump:
    add     rsp, 0x10
    ret
SetCodeSelector ENDP

;------------------------------------------------------------------------------
; VOID
; SetDataSelectors (
;   UINT16 Selector
;   );
;------------------------------------------------------------------------------
SetDataSelectors PROC PUBLIC
    mov     ss, cx
    mov     ds, cx
    mov     es, cx
    mov     fs, cx
    mov     gs, cx
    ret
SetDataSelectors ENDP

分别加载了前面 Table 中的  LINEAR_DATA64_SEL和  LINEAR_CODE64_SEL到 DS CS 还有其他的段寄存器中。

使用前面介绍过的 DCI【参考2】进行查看:

1.直接查看gdtr (这步之前需要先 halt),可以看到里面的内容和Application 读取的是相同的,同样Limit=0x47,  (0x47+1)/8=9 ,也就是说有9项和读取结果相同。

2.查看 cs 寄存器(我不确定是否为这个命令,只是看着像),解析如下:

看到的内容比我们普通看到的会多一些,根据【参考3】和一些资料的介绍,保护模式下,CS 中装的是selector(选择子),此外还有一部分隐藏的,资料上称之为 Cached的内容。使用DBC 工具可以看到隐藏的部分确实有存放一些其他内容。csb 可能是 CS.Base的意思,csl 可能是 CS.Limit 的意思。

同样的在【参考4】也有描述:

Every segment register has a “visible” part and a “hidden” part. (The hidden part is sometimes referred to as a “descriptor cache” or a “shadow register.”) When a segment selector is loaded into the visible part of a segment register, the processor also loads the hidden part of the segment register with the base address, segment limit, and access control information from the segment descriptor pointed to by the segment selector. The information cached in the segment register (visible and hidden) allows the processor to translate addresses without taking extra bus cycles to read the base address and limit from the segment descriptor. In systems in which multiple processors
have access to the same descriptor tables, it is the responsibility of software to reload the segment registers when the descriptor tables are modified. If this is not done, an old segment descriptor cached in a segment register might be used after its memory-resident version has been modified.

这部分在BIOS中从来不会有错,因为上来之后就会被设置为0-4G 全部都可以访问,代码中也不会进行修改。但是这部分知识对于掌握X86系统结构是非常有必要的。

参考:

  1. 64-ia-32-architectures-software-developer-vol-3a-part-1-manual  P74
  2. http://www.lab-z.com/ccadbc/ INTEL CCA/DBC简介
  3. https://www.sandpile.org/x86/sreg.htm
  4. Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4     P2796

UDK201905来了

之前介绍过 UDK201903,这一段的实验也都是基于这个版本的。最近发现有更新的 UDK201905。在https://github.com/tianocore/edk2/releases/tag/edk2-stable201905 可以看到。增加了如下特性:

特别值得注意的是Nt32Pkg已经被移除了,取而代之的是EmulatorPkg。

下载代码后试验编译,我将之前UDK201903的BaseTool copy到这个目录下。然后使用 “VS2015 x64 Native Tools Command Prompt”进行编译。编译命令是 “build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -D WIN_SEC_BUILD -a X64”。

编译之后模拟器在201905\Build\EmulatorX64\DEBUG_VS2015x86\X64\WinHost.exe 直接运行之即可。

新的模拟器

后面会进一步研究,特别是针对模拟器部分。

完整的编译环境可以在这里下载

链接: https://pan.baidu.com/s/1fO7XISwfcc79rZaMbydtQw 提取码: insn

记一个诡异的问题

最近在实验屏幕PSR功能的时候碰到一个诡异的问题。具体现象就是:鼠标可以打开桌面上的一个目录,然后就出现鼠标可以移动但是不能点击任何内容的情况。这个时候键盘仍然是可以使用的。

起初我怀疑是系统装了很多乱七八糟的软件导致的问题。然后将这个硬盘换到其他的机器上就没有这样的现象了。接下来就怀疑BIOS导致的,但是理论上BIOS不会导致系统下这样的情况。出现问题的时候,鼠标可以移动,Touch Pad(键盘下面的触摸板)也是可以移动的,但是无法点击。

偶然之间,我换了一个鼠标惊奇的发现问题消失了。然后意识到问题真的有可能是我的鼠标导致的。因为那个鼠标是我刚维修更换过微动的微软 1.01 鼠标,并且这个鼠标是复刻版的微软 1.01,换句话说,这个鼠标除了里面的电路板是微软原装,其他的东西要么是山寨的,要么是我自己维修更换过的。额外说一句,我很喜欢这个型号的鼠标,握起来感觉很好。但是这个对于手小的人来说非常别扭。这个型号的鼠标我有5个,除了1个是十年前购买的原装,其余都是复刻的。我一直用他们办公或者测试。

为了验证猜想,我在一台装有USBlyzer 的机器上实验这个鼠标,仍然能看到现象。接下来打开软件开始抓包。发现出现问题时这个鼠标的Button5 一直处于按下的状态。正常情况下,按下按键后会发出“鼠标X Button 按下”的消息,抬起的时候还会发出“鼠标X Button 抬起”的消息。比如下面就是一个例子:

 按下 Button 5

抬起 Button 5

对于出现问题的鼠标来说,无论如何移动,一直都有 Button5 被按下的消息存在。因此系统无法正确响应,导致了前面提到的问题。 其中的Button5 位于图片中的这个位置。

应该是我在安装时机构建没有完美对齐导致这样的问题。最终拆卸重新安装问题就消失了。

最难解决的问题是看不到现象的问题。譬如说阅读《福尔摩斯全集》的时候每次都是有人来找福尔摩斯然后他们兴高采烈的去出现场然后发现蛛丝马迹,从来没有福尔摩斯问了几句就知道真相的,毕竟侦探小说不是通灵传奇。对于我们 Debug 也一样。特别是没有条件提供对方现场,只能进行现象描述的时候,如果能站在对方的角度思考尽可能多的提供线索也可以提让提问更加有效。

Step to UEFI (187)一个奇怪的编译Bug

最近在编写代码的时候遇到一个非常奇怪的问题,经过化简,出现问题的代码如下:

#include <Uefi.h>
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>
#include <Library/DebugLib.h>

EFI_PCI_IO_PROTOCOL         *mFFIO = NULL;

EFI_STATUS
EFIAPI
MSMain (
  IN     EFI_HANDLE                 ImageHandle,
  IN     EFI_SYSTEM_TABLE           *SystemTable
  )
{
  Print(L"LabZ Test\n");

  return EFI_SUCCESS;
}

INF 如下:

[Defines]
  INF_VERSION                    = 0x00010005
  BASE_NAME                      = mst
  FILE_GUID                      = fb925ac7-192b-9569-8580-7c6f5f710601
  MODULE_TYPE                    = UEFI_APPLICATION
  VERSION_STRING                 = 1.0
  ENTRY_POINT                    = MSMain

#
# The following information is for reference only and not required by the build tools.
#
#  VALID_ARCHITECTURES           = IA32 X64 IPF
#

[Sources]
  MSTest.c

[Packages]
  AppPkg/AppPkg.dec
  MdePkg/MdePkg.dec

[LibraryClasses]
  UefiApplicationEntryPoint
  UefiLib
  BaseLib

错误提示为:

c:\buildbs\201903\AppPkg\Applications\MSTest\MSTest.c(20): error C2143: syntax error: missing '{' before '*'
c:\buildbs\201903\AppPkg\Applications\MSTest\MSTest.c(20): warning C4218: nonstandard extension used: must specify at least a storage class or a type
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Vc\bin\x86_amd64\cl.exe"' : return code '0x2'
Stop.

百思不得其解,不知道这么简单的一句话为什么会导致这样奇怪的问题。有兴趣的朋友可以先花费三分钟思考一下。

忽然想起来最近学到的一个 VS 编译指令 /P 【参考1】,可以将宏展开进行查看,于是在 INF中加入下面的参数:

[BuildOptions]
  MSFT:*_*_X64_CC_FLAGS  = /P

在 \Build\AppPkg\DEBUG_VS2015x86\X64\AppPkg\Applications\MSTest\MSTest 下面看到 MSTest.i 中有下面的定义。出现问题的原因就是:EFI_PCI_IO_PROTOCOL  未定义。

EFI_PCI_IO_PROTOCOL         *mFFIO = ((void *) 0);

EFI_STATUS
__cdecl
MSMain (
       EFI_HANDLE                 ImageHandle,
       EFI_SYSTEM_TABLE           *SystemTable
  )
{
  Print(L"LabZ Test\n");

  return 0;
}

找到了问题的原因,解决方法很简单,在C 文件中加入#include <Protocol/PciIo.h> 即可。但是按道理,这种情况应该出现 “identifier “EFI_PCI_IO_PROTOCOL” is undefined”的错误提示,不知道为什么这里没有出现。

参考:

1. https://docs.microsoft.com/en-us/cpp/build/reference/p-preprocess-to-a-file?view=vs-2019 /P (Preprocess to a File)

Krishna 的获取屏幕历史信息工具

最近 Krishna 做了一个能够读取分析 UEFI Shell 下屏幕历史信息的工具。比如,你想得到某一个 Application 的输出结果,可以先让他运行一次,然后用这个工具抓取之前的输出结果。

这是用这个工具取得 BIOS Version 和 FPT 版本号的例子

具体项目在 https://github.com/krishna116/UefiTest 有兴趣的朋友可以去围观一下。