《UEFI内核导读》UEFI Application Binary Interface (ABI)简介

UEFIABI与编译器调用约定详解,
文章详细阐述了UEFI(统一可扩展固件接口)在不同CPU架构和编译器下的调用约定,如MSVC/x86和x64下的差异。EFIABI规定了如何声明和使用UEFI标准API,以及C语言中的cdecl调用约定。在x86平台上,参数通常通过栈传递,而在x64平台,前五个参数使用寄存器,其余的才使用栈。文中通过示例展示了在汇编级别如何实现这些调用约定。

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

敬请关注:“固件C字营

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

         UEFI根据CPU体系结构和编译器的不同有着不同的“调用约定”统称之为“EFI ABI”。以MSVCx86/x64举例来说,默认MSVC/x86使用 C标准cdecl”,MSVC/x64使用“MSVC x64 ABI”。Gcc/x86使用“C标准cdecl”,Gcc/x64支持原生的“EFI ABI”。具体来说我们需要在调用到UEFI标准API或接口的函数前面使用 EFIAPI”进行声明,在EFI应用或驱动内部可以不使用。

        C Declaration的缩写(使用__cdecl编译参数),表示C语言默认的函数调用方法,所有参数从右到左依次入栈,这些参数由调用者清除,称为手动清栈。被调用函数不会要求调用者传递多少参数,调用者传递过多或者过少的参数,甚至完全不同的参数都不会产生编译阶段的错误,支持可变参数的函数。

        修饰名(Decoration name)"C"或者"C++"函数在内部(编译和链接)通过修饰名识别。因被调用函数不会要求调用者传递参数数量,cdecl调用约定仅在输出函数名前加上一个下划线前缀,如,原函数为function(int a, int b),输出格式为_function

        对于EFI ABI/MSVC/x86编译器,如果ESI, EDI, EBX, EBP被调用者用到,就会被调用者自动保存并恢复。EAX用来返回32/16/8bit函数返回值,EDX:EAX用来返回8字节的结构体,其他的类型使用EAX返回其指针。

       对于EFI ABI/MSVC/x64编译器,有类似的机制,区别在于使用不同的寄存器来传递参数和返回值。前5个参数使用寄存器传递,从第五个开始使用堆栈传递,例如,拥有5个整形参数的函数function (int a, int b, int c, int d, int e, int f);其规则是a in RCX, b in RDX, c in R8, d in R9, f then e pushed on stack,其他类型的参数根据参数类型不同其传递方式稍有不同,如下表。

例:

MSVC/x86

        该函数输入参数为一个32bit的整形,输出32bit的整形,功能是往Dr0寄存器写入一个32bit的整形值,以EFIAPI声明该函数使用cdecl调用约定,函数的32bit整形实参被压栈到esp+4的位置,通过mov指令读取,进而写入到dr0寄存器。函数返回值通过eax传递。调用AsmWriteDr0()函数的函数负责堆栈平衡。

;------------------------------------------------------------------------------

; UINTN

; EFIAPI

; AsmWriteDr0 (

;   IN UINTN Value

;   );

;------------------------------------------------------------------------------

global ASM_PFX(AsmWriteDr0)

ASM_PFX(AsmWriteDr0):

    mov     eax, [esp + 4]

    mov     dr0, eax

    ret

MSVC/x64

       该函数输入参数为一个64bit的整形,输出64bit的整形,功能是往Dr0寄存器写入一个64bit的整形值(高位被硬件忽略),以EFIAPI声明该函数使用“MSVC x64 ABI 调用约定。函数的64bit整形实参被传递到rcx寄存器,而不是通过堆栈来传递,同样函数返回值通过rax传递。调用AsmWriteDr0()函数的函数负责堆栈平衡。

;------------------------------------------------------------------------------

; UINTN

; EFIAPI

; AsmWriteDr0 (

;   IN UINTN Value

;   );

;------------------------------------------------------------------------------

global ASM_PFX(AsmWriteDr0)

ASM_PFX(AsmWriteDr0):

       mov     dr0, rcx

       mov     rax, rcx

       ret

       以上EFI ABI在各种底层库中被广泛使用,比如C语言访问MSR寄存器必须调用汇编代码就必须使用上述方式来实现。

更多导读,尽情期待!

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

   敬请猛戳下面链接,关注&转发

敬请关注:“固件C字营

点击左下角“分享”,快乐更多人

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

we-chat固件C字营

随着国家十四五新战略规划的推出,众多国内企业都参与到国产芯片替代浪潮中来,可以预测未来越多的国产芯片会被设计、生产和使用在我们日常所使用的电子产品中,国产芯片拥有巨大的市场前景。 目前国产芯片采用的体系架构主要有X86、ARM、MIPS、RISC V、PowerPC、Alpha等。我们知道电子产品正常工作必须要有操作系统和各种应用软件,没有操作系统和应用软件的芯片就是一堆废铁,而大多数人并不知道的是没有系统固件来加载操作系统的电脑亦是一堆废铁, UEFI就是由UEFI行业协会提出和维护一种行业标准的系统固件,它支持目前市面上的大多数芯片体系结构和操作系统,随着标准的不断演进相信越来越多的体系结构的芯片和操作系统会被支持。 笔者从事BIOS开发已有十余年的时间,见证了Legacy BIOS辉煌与隐退,也有幸了参与了新世纪初系统固件从Legacy BIOS往UEFI BIOS的迁移的全过程。科技行业风起云涌新技术新架构日新月异,每每回望不禁感慨我辈可谓是“眼见着他起高楼,眼见着他宴宾客”的那一波BIOS人。曾经系统固件江湖还是Legacy BIOS的天下,BIOS人使用汇编语言编码、通过中断来与操作系统沟通。自UEFI框架被广泛使以来开我们的发环境从纯汇编变成了99%的C语言加1%的汇编语言的模式,开发效率大大的加强了。 虽然UEFI框架大大加快了开发效率,但是由于系统固件开发属于比较偏门和专业的领域,学习和入门门槛比较高,现有的BIOS工程师又分布在大大小小的各个公司内部缺乏有效沟通和交流,同时BIOS源码又属于敏感和机密数据受到各种NDA限制,市面上对UEFI框架介绍的资料少之又少,因此笔者从2000左右开始就陆续以Cstyle_0x007为ID在https://blog.youkuaiyun.com/CStyle_0x007发布一系列博文,现已有数十篇原创文章。刚开始的想法是把博文当作工作笔记方便自己随时查阅,后来慢慢发展成了与业内外感兴趣的朋友的沟通交流的平台。 随手写的博文难免有错误与纰漏为了避免误导大众,准备把博文重新整理在纠正谬误同时也会补充一些新的内容,尽量做到所写的每句话都是无误的,也欢迎有兴趣的朋友踊跃提出意见和建议。组建了微信公众号,目的在于方便有兴趣的朋友一起交流,名字初步定为“固件C字营”,其中“固件”泛指一切固化的软件,这里主要指UEFI BIOS系统固件,“C”泛指“China“,我们可以把这里当作大家沟通交流的营地,我们会不定时发布一些行业资讯、工作、学习心得,感兴趣扫描下面二维码就可以加入,也可以发邮件到CstyleFirmWareCamp@outlook.com投稿分享你的想法。 本文取名《UEFI内核导读》这里的UEFI专指“UEFI BIOS”,全文专注于对UEFI内核的梳理与分享,同时兼顾对X86系统固件生态中常用的工程技术的介绍,主要包含以下内容:UEFI启动流程以及各个阶段主要完成的任务及参考的实现方式导读UEFI及PI规范中的常见Protocol的实现与使用技巧UEFI固件生态中常见外设、总线、行业标准的协议内容及使用方法 雄关漫道真如铁,而今迈步从头越,系统固件雄起之路道阻且长,相信我们的BIOS人一定可以为国产芯片的起飞助力、为系统固件团队的壮大贡献自己的一份微薄之力,为每一个不畏艰难、不惧寂寞坚守在工作岗位的BIOS人加油,好样的。
<think> 嗯,用户现在想了解在Windows系统中调用UEFI Runtime服务的方法。这个问题相当底层啊,看来用户对系统引导和硬件交互有深入了解的需求。 先梳理已知信息:根据用户提供的两个引用,UEFI为操作系统提供了启动服务(BS)和运行时服务(RT),其中RT服务在OS调用ExitBootServices后仍然有效。引用2还提到UEFI runtime driver的概念,比如UNDI驱动可以在OS环境下继续使用。 用户的上个问题及回答历史很重要。之前讨论过UEFI接口的基本结构,特别是BS和RT的区别。现在用户显然想深入RT服务的具体调用机制,特别是在Windows环境下的实现方式。 从技术角度看,这个问题有几个关键层面需要覆盖: 第一是调用前提——Windows必须在调用ExitBootServices后,通过特定内核接口访问RT服务。第二是调用方式,用户态驱动通过DeviceIoControl与内核通信,再由内核通过EFI_SYSTEM_TABLE定位Runtime Services Table。第三要强调RT服务的特殊性质,比如物理地址映射和同步要求。 考虑到用户可能是驱动开发者或系统工程师,回复需要包含具体的技术路径:从Win32 API调用到内核转换层再到UEFI实际执行的完整链条。特别要说明EFI_RUNTIME_SERVICES结构体的作用,它是所有RT服务的函数指针集合。 安全限制也必须强调——微软严格限制RT服务的访问权限,否则可能破坏系统稳定性。可以举例说明常见的RT服务类型,如时间、电源管理、变量存储等,但实际可用的服务取决于固件实现。 最后生成的三个问题要延续技术深度:调用机制细节、具体服务案例、以及安全限制范围,这样能帮助用户根据实际需求选择后续研究方向。 </think> 在Windows系统中调用UEFI Runtime服务需通过特定的内核级接口,其核心流程和技术要点如下: ### 一、调用前提条件 1. **系统状态要求** UEFI Runtime服务仅在操作系统调用`ExitBootServices()`后生效[^1],此时: - 启动服务(Boot Services)已被卸载 - 仅运行时服务(Runtime Services)和Runtime Drivers保留在内存中 - 操作系统已完全接管硬件控制权 2. **内存映射要求** Runtime服务的代码和数据页必须被标记为`EFI_MEMORY_RUNTIME`类型,确保OS内核不会回收或修改这些内存区域[^1]。 ### 二、Windows调用路径 ```mermaid graph LR A[用户态应用] --> B[DeviceIoControl API] B --> C[内核态驱动] C --> D[HalCallEfiRuntimeService] D --> E[EFI_RUNTIME_SERVICES结构] E --> F[具体Runtime服务函数] ``` 1. **内核驱动层** Windows通过`hal.dll`和`ntoskrnl.exe`提供桥接接口: ```c NTSTATUS HalCallEfiRuntimeService( _In_ ULONG ServiceIndex, // 服务标识符 _Inout_ PVOID ServiceParams // 参数结构指针 ); ``` 此函数直接访问`EFI_SYSTEM_TABLE->RuntimeServices`的函数指针表[^1]。 2. **运行时服务表结构** UEFI规范定义的函数指针结构(节选): ```c typedef struct _EFI_RUNTIME_SERVICES { EFI_GET_TIME GetTime; // 获取硬件时间 EFI_SET_TIME SetTime; // 设置硬件时间 EFI_GET_WAKEUP_TIME GetWakeupTime; // 获取唤醒时间 EFI_SET_WAKEUP_TIME SetWakeupTime; // 设置唤醒时间 EFI_GET_VARIABLE GetVariable; // 读取UEFI变量 // ... 其他服务函数指针 } EFI_RUNTIME_SERVICES; ``` ### 三、典型调用场景示例(获取硬件时间) 1. **用户态发起请求** 应用程序通过IOCTL调用内核驱动: ```cpp DeviceIoControl(hDevice, IOCTL_GET_EFI_TIME, NULL, 0, &timeBuffer, sizeof(timeBuffer), &bytesReturned, NULL); ``` 2. **内核层处理流程** 驱动转换请求为UEFI调用: ```c EFI_TIME efiTime; EFI_STATUS status = HalCallEfiRuntimeService( EFI_GET_TIME_INDEX, &efiTime ); ``` ### 四、关键限制与注意事项 1. **同步性要求** 所有Runtime服务调用必须是**同步操作**,且禁止在中断上下文调用[^2]。 2. **内存操作限制** - 输入/输出缓冲区需预先锁定物理内存(`MmLockPagableCodeSection`) - 禁止使用分页内存(Pageable Memory) 3. **安全机制** Windows 10+启用安全启动时: - 需驱动持有微软签名 - 访问`GetVariable/SetVariable`需`SeSystemEnvironmentPrivilege`权限 > ⚠️ 警告:错误调用可能导致系统稳定性问题,微软官方仅推荐在硬件抽象层(HAL)或特定固件管理驱动中使用[^2]。 --- ### 相关问题拓展 1. UEFI Runtime Driver与标准内核驱动在内存管理上有何本质差异? 2. 如何通过`SetVariable`实现Windows与UEFI固件间的双向数据传递? 3. 调用Runtime服务时如何处理ACPI_OS与UEFI的互斥访问冲突? [^1]: UEFI规范定义的操作系统接口架构 [^2]: Windows硬件兼容性规范对Runtime Driver的要求
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值