Local Inter-Process Communication

Last updated

The Local Inter-Process Communication [1] (LPC, often also referred to as Local Procedure Call or Lightweight Procedure Call) is an internal, undocumented inter-process communication facility provided by the Microsoft Windows NT kernel for lightweight IPC between processes on the same computer. As of Windows Vista, LPC has been rewritten as Asynchronous Local Inter-Process Communication [1] (ALPC, often also Advanced Local Procedure Call) in order to provide a high-speed scalable communication mechanism required to efficiently implement User-Mode Driver Framework (UMDF), whose user-mode parts require an efficient communication channel with UMDF's components in the executive. [2]

Contents

The (A)LPC interface is part of Windows NT's undocumented Native API, and as such is not available to applications for direct use. However, it can be used indirectly in the following instances:

Implementation

(A)LPC is implemented using kernel "port" objects, which are securable (with ACLs, allowing e.g. only specific SIDs to use them) and allow identification of the process on the other side of the connection. Individual messages are also securable: applications can set per-message SIDs, and also test for changes of the security context in the token associated with the (A)LPC message.

The typical communication scenario between the server and the client is as follows:

  1. A server process first creates a named server connection port object, and waits for clients to connect.
  2. A client requests a connection to that named port by sending a connect message.
  3. If the server accepts the connection, two unnamed ports are created:
    • client communication port - used by client threads to communicate with a particular server
    • server communication port - used by the server to communicate with a particular client; one such port per client is created
  4. The client receives a handle to the client communication port, and server receives a handle to the server communication port, and the inter-process communication channel is established.

(A)LPC supports the following three modes of message exchange between the server and client: [3]

ALPC has a performance advantage over the former LPC interface, as it can be configured to use I/O completion ports instead of synchronous request/reply mechanism that LPC exclusively uses. [4] This enables ALPC ports high-speed communication which automatically balances the number of messages and threads. Additionally, ALPC messages can be batched together so as to minimize user-mode/kernel-mode switches.

Known usage

(A)LPC is used heavily in communication between internal subsystems in Windows NT. The Win32 subsystem uses (A)LPC heavily for communication between client and the subsystem server (CSRSS). Quick LPC was introduced in version 3.51 of Windows NT to make these calls faster. This method was largely abandoned in version 4.0 in favor of moving the performance critical server portions into kernel mode (win32k.sys).

The Local Security Authority Subsystem Service (LSASS), Session Manager (SMSS), and Service Control Manager all use (A)LPC ports directly to communicate with client processes. Winlogon and the Security Reference Monitor use it to communicate with the LSASS process.

As mentioned, Microsoft RPC can use (A)LPC as a transport when the client and server are both on the same machine. Many services that are designed to communicate only on the local computer use (A)LPC as the only transport through RPC. The implementation of remote OLE and DCOM in many cases uses (A)LPC for local communication as well.

See also

Notes

  1. 1 2 "LPC (Local procedure calls) Part 1 architecture". Microsoft Docs .
  2. Russinovich, Solomon & Ionescu (2009 :201)
  3. Russinovich, Solomon & Ionescu (2009 :203)
  4. Russinovich, Solomon & Ionescu (2009 :204)

Related Research Articles

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space, which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction, typically implemented via a request–response message-passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.

Inter-process communication How computer operating systems enable data sharing

In computer science, inter-process communication or interprocess communication (IPC) refers specifically to the mechanisms an operating system provides to allow the processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing.

Hardware abstractions are sets of routines in software that provide programs with access to hardware resources through programming interfaces. The programming interface allows all devices in a particular class C of hardware devices to be accessed through identical interfaces even though C may contain different subclasses of devices that each provide a different hardware interface.

Windows Console

Windows Console is the infrastructure for console applications in Microsoft Windows. An instance of a Windows Console has a screen buffer and an input buffer. It allows console apps to run inside a window or in hardware text mode. The user can switch between the two using the Alt+↵ Enter key combination. The text mode is unavailable in Windows Vista and later. Starting with Windows 10, however, a native full-screen mode is available.

Windows NT 3.1 32-bit cross-platform operating system developed by Microsoft

Windows NT 3.1 is the first major release of the Windows NT operating system developed by Microsoft, released on July 27, 1993.

Architecture of Windows NT Overview of the architecture of the Microsoft Windows NT line of operating systems

The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant multitasking operating system, which has been designed to work with uniprocessor and symmetrical multiprocessor (SMP)-based computers. To process input/output (I/O) requests, they use packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows XP, Microsoft began making 64-bit versions of Windows available; before this, there were only 32-bit versions of these operating systems.

Svchost.exe is a system process that can host from one or more Windows services in the Windows NT family of operating systems. Svchost is essential in the implementation of shared service processes, where a number of services can share a process in order to reduce resource consumption. Grouping multiple services into a single process conserves computing resources, and this consideration was of particular concern to NT designers because creating Windows processes takes more time and consumes more memory than in other operating systems, e.g. in the Unix family. However, if one of the services causes an unhandled exception, the entire process may crash. In addition, identifying component services can be more difficult for end users. Problems with various hosted services, particularly with Windows Update, get reported by users as involving svchost.

Mark Russinovich Spanish-born American software engineer

Mark Eugene Russinovich is a Spanish-born American software engineer who serves as CTO of Microsoft Azure. He was a cofounder of software producers Winternals before it was acquired by Microsoft in 2006.

The Windows NT booting process is the process by which Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003 operating systems initialize. In Windows Vista and later, this process has changed significantly; see Windows NT 6 startup process for information about what has changed.

The Native API is a lightweight application programming interface (API) used by Windows NT and user mode applications. This API is used in the early stages of Windows NT startup process, when other components and APIs are still unavailable. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API. The Native API is also used by subroutines such as those in kernel32.dll that implement the Windows API, the API based on which most of the Windows components are created.

A hybrid kernel is an operating system kernel architecture that attempts to combine aspects and benefits of microkernel and monolithic kernel architectures used in computer operating systems.

Kernel Transaction Manager (KTM) is a component of the Windows operating system kernel in Windows Vista and Windows Server 2008 that enables applications to use atomic transactions on resources by making them available as kernel objects.

Session Manager Subsystem, or smss.exe, is a component of the Microsoft Windows NT family of operating systems, starting in Windows NT 3.1. It is executed during the startup process of those operating systems, at which time it performs the following tasks:

The Microsoft Windows operating system supports a form of shared libraries known as "dynamic-link libraries", which are code libraries that can be used by multiple processes while only one copy is loaded into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.

Client Server Runtime Subsystem, or csrss.exe, is a component of the Windows NT family of operating systems that provides the user mode side of the Win32 subsystem and is included in Windows NT 3.1 and later. Because most of the Win32 subsystem operations have been moved to kernel mode drivers in Windows NT 4 and later, CSRSS is mainly responsible for Win32 console handling and GUI shutdown. It is critical to system operation; therefore, terminating this process will result in system failure. Under normal circumstances, CSRSS cannot be terminated with the taskkill command or with Windows Task Manager, although it is possible in Windows Vista if the Task Manager is run in Administrator mode. On Windows 7 and later, Task Manager will inform the user that terminating the process may result in system failure, and prompt if they want to continue. In Windows NT 4.0 however, terminating CSRSS without the Session Manager Subsystem (SMSS) watching will not crash the system. However in Windows XP, terminating CSRSS without SMSS watching will crash the system due to the critical bit being set in RAM for csrss.exe.

Object Manager (Windows)

Object Manager is a subsystem implemented as part of the Windows Executive which manages Windows resources. Resources, which are surfaced as logical objects, each reside in a namespace for categorization. Resources can be physical devices, files or folders on volumes, Registry entries or even running processes. All objects representing resources have an Object Type property and other metadata about the resource. Object Manager is a shared resource, and all subsystems that deal with the resources have to pass through the Object Manager.

Microsoft POSIX subsystem is one of four subsystems shipped with the first versions of Windows NT, the other three being the Win32 subsystem which provided the primary API for Windows NT, plus the OS/2 and security subsystems.

Windows NT is a proprietary graphical operating system produced by Microsoft, the first version of which was released on July 27, 1993. It is a processor-independent, multiprocessing and multi-user operating system.

In computing the Process Environment Block is a data structure in the Windows NT operating system family. It is an opaque data structure that is used by the operating system internally, most of whose fields are not intended for use by anything other than the operating system. Microsoft notes, in its MSDN Library documentation — which documents only a few of the fields — that the structure "may be altered in future versions of Windows". The PEB contains data structures that apply across a whole process, including global context, startup parameters, data structures for the program image loader, the program image base address, and synchronization objects used to provide mutual exclusion for process-wide data structures.

Service Control Manager (SCM) is a special system process under the Windows NT family of operating systems, which starts, stops and interacts with Windows service processes. It is located in the %SystemRoot%\System32\services.exe executable. Service processes interact with SCM through a well-defined API, and the same API is used internally by the interactive Windows service management tools such as the MMC snap-in Services.msc and the command-line Service Control utility sc.exe. Terminating this file is used as a method of causing the Blue Screen of Death.

References