Enterprise Just Builder

Solution for Enterprise Software Architecture

平台开发

WDF 驱动程序开发

设备驱动程序是硬件设备连接到计算机系统的软件接口,任何设备都必须有相应的驱动程序才能在计算机系统上正常工作。设备驱动程序的优劣直接关系到整个系统的性能和稳定性,因此,设计和开发稳定高效的驱动程序具有重要意义。

WDF (Windows Driver Foundation) 是微软新一代驱动程序模型,它在 WDM (Windows Driver Model) 的基础上发展而来,支持面向对象、事件驱动的驱动程序开发,提供了比 WDM 更高层次的抽象,是高度灵活、可扩展、可诊断的驱动程序框架。WDF 框架接管了驱动和操作系统内核的大多数交互,驱动和操作系统的交互交给框架内封装的方法(函数)完成,从而对二者进行了隔离,这样驱动开发者只需专注处理硬件的行为即可。另外 WDF 还将大多数驱动中都需要处理的 PnP (即插即用)和电源管理封装进了框架,成为了公用的驱动程序功能。

WDF 可以开发内核模式驱动, 也可以开发用户模式驱动,二者采用同一套对象模型构建,即 WDF。对于内核模式对象和用户模式对象来说,WDF 是它们的父对象。换言之两者都是从 WDF 派生而来的。针对内核模式派生出来的对象称为 KMDF;针对于户模式派生出来的对象称为 UMDF。无论何种模式的框架,其内部封装的方法、执行的行为其实还是用 WDM 来完成的。

本文主要针对 KMDF 框架展开讨论。

KMDF 对象模型
KMDF 驱动程序模型支持面向对象、事件驱动。它定义了一系列的对象用于表示设备、驱动、中断等,每个对象有其相应的属性、方法和事件。驱动程序利用这些方法创建对象、设置属性和响应事件。该框架定义的主要对象有:

>>> 阅读全文

 

, , ,

SPB 设备和驱动简介

现在有许多文章介绍 Windows 8 操作系统层级的功能。其中之一就是支持简单外设总线 (SPB) 连接的设备。SPB 总线具有低成本、低功耗、低速度的特点,经常用于连接如传感器之类的相对简单的外设。Windows 8 支持的 SPB 设备包括 I2C 和 SPI。之前这类设备受到 BIOS 的限制而很少使用。从 Windows 8 开始,支持这些设备则成为了主流。

如果你对 SPB 总线以及如何编写 SPB 设备驱动感兴趣,可以跟随本文1来深入探讨这些话题。

SPB 总线 — 拓扑和设备枚举
和 SCSI、 SATA 和 USB 总线一样,SPB 是协议式(protocol-based ) 总线。也就是说,有一个控制器会根据总线定义的规则使用正确的协议来请求开关总线。连接到协议式总线上的设备被称为客户端设备,简称客户端。如图1-1.

SPB 总线最让人困惑的地方是如何发现和枚举总线上的设备。 SPB 总线无法动态枚举,这意味着在运行时接上 SPB 总线的设备都无法被发现。那么 Windows PnP 过程如何侦测 SPB 客户端的呢?答案很简单:哪个 SPB 设备挂在哪条 SPB 总线,这些描述被静态添加到一个表中,作为 ACPI BIOS 一部分。所以,枚举 SPB 客户端是由 ACPI 驱动而不是 SPB 控制器驱动负责的。SPB 控制器是典型的背板总线(backplane-bus )类型的设备,总被 PCI 总线驱动所枚举。详细可以参考图1-2 和图1-3。

包含该描述的 ACPI 表格被称为差异系统描述符表(Differentiated System Descriptor Table)简称 DSDT。DSDT 通常由系统集成商(一般是 OEM ) 随 ROM 一起提供的。由于 SPB 设备通常都被永久集成在系统平台上 — 大部分被焊在主板上,所以无法动态枚举不会有任何问题。 少数情况下,SPB 设备可能会被动态地接上系统(比如平板电脑的 I2C 键盘),此时设备信息仍由 ACPI BIOS 提供并由 ACPI 驱动枚举。

>>> 阅读全文

 

, , , , ,

Windows 连接管理器和 NCM 驱动

从 Windows 8 开始,微软引入了自动连接管理器,它负责查看系统的网络连接如以太网、Wi-Fi 和移动网络,从中选择最合适的网络并自动连接,同时断开其他连接。(注:Windows 会响应以太网,但不会自动管理其连接。另外:拨号上网或者虚拟网络接口如 VPN 不在其管理范围中)。1

连接管理器策略
Windows 内置了许多策略来控制连接管理器,Windows 并未提供用户界面来查看这些策略,但可利用 WcmSetProperty API 或组策略来进行配置。这些策略包括:

最少并发连接数
该策略在 Windows 8 或 8.1 中是默认打开的。如果禁用该策略,操作系统行为将与 Windows 7 类似:每个网络接口都选择其所辖的首选网络,而不管其他接口的连接状态。

如果启动该策略,Windows 会尝试用最小并发连接来提供最佳的可用网络,Windows 将保持下列连接:

  • 任何以太网
  • 当前用户会话中手动连接的任何网络
  • 连接到 Internet 的首选连接
  • 连接到活动目录域的首选网络(入域的机器)

其他的所有网络则被“软”断开,有关“软”断开请见下一节。这也用于评估未被连接的可用网络。Windows will not connect to a new network from which it would immediately soft-disconnect.

>>> 阅读全文

 

,

X64 寄存器、栈帧和汇编

多年以来人们一直使用 X86 汇编编写性能关键代码。随着 32位 CPU 逐渐被 64 位处理器取代,底层汇编代码也随之发生变化。本文将简单介绍 X64 汇编一些相关知识。了解 X86 汇编虽然有助于了解这种过渡,不过不是必要前提。http://www.ejb.cc/wp-admin/profile.php

X64 泛指 Intel/AMD 的 32 位 X86 指令集架构 (ISA) 的 64 位扩展。AMD 率先推出了第一代 X64 指令集。即 X86-64,后来被命名为 AMD64。Intel 的实现称为 IA-32e ,后来又改为 EMT64。这两个版本大致相同,只在一些细微处略有不兼容。详细可以参考 《Intel® 64 and IA-32 Architectures Software Developer’s Manuals》 和 《AMD64 Architecture Tech Docs》。本文中将其统称为 X64 ,以区分 Intel 64 位安腾架构 IA-64。

本文将不涉及缓存、分支预测等等与硬件相关的内容,如果读者感兴趣,可以参考本文列出的一些参考文章。1

汇编常被用来编写程序性能关键部分,虽然大部分程序员还是宁可选择好的 C++ 编译器。掌握汇编对代码调试十分有用,有时候编译器会产生错误的汇编代码,通过调试器单步执行代码可以有助于了解错误的原因;代码优化有时也会产生错误。如果手边没有源代码,你还可以通过汇编/反汇编来了解或修正手边的程序;此外如果你想深入了解语言的内部机制,比如方法 A为什么比方法 B 速度快,这时候汇编就十分必要;最后,在诊断恶意代码时,汇编也不可或缺。

架构
要学习平台汇编,首先就得了解寄存器集。

>>> 阅读全文

 

, ,

Linux和Windows设备驱动架构比较

本文将考查最为广泛使用的 Windows 和 Linux 操作系统的设备驱动架构。我们首先将展示并比较在这些操作系统中实现设备驱动所需的组件,然后讨论实现驱动程序的过程,包括对内核缓冲区执行 I/O 操作。在文章的末尾我们还将了解这些操作系统所提供的开发环境和基础工具。1

1.引言
现代操作系统一般都包含多个模块,如内存管理器、进程调度器、硬件抽象层和安全管理器等等。想进一步了解这两种操作系统的内核,这里有一些参考资料:关于 Windows 内核的细节,可翻阅 Russinovich 著的《Windows Internal》一书;而 Linux 内核则可以参考 Rusling 的《The Linux Kernel》或者 Beck et al 等合著的《Linux Kernel Internals》。对和各类型硬件设备交互来说,内核可被视为一个黑盒。那么能否将和所有已知设备交互的功能内建到内核中呢?有可能,但没有实际意义,因为这会无谓地消耗太多系统资源。

内核模块化
对于各种新设备,内核无法在创建时就预知如何与之交互。现代操作系统的内核允许通过运行时添加设备驱动模块来扩展系统功能,该模块实现的功能使得内核可以与某种特定的新设备交互。这些模块通常都会实现一个例程供内核在模块被加载时调用,此外还有例程则在模块被移除时调用。模块还会实现各种不同的例程以便实现 I/O 功能,如将数据传送到设备或从设备接收数据;同时还有例程以便向设备发送 I/O 控制指令。以上所述对 Linux 和 Windows 两种驱动架构均适用。

本文的组织结构
本论文分成下面几节:

  • 对两种驱动架构的一般介绍 (第二节)
  • 详细论述两种驱动架构的各个组件 (第三节)
  • 驱动程序范例,包括如何对内核缓冲区执行 I/O 操作(第四节)
  • 相关驱动开发环境和基础工具(第五节)

相关著作
Windows 设备驱动架构相关文档可在 Windows 驱动开发包(DDK)中找到. 此外 Walter Oney 和Chris Cant 在 《Writing Windows WDM Device Drivers》一书中对 Windows 驱动架构进行了详细介绍。Linux 设备驱动架构可以参考 Rubini 的《Linux Device Drivers》,该书可免费获取。

>>> 阅读全文

 

, , , , ,

理解 ACPI (一) ACPI 简介及加电过程

在引入高级配置和电源接口 (ACPI — Advanced Configuration and Power Interface) 之前, 高级电源管理 (APM) BIOS 被广泛用于电源管理。在 APM 中,大部分的电源管理控制逻辑都驻留在 APM BIOS 代码中。支持 APM 的操作系统通过固定的 BIOS API 与 APM BIOS 进行通信,这些 API 提供了 BIOS 功能的基本访问。支持 APM 的操作系统必须定期轮询 APM 以处理 APM 相关事件。

APM 存在着以下三个缺陷: 首先,除非供应商提供专有程序,否则很多 APM 功能都要在操作系统启动前,进入 BIOS 菜单来配置,比如设置显示器关闭前的空闲时间。而且 APM 电源管理配置的具体策略是由 BIOS 供应商设定的,比如某 APM BIOS 的策略是在关闭显示器的同时降低 CPU 时钟频率或休眠网卡等设备,如果不想这么做,就必须修改 BIOS。 其次,APM 是 BIOS 级别的代码,运行在操作系统之外,因此开发和调试 APM 代码都十分困难,更糟糕的是用户只能通过重刷 ROM 的方式来解决 APM 的错误,而重刷 BIOS 相当危险,一旦发生错误,系统就再无法启动了。最后,由于 APM 是各个供应商专有的,为相同的功能而进行的重复开发投入是种巨大浪费。

不同于 APM 直接基于 BIOS 的管理方式,ACPI 中不再由 BIOS 代码来作出决策,而是通过操作系统内核来统一管理所有设备,从而解决了 APM 配置机制的局限性,换句话说,ACPI 允许操作系统直接对电源和散热进行管理,还允许系统硬件产生的 Hot-Plug 事件,让操作系统从用户的角度上直接支配即插即用设备。因而 ACPI 比其他机制更加灵活。

ACPI 主要提供下列功能:1

  • 系统电源管理(System power management):ACPI 提供了让系统作为一个整体进入或离开睡眠状态的机制,让设备唤醒系统。
  • 设备电源管理(Device power management):ACPI 表描述了电源信息(包括主板设备、设备电源状态以及设备所连接的电源层– Power Planes) 和让设备进入低功耗状态的控制信息,这样操作系统就可根据资源占用来控制设备进入低功耗状态。
  • 处理器电源管理(Processor power management):当操作系统处于空闲且非睡眠状态,可以通过 ACPI 提供的命令让处理器进入低功耗状态。
  • 设备和处理器性能管理(Device and processor performance management):操作系统在工作时可以根据 ACPI 的定义,让设备和处理器进入不同的性能状态
  • 配置/即插即用(Configuration/Plug and Play):ACPI 指定了用来枚举和配置主板设备的信息,这些信息按层次结构排列,当发生诸如 docking/undocking 之类的事件时,操作系统就可准确知道该事件影响了哪个设备。
  • 系统事件(System Event): ACPI 提供了通用的事件机制操作用于处理如散热、电源管理、坞站或设备的插拔等事件。
  • 电池管理(Battery management):兼容 ACPI 的电池设备需要具有智能电池子系统接口(Smart Battery subsystem interface)或者控制型电池接口(Control Method Battery interface),前者通过嵌入式控制器的接口控制,后者则完全由 AML 控制方法进行操控。
  • 温度管理(Thermal management):ACPI 允许 OEM 自由定义散热温度区间。
  • 嵌入式控制器(Embedded Controller):ACPI 提供了标准接口让操作系统和嵌入式控制器进行通讯。
  • SMBus 控制器(SMBus Controller): ACPI 提供了标准接口让操作系统和 SMBus 进行通讯。

当然为此操作系统内核中要添加额外的 ACPI 支持。支持 ACPI 的操作系统就可以叫做 OSPM (Operating System-directed configuration and Power Management) 。 支持 OSPM 的至少要求实现:

>>> 阅读全文

 

, , , ,

Windows CSRSS 详解 (1) 基础概念

微软之所以引入 “Windows 环境子系统” 这一概念,其理念是为了用户程序提供一个严格定义的原生函数子集。这是因为 Windows 操作系统被设计成同时支持原生 Windows 和 POSIX 类型的可执行程序(在 Windows 10 Red Stone 中还新添加了 Windows Subsystem for Linux 子系统),因此对于每一类应用,开发者必须区隔其所调用的 API。每个环境子系统通常包含两个主要部分:1

  • 子系统进程:一个正常的 ring-3 级应用程序,负责处理某些子系统特定的功能。
  • 子系统 DLL: 特定子系统专用的系统类库集,是额外添加在用户程序与原生系统调用间的调用层。

事实上 Windows 子系统 — — 也称为 CSRSS (客户端/服务器运行时子系统 Client/Server Runtime Subsystem) 是系统强制的执行环境,换句话说,如果没有没有 CSRSS.exe 在后台运行, Windows 不能正确工作。由于 CSRSS 所绑定的职责,该子系统对每个 Windows 都是必须的,包括服务器版本 (它可以不处理交互式用户会话)。另一方面,POSIX (psxss.exe) 和 Windows Subsystem for Linux 属于可选子系统 — — 因此,只在需要才启动相关进程。

子系统的启动信息被保存在注册表键 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems 下面。默认的启动信息配置如下:

  • 名称: Debug 类型: REG_EXPAND_SZ 数据:
  • 名称: Kmode 类型: REG_EXPAND_SZ 数据: \SystemRoot\System32\win32k.sys
  • 名称: Optional 类型: REG_MULTI_SZ 数据: Posix
  • 名称: Posix 类型: REG_EXPAND_SZ 数据: %SystemRoot%\system32\psxss.exe
  • 名称: Required 类型: REG_MULTI_SZ 数据: Debug Windows
  • 名称: Windows 类型: REG_EXPAND_SZ 数据: %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileC

大多数人对支持 Windows API 的子系统 DLL 都有所耳闻 — 即 kernel32.dll、 user32.dll、 gdi32.dll、 advapi32.dll 等等,无数的 Windows 软件开发者在日常工作中都会用到它们。而对于 POSIX 子系统来说,只需用到 psxdll.dll 这一个模块就可以实现所需的 Unix API。

此外,每一个进程都会与某个特定的子系统关联,该属性是由链接器在编译过程中设置的,并保存在 PE 结构的相关字段中:

>>> 阅读全文

 

, ,

CPU C-State 详解

如果你对计算机电源管理方面有所了解,一定会接触到 S-States、C-States 和 P-States 这三种工作状态。其中S-States (Sleeping states)指系统睡眠状态 ,由 ACPI 规定,C-States(CPU Power state) 则是 CPU 电源状态,而 P-States (CPU Performance states) 则指 CPU 性能状态。当然除了这三种外,还有 G-States(全局状态)和 D-States (设备状态)。

S-States 很好理解,就是用户手动点击“睡眠”,或者达到一定的待机时间(由系统电源管理设置而定)进入睡眠状态,S0 就是指正常运作。而 C-States 和P-States 看起来也很类似,都会调节处理器的核心电压、电流以及频率,因此经常被混淆。我们通过图1-1 来梳理一下上面这三种状态的关系。

S-States 中的 S0 指非睡眠状态,即系统正常运作状态或待机状态(idle)。只有在 S0 状态下,C-States 才会存在。同样的,C0 代表 CPU 正常工作状态,而P-States 正是处理器正常运作时的状态,所以 P-States 只存在于 C0 状态下。

因此简单来说,P-States 是根据系统的负载情况调节处理器核心电压和频率,处理器仍在运作当中;而 C-States 则是改变处理器各个部分的状态,包括核心、缓存、总线以及各种后来集成进来的模块,此时处理器应该是处于工作或待机状态。我们日常使用电脑的时候,系统就是频繁地在这些状态下切换,以达到提高续航和降低功耗的目的。1

C-States 的 11 个工作状态
目前 C-States 有以下这11个状态:

>>> 阅读全文

 

, ,

Windows 驱动开发 <1> 理解 Windows 驱动的执行上下文

要理解 Windows 内核驱动,很重要的是要了解一个驱动函数是在哪一种”上下文”中执行的。如果你从事文件系统的开发、或 Windows 内核驱动的编写,透彻理解执行上下文将使你获益匪浅。了解上下文并小心使用,可以让你设计出高性能、低开销的内核驱动。

本文将探讨执行上下文的概念。在文章末尾,沃恩还会介绍一个驱动作为概念演示,该驱动可以允许用户态程序运行在内核模式中,因此拥有内核模式的所有权限与特权。此外,我们还将讨论设备驱动程序的执行上下文及其实际用途。1

什么是上下文
当提到某个例程的上下文时,其实指的是它的线程和进程执行环境。在 Windows NT 中,该环境是由当前的 TEB (Thread Environment Block) 和 PEB (Processes Environment Block) 所建立的。因此,上下文中将包括虚拟内存配置 ( virtual memory settings — 用于说明物理内存页与虚拟内存地址的对应关系) 、句柄对照表 (handle translations, 因为句柄是特定于进程的)、分发器信息( dispatcher information)、栈(stacks) 、通用和浮点寄存器集等内容。

如果我们问“某个内核例程所运行的上下文是什么”,实际上的问题是“内核分发器所建立的当前线程是什么”。由于每个线程仅可属于一个进程,所以当前线程同时也就意味着某个当前进程。当前线程和当前进程合在一起,就意味着我们前面提到的句柄、虚拟内存、调度状态等等,这些东西使得线程和进程具有唯一性。

对于内核驱动程序员来说, 上下文中最有用的也许就是虚拟内存上下文。如果你还记得 Windows 将用户进程空间映射到低 2GB 的虚拟内存地址中,而操作系统代码则被映射到高 2GB 虚拟内存空间中。当用户进程中的某个线程被执行时,其虚拟地址将位于 0~2GB 的范围中。所有高于 2GB 的地址都被设置为“不可访问”,以防用户直接访问操作系统的代码和数据结构。当操作系统代码被执行时,其虚拟地址范围是 2~4GB。

>>> 阅读全文

 

,

USB 协议详解之一 基础知识

在 USB 出现前,计算机上就已经存在众多接口标准,比如串口、并口、PS2 等等,各接口从硬件形状和软件设置都不兼容,因此 USB 的设计目标之一,就是希望通过它方便地实现设备之间的互联。从而解决接口标准太多的弊端,这也是 USB 中的 Universal 一词的含义。

USB 使用一个 4 针的标准插头,采用菊花瓣形式把所有外设连接起来,它使用串行方式传输数据,支持多数据流和多个设备并行操作并允许外设热插拔。

基础知识
从物理结构上,USB 系统是一个分层的星形结构,它包含三类硬件设备:主机(HOST)、 设备(DEVICE)和集线器(HUB)。处于每个星形拓扑中央的是集线器,而在主机与集线器之间,集线器与集线器之间,集线器与设备之间都是点对点连接。1

各个设备在系统中的作用如下:

  • USB 主机 的主要作用包括: 提供电源,同时进行节电管理;检测设备,包括设备的接入与断开;管理数据传输,包括控制流和数据流;发送配置请求对 USB 设备进行配置操作;对总线上的错误进行管理和恢复等等。
  • USB 设备:在一个 USB 系统中,设备和集线器的总数不能超过 127 个。USB 设备接收 USB 总线上所有数据包,通过数据包的地址域来判断是不是发给自己的数据包:若地址不符,则简单地丢弃该数据包;若地址相符,则通过响应主机的数据包来和 USB 主机进行数据传输。
  • USB 集线器:集线器用于设备扩展连接,所有 USB 设备都连接在 USB 集线器的端口上。一个 USB 主机总与一个根集线器 (USB ROOT HUB)相连。USB 集线器为其每个端口提供 100mA 电流供设备使用。同时,USB 集线器可以通过端口的电气变化来判断出设备的插拔操作,并通过响应 USB 主机的数据包把端口状态汇报给主机。一般来说,USB 设备与USB 集线器间的连线长度不能超过 5米,USB 系统的级联不能超过5层(包括ROOT HUB)。

USB 功能
USB 是一种串行接口协议,它依靠 D+/D- 两条数据线构成的差分线来进行数据传输,这和我们熟悉两线 RS232/485 协议有何区别呢?了解这种区别有助于深入理解 USB 。所以首先让我们回想一下 RS232 的数据是如何传送的,如图1-2:

>>> 阅读全文

 

, ,

IRP 操作详解

每个操作系统都需要一个显性或隐性的 I/O 模型来处理进出外设的数据流。而 Windows I/O 模型的特性之一就是支持异步 I/O,其它一些特点包括:1

  • I/O 管理器为所有内核驱动提供了一致的接口,无论是底层驱动,中间层驱动或者文件系统驱动。所有请求都以 IRP (I/O 请求包)的形式发送给驱动。
  • I/O 操作是层叠的。I/O 管理器提供 I/O 系统服务供用户模式下子系统调用来执行 I/O 操作。I/O 管理器负责解释这些调用,并创建一个或多个 IRP,然后将它们路由给堆叠的驱动层层传递到物理设备。
  • I/O 管理器定义了一整套标准例程,其中一些要求驱动必须支持,另一些则是可选的。所有驱动遵循相对一致的实现模型,并根据不同的外设而有所差异,另外总线驱动、功能驱动、过滤驱动和文件系统驱动等也有不同的功能要求。
  • 正如 Windows 操作系统一样,驱动也是基于对象的。驱动、设备和物理硬件都被表示为对象。I/O 管理器和其他系统组件提供了内核态的支持例程,驱动通过例程调用来操作相关对象使得工作得以完成。

除了用来传递传统的 IO 请求外,I/O 管理器也可以和PnP 管理器、电源管理器一起发送包含 PnP 和电源请求的 IRP。

用户的 I/O 请求和文件对象
由于内核驱动被环境子系统所隐藏,因此用户是不可见的,这些子系统实现了一些大家熟悉的编程接口,比如 Windows 或 POSIX。对用户态代码(包括子系统)来说,可见的只是 I/O 管理器所控制的命名文件对象(named file object) 。

图1-1 显示了用户、子系统和 I/O 管理器的关系。

诸如 Win32 子系统这样的受保护子系统,将 I/O 请求通过 I/O 系统服务传递给相应的内核驱动。上图所示的子系统依赖于显示、显卡适配器、键盘和鼠标设备驱动的支持。

>>> 阅读全文

 

, ,

Windows LPC 通信机制剖析

LPC (Local procedure calls) 是 NT 内核实现一种基于消息的高速通信机制,可用于用户进程之间、用户进程与内核驱动之间或者内核驱动之间的通信。举个用户态进程间通信的例子,比如在创建登录会话时,CSRSS.exe 就通过 SmssWinStationApiPort 和 SMSS.exe 沟通,或者进程可以通过 LsaAuthenticationPort 就安全问题与 LSASS.exe 沟通。又比如在读写加密文件时, KSecDD.sys 会因为 EFS 秘钥的加密和解密与 LSASS.exe 通信, 这是用户进程与内核驱动通信的例子。1

LPC 采用两种不同机制以便在服务端与客户端之间传递数据:如数据长度小于 304 字节,则使用 LPC 消息缓冲;反之,数据长度超过 304 字节,则使用共享内存 (通过 NtCreateSection ),该内存段会同时映射到服务端和客户端的地址空间中。

除了当作远程过程调用(Remote Procedure Calls)的备选协议外,LPC 还被广泛运用到整个系统中,比如 Win32 应用与 CSRSS.EXE 间的通信,SRM 和 LSASS间的通信以及 WinLogon 与 LSASS 的通信等等。

LPC 强制在客户端与服务端间采用同步通信模型。从 Vista开始, LPC 开始被废弃转而采用称为异步本地进程间通信(ALPC)的新机制。 和 LPC 相比,ALPC 固有的优势是:从客户端到服务端的所有调用都是异步的,即客户端不需要阻塞或等待服务器对消息作出响应。从 Vista 之后,如果某些老应用调用了 LPC API,则会被自动重定向到新的 ALPC API。

LPC API
LPC API 是原生 API,换句话说 API 分别通过 NTDLL.dll 和 NTOSKRNL.exe 导出到用户模式和内核模式。LPC API 并未被导出到 Win32 层,因此 Win32 应用不能直接使用 LPC。不过如果进行 RPC 通信时使用 “ncalrpc” 协议序列(协议序列代表 RPC 通信使用的网络协议。2,就可以指定 LPC 作为下层传输协议,从而让 Win32 应用间接使用 LPC。

>>> 阅读全文

 

, , ,

受保护进程的演进 <1>: Windows 8.1 如何抵御哈希传递攻击

6年多前我第一次发文讨论受保护进程的概念—《为什么受保护进程糟糕透顶》1,该标题已经清楚透露了我对这个未经深思熟虑的 DRM 方案的看法。显然之后微软对其内部机制进行了长考(的确,抛开 DRM,一个难以渗透的用户态进程在安全领域也是个有趣的课题),又创造了一类新进程:Protected Process Light,内核中通常缩写为 PPL。

和其笨重的兄弟(受保护进程)不同,Protected Process Light 作为安全屏障,为 Windows 平台带来了三种可以有效抵御威胁的安全增强。在接下来的系列文章里2,我们将会看到这些安全增强是如何实现的,本文先从如何抵御哈希传递攻击(Pass-the-Hash)3开始。

我们将涉及 LSASS 4 在 Windows 安全模型中的作用,然后讨论新的 PPL 模型背后的技术细节。要涵盖新的安全改进,我们也不得不涉及一些内部相关领域,所以我们也会对安全启动和保护变量稍加讨论。不过最重要的是,我们还将了解如何启用设置来抵御 PtH ,因为对于非 RT 的 Windows,该功能默认是禁用的。

LSASS 进程
Windows 使用众所周知的算法(NTLM)对本地用户帐户进行哈希运算并将结果保存到称为 SAM (安全帐户管理器) 的数据库中,SAM 本身是注册表的一个配置单元文件。和其他操作系统一样,总是存在各种脱机或在线攻击,目的不外是为了获取、重置,甚至重用保存在 SAM 中的哈希值,例如常见的”密码重置”应急启动盘,或者是恶意的权级提升等等。此外,还有其它一些加密数据存储在 SECURITY 数据库(也称为 LSASS 策略数据库),这是另一个注册表配置单元文件。该数据包括密文(secrets,如 LSA 密文信息),保存的纯文本密码等等。

Windows 通过被称为本地安全权威子系统(LSASS Local Security Authority Sub-System)的进程管理着这些信息的运行时状态,并最终负责所有登录操作 (包括远程登录到 Active Directory)。因此,为了要获得对这些数据的访问,主要通过用两种机制:

>>> 阅读全文

 

,

Linux环境下的图形系统和AMD R600显卡编程(7)——AMD显卡的软件中断

CPU上处理的中断可以分成“硬件中断”和“软件中断”两类,比如网卡产生的中断称为硬件中断,而如果是软件使用诸如”int 0x10″(X86平台上)这样的指令产生中断称为软件中断,硬件中断是异步的,其发生的时机是不可知的,但是软件中断是同步的,CPU是“确切”知道其发生的时机的。

  同样的,在GPU看来,中断也可以分成“硬件中断”和“软件中断”两类,比如热插拔事件或者vblank事件都会产生“硬件中断”,这些事件在GPU看来是异步的,GPU不知道这些事情何时发生。GPU也可以使用类似CPU的int指令那样产生中断,考虑这样一种情形:驱动向硬件发送了绘图命令后必须等到硬件执行完了这些命令后才能进行后续的操作,否则硬件的上一次命令没有执行完就继续执行下一次命令会导致错误。前面介绍scratch寄存器的时候提及过可以在命令末尾添加一条写scratch寄存器的命令,发送命令之后驱动使用轮询的方式轮询scratch寄存器,当然这种场合使用轮询肯定是不合适的,实际上显卡可以采用软中断机制,在完成绘图命令后执行一个类似“int xx”的命令产生中断,这里GPU是“确切”知道中断发生的时机的—-即在绘图命令完成的时候。

  前面提到的fence就是这种“软件中断”的具体应用。

  在上一篇blog中看到,fence是按照下面的步骤使用的:

  radeon_fence_create->radeon_fence_emit->radeon_fence_wait

>>> 阅读全文

 

Linux环境下的图形系统和AMD R600显卡编程(5)——AMD显卡显命令处理机制

  通常通过读写设备寄存器对设备进行编程,在X86系统上,有专门的IO指令进行编程,在其他诸如MIPS、SPARC这类系统上,通过将设备的寄存器映射到内存地址空间直接使用读写内存的方式对设备进行编程。

  Radeon显卡提供两种方式对硬件进行编程,一种称为“推模式”(push mode)即直接写寄存器的方式,另一种称为拉模式,这篇blog讨论拉模式,这也是驱动中使用的模式。

  在拉模式下,驱动使用命令流(Command Stream)的形式进行对显卡编程:驱动程序将需要对显卡进行配置的一连串命令写入命令缓冲区,写完之后进入让出处理器,显卡按照命令写入的顺序执行这些命令,执行完成后触发中断通知驱动。CPU将这些命令放入一个称为命令环的环形缓冲区中,命令环是GTT内存中分出来的一片内存,驱动程序往命令环中填充命令,填充完后通知GPU命令已经写入命令,GPU的命令处理器CP(Command Processor)。上一篇博客即是通过ring环内存的使用来说明如何在系统中分配内存以及建立映射关系的。

  驱动写入的命令流由命令处理器CP进行解析,具体来说,CP完成以下工作:
•接收驱动程序的命令流。驱动程序将命令流先写入系统内存,然后由CP通过总线主设备访问方式进行获取,当前支持三种命令流,除了前面说的环形缓冲命令流,还有间接缓冲1命令流和间接缓冲2命令流;
•解析命令流,将解析后的数据传输给图形控制器的其他模块,包括3D图形处理器、2D图形处理器、视频处理器。

命令环缓冲区

>>> 阅读全文

 

Previous Posts