Session Memory in the Windows Kernel

Question

While reading the paper Effective Data-Race Detection for the Kernel by John Erickson and Madanlal Musuvathi. I was stuck on a slightly tricky sentence.

"Similarly, a range of kernel-address space, called session memory, is mapped to different address spaces based on the session the process belongs to. When a sampled access lies in the session memory space, DataCollider sets a data breakpoint but checks if the conflicting accesses belong to the same session before reporting the conflict to the user."

I can not figure out in practice what the session memory is at process level. Is the session related to the user owning the process? Or is it something more specific of the Kernel?

I know that I am probably missing something important but this is not basically my field of study so, although I tried, I couldn't find substantial answers. Is there someone who can explain me briefly what I am missing?

Cheers

Answer 1

I think that what is going on here is this.

In most operating systems, including Windows, there are lots of data structures inside the kernel that the kernel "shares" between all the processes running on the machine. In early versions of Win32 (starting maybe with Windows 95?) there are some kernel data structures, specifically those having to do with the graphics device interface (GDI)) that are shared by all the processes that are using the same desktop. In early versions of the OS there was only one desktop, so only one session, so these data structures were just shared like all the others. In the Server versions of Windows each remote login gets a "terminal" which, I think, is sort of a virtual desktop. So now they needed to "virtualize" those GDI data structures inside the kernel that weren't previously virtualized. I think that a "session" is that set of virtualized GDI datastructures. They are shared by all processes running on the same "terminal", and each "terminal" has its own version of the data structures.

The reason this matters in the DataCollider paper you referenced is that they are using data breakpoints, which are set on virtual addresses rather than physical addresses. But race detection (in the kernel) really makes more sense from the physical address perspective. For most kernel data structures there is a one-to-one mapping from virtual addresses to physical addresses. You set a data-breakpoint on a particular virtual address and when it "fires" you know that the physical address corresponding to that virtual address is still the same. All processes, from all users, from all "terminals" are really sharing those data structures, and if there is a race, there is a race.

The problem, for DataCollider is that in "session memory" this one-to-one mapping doesn't hold. In the case of session memory the virtual addresses are the same for every process, but the physical address that virtual address is mapped to is different when the kernel is working on behalf of processes from different terminals. So when the data breakpoint fires you need to do some extra bookkeeping to figure out whether the virtual address is pointing to the same physical address that you intended when you set the breakpoint.