CS150 Components and Design Techniques for Digital Systems

http://www-inst.eecs.berkeley.edu/~cs150

Landauer's eraser

 In 1961 Landauer showed "that the erasure of one bit of information is necessarily accompanied by the release of at least kTln(2) of heat into the environment" this defines the theoretical minimum for energy consumed by a system with memory which is W = kT ln(2) for each bit of a state, where k is a Boltzmann constant and T is a system temperature. This principle helped to solve the paradox of Maxwell's Demon.

  The following articles are a good source of reference

 "The physics of forgetting: Landauer’s erasure principle and information theory" - http://www3.imperial.ac.uk/pls/portallive/docs/1/55905.PDF

Information: From Maxwell’s demon to Landauer’s eraser - http://scitation.aip.org/content/aip/magazine/physicstoday/article/68/9/10.1063/PT.3.2912

Unsafe use of FltGetFileNameInformationUnsafe

  FltGetFileNameInformationUnsafe name is spot on. It is very unsafe and dangerous function but not in the way mentioned in WDK. The documentation misses yet another dangerous case when it should not be used. This case is related to file system isolation filters( for more information on such filters follow this link https://www.osronline.com/article.cfm?article=560 ). I would state this additional condition as

  - A filter driver must not use FltGetFileNameInformationUnsafe for file objects it never observed. A filter observed a file object if it was called at least once with this file object for any operation and it never received IRP_MJ_CLOSE for this file object or observed a failed IRP_MJ_CREATE. This condition guaranties that a file object is initialized by a filter of file system driver that is beneath a filter calling FltGetFileNameInformationUnsafe . 

  When the above condition is violated by any file system filter a filter might call an underlying file system with a file object this file system never initialized as the file object was initialized by a file system filter that is above a filter that has called FltGetFileNameInformationUnsafe . At first glance it seems that in that case an upper filter must isolate the underlying filters from such file object. This is true, but there is a degenerate case when a filter can gain access to file objects that it should never see. This is a case of a process creation callback when a file object for executable file is provided as a parameter to a callback and this file object might have been initialized by a file system filter above one that registered this callback. Below is a call stack from the system where Microsoft Windows Defender file system minifilter used FltGetFileNameInformationUnsafe from a process creation callback to query a file name for a file object initialized by a file system filter attached to MiniFilter Manager ( aka fltmgr.sys ). 

Ntfs!NtfsCommonQueryInformation+0xa7

Ntfs!NtfsFsdDispatchSwitch+0xd3

Ntfs!NtfsFsdDispatchWait+0x47

nt!IovCallDriver+0x3cd

fltmgr!FltpQueryInformationFile+0x10e

fltmgr!QueryStandardLinkInformation+0x4d

fltmgr!FltpSetStreamListStandardInformationFlags+0x7a

fltmgr!FltpGetFileNameInformation+0x796

fltmgr!FltGetFileNameInformationUnsafe+0x71

WdFilter!MpGetImageNormalizedName+0x51

WdFilter!MpCreateProcessNotifyRoutineEx+0x77

nt!PspInsertThread+0x7a7

nt!NtCreateUserProcess+0x806

nt!KiSystemServiceCopyEnd+0x13

As a result NTFS crashed when it received an IRP with a file object initialized by a file system filter attached to the top of the drivers stack. The obvious solution is to use the old good ObQueryNameString as it has been done for the last 25 years by the kernel itself, for example in NtQueryVirtualMemory when processing a memory region supported by a mapped file. In that case an IRP is created and sent from the very top of a drivers stack so an isolation filter has a chance to intercept this IRP and complete it.

On interrupts handling by a kernel

This is an excerpt from Jonathan S. Shapiro's article "Design Note: Kernel Interrupt and Concurrency Management" 

With the exception of the interval timer interrupt and (on SMP systems) the interprocessor interrupt, Coyotos does not handle interrupts directly. Also, the kernel does not support interrupt nesting. Our working assumptions are:

• The longest kernel path is very short (units of microseconds).
• We can therefore defer doing anything about interrupts until we are just about to exit the kernel, when kernel state is not ``in flight.''
• Since we are going to defer interrupt handling to the scheduler, the kernel does not need to deal with nested interrupts.
• It is preferable, and not much unduly expensive, to prioritize interrupt handlers using the kernel scheduler rather than hardware priorities.
• If it were not for the need to deal with the interval timer interrupt and IPI issues, we could hypothetically run with interrupts entirely disabled in the kernel.

Ignoring the interval timer and the interprocessor interrupt, the primary action taken by the kernel in response to an interrupt is to wake up the relevant driver process by moving it from a per-interrupt stall queue to the ready queue. A preemption occurs only if the awakened process is higher priority than the currently executing process. On hardware platforms where a prompt hardware-level acknowledge is required to avoid interrupt controller lockup, the interrupt handler takes care of this as well.

Quantum Field Theory

On importance of FileObject->Vpb pointer

 An easily overlooked issue in FS(file systems) and FS filters development for Windows is Vpb pointer in FILE_OBJECT structure, i.e. Volume Parameters Block ( struct VPB ). It is responsibility of FS or FS filter ( in case of stacked FS, i.e. FSD-over-FSD ) to initialize this pointer to a correct value. It is especially important in case of FSD over FSD implementations as some underlying FSs check the VPB->ReferenceCount pointer on their PnP path and both upper FSD and lower FSD share the same VPB pointer. The kernel references Vpb in IopParseDevice routine that calls IRP_MJ_CREATE dispatch routine, but doesn't set Vpb pointer for FileObject sent with create Irp, and dereferences Vpb in IopDeleteFile just after IRP_MJ_CLOSE completes but IopDeleteFile fetches the pointer from FileObject->Vpb that is set by FS when processing IRP_MJ_CREATE. If FS or FS filter fails to set Vpb pointer PnP safe remove for some file systems would be impossible as Vpb->ReferenceCount never drops below a checked value.

 I encountered this problem when working on my own implementation for FSD-over-FSD FS filter. The problem manifested itself on FAT32 , NTFS was clean from this issue.

 Below are two call stacks for 32 bit Windows 8, the first is for a case when Vpb->ReferenceCount is bumped and the second for a case when it is decremented.


nt!IopCheckVpbMounted+0x81
nt!IopParseDevice+0x48b
nt!ObpLookupObjectName+0x6ef
nt!ObOpenObjectByName+0x1e3
nt!IopCreateFile+0x372
nt!NtCreateFile+0x78
nt!KiSystemServiceCopyEnd+0x13
ntdll!NtCreateFile+0xa


nt!IopDecrementVpbRefCount+0x5b
nt!IopDeleteFile+0xf5
nt!ObpRemoveObjectRoutine+0x64
nt!ObfDereferenceObjectWithTag+0x8f
nt!NtClose+0x210
nt!KiSystemServiceCopyEnd+0x13

How to check that a certificate is suitable for Mac OS X kernel extensions signing

   The certificate suitable for signing kernel extensions must contain the following extension ( 1.2.840.113635.100.6.1.18 ) . You can check this by opening certificate information in Keychain Access application.