Unique Process ID Mapping for Long-Term OS Tracking
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing operating systems face challenges in uniquely tracking processes over long periods due to the reuse of process IDs, which limits forensic analysis and security monitoring, especially in environments like eBPF where functionality is restricted.
Innovation Solution
The generation and maintenance of unique process IDs (UPIDs) that map to process IDs (PIDs), with UPID-to-PID mappings shared between kernel and user spaces, allowing for secure and efficient tracking of processes beyond their lifecycle, even in environments lacking full functionality.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If process IDs are reused after process termination, then the finite process ID pool is efficiently utilized, but the ability to uniquely track processes over long periods is compromised
Solution Approach 1:
The patent introduces a mapping table as an intermediary data structure that associates terminated process IDs with their original unique process identifiers (UPIDs). When a process terminates and its PID is reused, the mapping table stores the relationship between the reused PID and the original UPID, allowing the tracking system to resolve the correct process identity through this intermediary layer rather than relying on PID uniqueness alone.
Solution Approach 2:
The patent creates a copy of the process identification mechanism by maintaining both the original unique process identifier (UPID) and the system-assigned process ID (PID) in a mapping relationship. The UPID serves as a persistent copy that remains valid even after the PID is reused, enabling long-term tracking by referencing this copied identifier through the mapping table.
2Loss of information
If process tracking is implemented over long periods, then forensic analysis capability is improved, but the complexity of managing process identity uniqueness increases
Solution Approach 1:
The patent performs preliminary action by generating a unique process identifier (UPID) at process creation time and establishing its mapping to the system PID before the process terminates. This upfront preparation ensures that even after PID reuse, the original process identity is preserved in the mapping table, enabling forensic analysis without requiring complex real-time resolution mechanisms.
Solution Approach 2:
The patent replaces the mechanical assumption of PID uniqueness with a software-based mapping system. Instead of relying on the operating system's PID allocation mechanism to guarantee uniqueness, the solution substitutes a software mapping table that explicitly tracks PID-to-UPID relationships, transforming a system-level constraint into a software-managed data structure.
3Reliability
If unique process identifiers are generated for each process, then process tracking reliability is improved, but the system consumes more identifier resources
Solution Approach 1:
The patent extracts the uniqueness requirement from the system-assigned PID and places it in a separate UPID field. The PID can be reused according to operating system conventions, while the UPID is extracted and stored in the mapping table to maintain uniqueness. This separation allows the system to consume minimal additional resources (just the mapping table storage) while achieving reliable long-term process identification.
Data Source
AI summary
A unique process identifier (UPID) associated with a process identifier (PID) of a process executing in an operating system is generated in a kernel space of the operating system executing on a computing device. The UPID is inserted into a first mapping store that maps the PID to the UPID. A message is transmitted including the PID to a message buffer structure. A second mapping store that maps the UPID to the PID is updated in a user space of the operating system based on the message.