'WDM/Architecture'에 해당되는 글 12건

  1. 2009.03.18 비스타 64bit에서 테스트 사인하기
  2. 2009.01.23 Managing Hardware Priorities
WDM/Architecture2009.03.18 14:14

비스타 64비트에서는 사인된 드라이버만 로드가 되는데요.. 이부분을 위해 해결해야 할것에 대해

 

말하겠습니다

 

x64버젼의 VISTA에서 정식 코드사인(드라이버사인)없이 드라이버를 로드하는 방법은

 

-         아예, 사인 여부 자체를 검사하지 않는 방법

-         정식 사인 외, Test사인을 허용하도록 하는 방법

 

두 가지 입니다. 본래는 정식 코드사인을 하지 않은 모듈은 로드가 거부됩니다.

 

- 드라이버 로드 방법 ---------------------------------------------------

 

1. 아예, 사인 여부 자체를 검사하지 않는 방법

 

-         cmd에서, 아래의 명령 실행

bcdedit -set loadoptions DDISABLE_INTEGRITY_CHECKS

 

<참고> 사인을 다시 검사하도록 하는 명령은, bcdedit -set loadoptions 아무런글자나

 

2. 정식 사인 외, Test사인을 허용하도록 하는 방법

 

-         cmd에서, 아래의 명령 실행

bcdedit /set TESTSIGNING ON

 

-         %DDK_PATH%\bin\SelfSign\makecert.exe -pe -ss PrivateCertStore -n CN=contoso.com(Test)

ContosoTest.cer

 

-         생성된 ContosoTest.cer 파일을 실행하여, <인증서 설치> 한다. (단순히, 다음 버튼만 누른다)

 

-         %DDK_PATH%\bin\SelfSign\certmgr.exe 실행하면, 인증서 관리창이 뜨며, 이곳에서 [다른사

] 시트에서 ContosoTest.cer 가 등록된 것을 확인할 수 있다.

 

-         아래의 명령을 통해 드라이버 사인을 할 수 있다.

%DDK_PATH%\bin\SelfSign\signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t

http://timestamp.verisign.com/scripts/timestamp.dll 사인할 드라이버의 풀패스네임

 

       < 참고 > %DDK_PATH% : DDK가 설치된 경로를 직접 적어주어야 한다.

 

 

-----------------------------------------------------------------------

< 참고 >

위의 작업은 대부분 관리자권한을 필요로 합니다. 예를 들어, 커맨드 창(cmd.exe)에서 작업하는 경우 cmd.exe

우 클릭하여 관리자 권한으로 실행을 통해 창을 띄워야 합니다. 하다 보면 상당히 번거롭기 때문에, 아래의 절차

통해 이를 피할 수 있습니다.

 

시작 > 프로그램 > 제어판 > 사용자 계정 및 가족 보호 > 사용자 계정 > 사용자 계정 컨트롤 사용/사용 안 함

에서 체크 해제 후, 적용 (재부팅 필요)

 

혹은,

 

시작 > 실행 > lusrmgr.msc 실행 > 사용자 > Administrator > 계정사용안함 체크 해제 후, 관리자로 로그인(

부팅 필요)

 

Posted by 쫑경
WDM/Architecture2009.01.23 11:42

The IRQL at which a driver routine executes determines which kernel-mode driver support routines it can call. For example, some driver support routines require that the caller be running at IRQL = DISPATCH_LEVEL. Others cannot be called safely if the caller is running at any IRQL higher than PASSIVE_LEVEL.

Following is a list of IRQLs at which the most commonly implemented standard driver routines are called. The IRQLs are listed from lowest to highest priority.

PASSIVE_LEVEL
Interrupts Masked Off — None.

Driver Routines Called at PASSIVE_LEVEL — DriverEntry, AddDevice, Reinitialize, Unload routines, most dispatch routines, driver-created threads, worker-thread callbacks.

APC_LEVEL
Interrupts Masked Off — APC_LEVEL interrupts are masked off.

Driver Routines Called at APC_LEVEL — Some dispatch routines (see Dispatch Routines and IRQLs).

DISPATCH_LEVEL
Interrupts Masked Off — DISPATCH_LEVEL and APC_LEVEL interrupts are masked off. Device, clock, and power failure interrupts can occur.

Driver Routines Called at DISPATCH_LEVEL — StartIo, AdapterControl, AdapterListControl, ControllerControl, IoTimer, Cancel (while holding the cancel spin lock), DpcForIsr, CustomTimerDpc, CustomDpc routines.

DIRQL
Interrupts Masked Off — All interrupts at IRQL<= DIRQL of driver's interrupt object. Device interrupts with a higher DIRQL value can occur, along with clock and power failure interrupts.

Driver Routines Called at DIRQL — InterruptService, SynchCritSection routines.

The only difference between APC_LEVEL and PASSIVE_LEVEL is that a process executing at APC_LEVEL cannot get APC interrupts. But both IRQLs imply a thread context and both imply that the code can be paged out.

Lowest-level drivers process IRPs while running at one of three IRQLs:

  • PASSIVE_LEVEL, with no interrupts masked off on the processor, in the driver's Dispatch routine(s)

    DriverEntry, AddDevice, Reinitialize, and Unload routines also are run at PASSIVE_LEVEL, as are any driver-created system threads.

  • DISPATCH_LEVEL, with DISPATCH_LEVEL and APC_LEVEL interrupts masked off on the processor, in the StartIo routine

    AdapterControl, AdapterListControl, ControllerControl, IoTimer, Cancel (while it holds the cancel spin lock), and CustomTimerDpc routines also are run at DISPATCH_LEVEL, as are DpcForIsr and CustomDpc routines.

  • Device IRQL (DIRQL), with all interrupts at less than or equal to the SynchronizeIrql of the driver's interrupt object(s) masked off on the processor, in the ISR and SynchCritSection routines

Most higher-level drivers process IRPs while running at either of two IRQLs:

  • PASSIVE_LEVEL, with no interrupts masked off on the processor, in the driver's dispatch routines

    DriverEntry, Reinitialize, AddDevice, and Unload routines also are run at PASSIVE_LEVEL, as are any driver-created system threads or worker-thread callback routines or file system drivers.

  • DISPATCH_LEVEL, with DISPATCH_LEVEL and APC_LEVEL interrupts masked off on the processor, in the driver's IoCompletion routine(s)

    IoTimer, Cancel, and CustomTimerDpc routines also are run at DISPATCH_LEVEL.

In some circumstances, intermediate and lowest-level drivers of mass-storage devices are called at IRQL APC_LEVEL. In particular, this can occur at a page fault for which a file system driver sends an IRP_MJ_READ request to lower drivers.

Most standard driver routines are run at an IRQL that allows them simply to call the appropriate support routines. For example, a device driver must call AllocateAdapterChannel while running at IRQL DISPATCH_LEVEL. Since most device drivers call these routines from a StartIo routine, usually they are running at DISPATCH_LEVEL already.

Note that a device driver that has no StartIo routine because it sets up and manages its own queues of IRPs is not necessarily running at DISPATCH_LEVEL IRQL when it should call AllocateAdapterChannel. Such a driver must nest its call to AllocateAdapterChannel between calls to KeRaiseIrql and KeLowerIrql so that it runs at the required IRQL when it calls AllocateAdapterChannel and restores the original IRQL when the calling routine regains control.

When calling driver support routines, be aware of the following.

  • Calling KeRaiseIrql with an input NewIrql value that is less than the current IRQL causes a fatal error. Calling KeLowerIrql except to restore the original IRQL (that is, after a call to KeRaiseIrql) also causes a fatal error.
  • While running at IRQL >= DISPATCH_LEVEL, calling KeWaitForSingleObject or KeWaitForMultipleObjects for kernel-defined dispatcher objects to wait for a nonzero interval causes a fatal error.
  • The only driver routines that can safely wait for events, semaphores, mutexes, or timers to be set to the signaled state are those that run in a nonarbitrary thread context at IRQL PASSIVE_LEVEL, such as driver-created threads, the DriverEntry and Reinitialize routines, or dispatch routines for inherently synchronous I/O operations (such as most device I/O control requests).
  • Even while running at IRQL PASSIVE_LEVEL, pageable driver code must not call KeSetEvent, KeReleaseSemaphore, or KeReleaseMutex with the input Wait parameter set to TRUE. Such a call can cause a fatal page fault.
  • Any routine that is running at greater than IRQL APC_LEVEL can neither allocate memory from paged pool nor access memory in paged pool safely. If a routine running at IRQL greater than APC_LEVEL causes a page fault, it is a fatal error.
  • A driver must be running at IRQL DISPATCH_LEVEL when it calls KeAcquireSpinLockAtDpcLevel and KeReleaseSpinLockFromDpcLevel.

    A driver can be running at IRQL <= DISPATCH_LEVEL when it calls KeAcquireSpinLock but it must release that spin lock by calling KeReleaseSpinLock. In other words, it is a programming error to release a spin lock acquired with KeAcquireSpinLock by calling KeReleaseSpinLockFromDpcLevel.

    A driver must not call KeAcquireSpinLockAtDpcLevel, KeReleaseSpinLockFromDpcLevel, KeAcquireSpinLock, or KeReleaseSpinLock while running at IRQL>DISPATCH_LEVEL.

  • Calling a support routine that uses a spin lock, such as an ExInterlockedXxx routine, raises IRQL on the current processor either to DISPATCH_LEVEL or to DIRQL if the caller is not already running at a raised IRQL.
  • Driver code that runs at IRQL > PASSIVE_LEVEL should execute as quickly as possible. The higher the IRQL at which a routine runs, the more important it is for good overall performance to tune that routine to execute as quickly as possible. For example, any driver that calls KeRaiseIrql should make the reciprocal call to KeLowerIrql as soon as it can.

Posted by 쫑경
TAG IRQL