Containing a Confused Deputy on x 86 : A Survey of Privilege Escalation Mitigation Techniques

The weak separation between userand kernelspace in modern operating systems facilitates several forms of privilege escalation. This paper provides a survey of protection techniques, both cutting-edge and time-tested, used to prevent common privilege escalation attacks. The techniques are compared against each other in terms of their effectiveness, their performance impact, the complexity of their implementation, and their impact on diversification techniques such as ASLR. Overall the literature provides a litany of disjoint techniques, each of which trades some performance cost for effectiveness against a particular isolated threat. No single technique was found to effectively mitigate all known and potential attack vectors with reasonable performance cost overhead. Keywords—Protection & Security; Virtualization; Kernel ROP; ret2usr; Kernel Code Implant; rootkits; Operating Systems; Privilege Escalation


I. INTRODUCTION
The modern operating system kernel is one of the most basic building blocks of any complex computing or control system.It exists to provide a controlled interface to the hardware and to protect multiple processes and users from each others' actions.In order to accomplish these tasks securely, it must operate with a higher privilege level than user processes, making it an attractive target for attackers.As security research steadily enhances the security of individual processes, the kernel is being attacked more regularly.Despite the recent increase in popularity of attacking the kernel, system designers have long recognized the need for kernel security.MULTICS [1], [2] was one of the first operating systems to take security seriously and laid the groundwork for the most popular kernel security mechanisms still used today.In particular, it defined operating system "rings", designated by processor modes, and memory segmentation and paging structures with flexible read, write, and/or execute permission bits to allow memory partitioning and protection.
Unfortunately, almost all modern operating systems share a common vulnerability: a "weak" separation between kerneland user-space.While the operating system provides a unique address space for each process in order to isolate processes from one-another, each address space must still allow access to kernel functionality.This is generally accomplished by sharing the address space of the kernel with each process.In contrast to the rare instances of "strong" separation between kerneland user-space (such as the 4G/4G split Linux patch [3], 32bit XNU [4], and certain systems using the hardware facilities provided by SPARC V9 hardware [5]), this weak separation protects the kernel from unauthorized access only with the mode of operation of the processor.A process that successfully manages to operate in supervisor mode has carte blanche access to all of the code and data of the kernel.
Often assisted by the weak separation of kernel-and userspace, all of the most popular kernels have been compromised by "rootkits" that give the attacker the highest level of privilege (i.e."root") [6]- [8].This survey is specifically interested in privilege escalation attacks that: • Hijack the facilities of the kernel to create a "confused deputy" that is acting on behalf of the attacker [9].This does not include attacks that are correctly exercising badly designed features of the kernel [10] or attacks that operate outside of the purview of the kernel [11].
• Persist even without a specific kernel-level bug or design flaw.Although most rootkits do require some kernel level bug (such as a buffer overflow) to be invoked, attacks that utilize a specific bug such as [12]- [14] are beyond the scope of this survey.Additionally, attacks such as [15] that are enabled by a specific kernel design flaw will not be considered.These cases typically have trivial solutions.
• Elevate local privilege to root rather than "horizontal" privilege escalation such as [16].
• Effect x86 Architectures.The focus of this article is on the x86 architecture because of its wide use in data centers and workstations [17].However, some techniques specific to ARM will be examined because they do make valuable and interesting contributions to the state of the art.
Kernel code implants are attacks in which the adversary manages to overwrite existing code with (or inject) arbitrary instructions into the kernel space, and then direct the kernel to execute those instructions.Well-known examples of this type of attack include exploitation of classic buffer-overflow vulnerabilities associated with system calls [23].If  Fig. 1: Return-to-User Privilege Escalation Attack manages to overflow a buffer on the kernel stack using some malformed arguments to a system call, it is possible to write shell-code onto the stack and overwrite a return-address so as to invoke the shell-code.This attack vector has largely been mitigated by techniques that mark the stack non-executable or provide canary code to detect overflows [24], [25] but it illustrates the core concept.
Kernel return-oriented programming (ROP) attacks defeat the use of a non-executable stack by using a payload, not of code directly on the stack, but of carefully crafted stackframes that direct computation through a series of gadgets found in normal kernel code [19]- [21].Research has shown that even small programs are likely to contain the gadgets necessary to generate a ROP Turing machine controlled only by a carefully crafted payload delivered to the stack [26].All operating systems are large and complex enough to guarantee that the necessary gadgets will be present.As a result, an attacker with the appropriate knowledge can perform arbitrary computation using a ROP payload.
A return-to-user attack is enabled directly by weak kerneland user-space separation.In this attack, illustrated in Figure 1, a user-controlled target associated with some kernel-code branch is set to an address in the normal user-space code.The compromised branch creates a path of execution that leaves kernel-code, entering user-code, without changing the CPU privilege level from supervisor mode to user mode.This attack results in the execution of user-controlled code with kernellevel privileges.Although hardware extensions such as Intel's SMEP [27] aim to mitigate this threat, these extensions are only slowly being adopted by operating systems and SMEP bypass techniques have already been demonstrated [28], [29].
Unfortunately, mitigation techniques for privilege escala-tion do not operate in isolation and it is important that they do not undermine other security features.For instance, it is easy to inadvertently inhibit techniques for enhancing security using non-determinism.This general class of technique was initially described by Cohen [30] and Forrest [31].In the years since these seminal papers, many have explored the idea further.A recent survey of the area was presented in [32].Address Space Layout Randomization (ASLR) is one of the most widely used applications of this technique.First implemented by the Linux PaX team [33], many other operating systems have implemented some form of ASLR including Mac OS X [34], Windows [35], and others.ASLR loads distinct memory regions including main program code, libraries, and the stack and heap at random locations within a program's virtual address space making it difficult to predict code entry points.More fine-grained techniques for diversifying the memory layout of a process [36], [37] require even more flexibility than traditional ASLR.In Summary, this paper surveys the primary technologies presented in the literature to mitigate privilege escalation.It provides a comparative analysis based on their effectiveness, performance impact, and implementation complexity.It also specifically considers whether the technologies provide sufficient flexibility to coexist with state of the art address space layout randomization techniques.ASLR is chosen to provide a window to whether the techniques presented "play nicely" with other kernel security efforts because it is has widespread application on real systems and requires flexibility in order to be implemented fully.Section II examines techniques based on hypervisors and virtualization while the remaining techniques are discussed in section III.These techniques are compared and contrasted in section IV.Finally, some proposals are more accurately described as architectures than techniques.These are not directly comparable to the primary methods because they involve a dramatic paradigm shift.These approaches are briefly reviewed in Section V.

II. MITIGATION TECHNIQUES BASED ON VIRTUALIZATION
Virtualization has dramatically changed the face of computing, not simply in terms of security and the way individual users interact with computers, but also by enabling cloud computing by allowing virtual machines to be migrated between servers.By adding a layer to the standard software stack, known as a hypervisor [38] or Virtual Machine Monitor (VMM) [39], an abstraction layer is introduced to isolate the operating system kernel from the hardware.In many ways, the hypervisor is to an operating system what an operating system is to a user process -serving to protect virtual machines from each other just as a kernel isolates user processes.The following approaches use virtualization as a means to deliver security guarantees to the kernel.

A. NICKLE
NICKLE [40] provides memory integrity to kernel code and thereby denies the execution of kernel code implants.It uses a VMM to maintain a "shadow" copy of memory that is verified when any kernel-code is loaded.This is achieved by comparing the memory to be loaded against a pre-computed cryptographic hash of the "clean" code distributed by the manufacturer or developer of the code.At boot time, a known clean copy of the kernel is loaded into the shadow memory and whenever a kernel module is loaded at runtime, it is verified and added to the shadow memory.
With the integrity of the shadow memory guaranteed by off-line a priori cryptographic hashes of trusted code, NICKLE can ensure that no unauthorized kernel code is executed by directing all memory accesses targeting kernel code to retrieve from the shadow memory rather than from regular memory.Although no attempt is made to deny an attacker from modifying or injecting kernel code, kernel-mode execution is contained within trusted memory.This is achieved transparently to the operating system kernel, allowing for commodity operating systems to be executed with NICKLE with no modification of kernel code.Additionally, NICKLE permits the mixing of kernel code and data within memory pages; this distinguishes NICKLE from many alternative approaches that require code and data to be loaded onto unique pages.
Unfortunately, NICKLE requires the off-line computation of cryptographic hashes for any code that may be executed; this poses a significant logistical issue for maintaining NICKLE on real systems and adds additional vulnerabilities associated with protection and distribution of hash values.NICKLE imposes a "minimal to moderate impact on system performance, relative to that of the respective original VMMs" averaging 1%-5% [40].

B. SecVisor
SecVisor [41] is an alternative virtualization technology leveraging hardware facilities to virtualize physical memory associated with modern processors.By utilizing this additional layer of translation from "guest physical" to "real physical" memory addresses, additional hardware memory protections can be enforced.This capability typically provides additional flexibility in creating memory access security; namely, any combination of read, write, and execute permissions can be allowed or denied on a particular page of memory [42].
SecVisor uses physical memory virtualization to mark only one of kernel-and user-space executable at a time.When a violation of security rules is detected, the protections can be swapped if the CPU has indeed changed privilege level, but are otherwise denied.This defeats ret2usr attacks by preventing unauthorized processor mode switches as shown in Figure 2. Additionally, the same virtualization allows SecVisor to enforce standard W⊕X rules on all kernel code pages that the user has approved.This mitigates the possibility of a kernel code implant by verifying that all executable kernel code is non-writable and has been approved for execution by the user.
The security benefits of SecVisor are packaged in a tiny VMM that provides a small attack surface: only 4092 lines of source code in total.Unfortunately, SecVisor does have several weaknesses.The kernel running on top of SecVisor must guarantee that it does not share code and data on a single page.Additionally, the kernel has to be modified to cooperate with SecVisor by issuing VMCALLs to designate that it is loading or unloading kernel code.Finally, it imposes an overhead as high as 97% due to the additional translation  required by the virtualization of physical memory.For a full discussion of performance overhead costs, the interested reader should consult [41].
It is worth noting that [43] discovered two different bugs in the SecVisor implementation that allowed an attacker to violate rules that SecVisor claimed to enforce.Although these were implementation rather than design issues, and easily remedied, it is clear that even in a small code base security properties are difficult to reason about and correctly enforce.

C. SVA
The Secure Virtual Architecture (SVA) [44] is a set of architecture independent instructions that allow an operating system to interact with hardware.A kernel is ported to use these instructions, similar to porting a kernel to any new hardware architecture.Offline, an SVA compiler produces SVA byte-code from the kernel source code.This compiler has advanced features to provide memory safety and controlflow integrity at compile-time, similar to "safe" programming languages such as Java.The byte-code is distributed to users and executed on top of a virtualized SVA interpreter that performs the final step of translating to native target-dependent machine code.
The effort required to port an operating system to execute on SVA and the large performance cost are balanced by a promise of a substantial increase in security.Guaranteed memory safety and control-flow integrity deny common methods used to initiate ret2usr, kernel ROP, and kernel code implant attacks.An important point is that SVA does not set out to deny these attacks explicitly.Instead, it attempts to deny the vulnerabilities that enable these forms of attack, such as buffer overflows.Unfortunately, the infrastructure needed to support www.ijacsa.thesai.orgSVA presents a significant hurdle.In addition to porting a kernel to a new architecture, SVA imposes restrictions on the kernel's memory allocation mechanisms that are likely to require modifications in kernel subsystems such as kmalloc.The performance cost is high, measured at approximately 50% on average, but at times reaching a 4-fold reduction.

D. KCoFI
Kernel Control Flow Integrity (KCoFI) [45] leverages the mechanics of the SVA implementation discussed previously, but offers only control flow integrity.Specifically, KCoFI ensures that function calls always enter at the beginning of some function's code, and that all returns from a particular function target the location of a possible call site.In order to prevent user-space applications from imitating the labels that KCoFI uses to validate branches, allowable address transitions are restricted to those within a certain pre-defined "kernel" range of virtual addresses.This limits the capabilities of advanced load-time randomization schemes.KCoFI also provides advanced treatment for the issues that make control flow integrity particularly difficult in the context of operating systems.In particular, it takes special care to handle interrupts, signals, DMA/devices, incomplete branch target information at compile-time, and page faults.
By verifying all branches at run-time, while the processor is in kernel mode, KCoFI manages to deny each of the three primary privilege escalation techniques described in this survey.Unfortunately, as with SVA, there is a large performance cost.Although the average performance impact on a standard application was 13%, worst-case costs up to 3.5fold were reported.In addition, the method shares the SVA framework and therefore also requires porting the OS to a new "architecture," and pre-compiling the kernel and all of its modules with specialized SVA compilers.

E. SBCFI
State-based control-flow integrity (SBCFI) [46] provides course grained control-flow integrity for the operating system kernel.It sets itself apart from traditional control-flow integrity solutions, such as [47], in two ways.First, it implements monitoring externally from the kernel, in a hypervisor.Additionally, it assumes that attackers will generate persistent control-flow violations, therefore necessitating that kernel state is checked only periodically.Consequently, its introspection techniques allow SBCFI to detect any attack that persistently modifies the kernel's known control-flow graph.
The authors of [46] argue that trading strict security rules for performance by using SBCFI instead of complete CFI is acceptable because SBCFI will still detect most rootkits.In particular, they examined 25 rootkits found "in the wild" on Linux and found that all but one were detected by SBCFI.They suggest that attacker goals such as packet-sniffing or keystroke logging demand persistent rather than transient control-flow changes.
Unfortunately, SBCFI focuses on detection rather than prevention.This, combined with the focus on only persistent control-flow changes, leaves many avenues open to the attacker.SBCFI verifies the state of the kernel by checking a pre-computed hash of the kernel code and checking all function  pointers stored in the kernel heap to verify that nothing has been changed.These checks would not detect a process that has achieved escalated privilege via a ret2usr attack or a kernel ROP payload.Overall, SBCFI manages to effectively deny persistent modifications to the kernel control-flow graph with minimal performance costs of less than 1% on average.However, it fails to address the general threat associated with privilege escalation.

III. OTHER TECHNIQUES
A. kGuard kGuard [22] aims to deny ret2usr attacks by inserting guards on the kernel's control-flow at compile time as shown in Figure 3. On the x86 platform, the call, jmp, and ret instructions all redirect control-flow and therefore are vulnerable to being hijacked in order to redirect kernel execution into user-controlled code.kGuard places an inline check before any of these instructions.The checks are provided in two different forms depending on whether the target address is stored in a register or in memory.The checks simply verify that the branch target lies within kernel-space.Unfortunately, if an attacker controls the target of two branches, he can direct the first to jump directly to the second branch, bypassing the kGuard check completely.Since the second branch is in kernelspace, the check on the first branch would allow the control transfer.To avoid this attack, kGuard includes a compile-time code diversification mechanism that makes it difficult for the attacker to locate the address of the second branch.
One of the most significant advantages of kGuard is that, as a purely compile-time technique, it is portable to any operating system on any target hardware.It does not require any special hardware or impose many restrictions on the implementation of kernel features.Additionally, its average performance cost (IJACSA) International Journal of Advanced Computer Science and Applications, www.ijacsa.thesai.org is low at approximately 1%, making it deployable on existing systems.Unfortunately, kGuard does suffer from a variety of weaknesses.Although its simplicity lends itself to easy deployment, it is unable to protect against kernel-code implants or kernel-ROP.Although these are outside of the scope of kGuard, a kernel code implant could be used to create a ret2usr attack by implanting an unguarded jump into a user-space region.Therefore, another technique must be used in combination with kGuard to deny the possibility of a ret2usr scenario.This quickly increases in complexity and performance cost as multiple techniques need to be deployed on the same system.Additionally, kGuard's inline checks verify that the target of a control-flow transfer lies in kernel-space only by checking that it falls within a predefined range.This limits the capacity for deploying advanced code randomization during the loading of the kernel.

B. Return-less Kernels
Recall that Kernel ROP attacks requires "return" instructions in order to move from one gadget to another.In [48] the author utilizes "return indirection," introducing additional jumps at compile-time to disrupt this mechanism and defeat kernel ROP attacks.This approach uses a pre-computed table of all legal return addresses.Rather than pulling a return address from the stack and jumping to it at the end of a function, this method reads an address from the specified index in the return address table.If this table is trusted, the attacker could only modify which legal return address is used.It is assumed that most gadgets begin in a location other than a legal return address, and as a result this technique defeats the possibility of an attacker to craft a malicious payload.
In addition to introducing return indirection, [48] introduces compiler modifications to avoid instructions with an embedded "return" opcode.On an architecture such as x86, variable length instructions make it possible to read different instructions if the instruction pointer is offset some distance into an opcode.Without taking care at compile-time to avoid these scenarios, an attacker could still create gadgets by indexing the instruction pointer at unintended positions in the middle of the intended instruction.
The idea of using a return-less kernel is a clearly beneficial.It effectively mitigates a very particular risk with reasonable overhead, assessed at approximately 6%.Unfortunately, it does require modification to the kernel source.Functionality provided by compiling a higher-level language, such as C, does not need to be modified, but any functionality defined in assembly language must be manually modified to follow return-less principles.Since the kernel interfaces with hardware directly, there is a non-trivial level of assembly code included in most kernel implementations.

C. PaX
One of the first kernel-hardening efforts was implemented on Linux by the PaX team [49] circa 2000.UDEREF [50] utilizes segmentation to create a stricter separation between kernel-and user-space (denying ret2usr), while the PAGEXEC and Restricted mprotect() features essentially generate and enforce typical W⊕X security rules on kernel code and data to mitigate kernel code implants.
PaX is valuable as a case study in hardening kernels.Unfortunately, it is less valuable as a mechanism for protecting modern kernels on today's hardware.Its protection mechanisms were based on Linux-specific software mechanisms (such as mprotect()) and x86-32-specific hardware features (such as segmentation).Additionally, the performance cost was significant, according to [22].PaX-reported data about performance cost was available at the time of writing.

D. Sprobes and TZ-RKP
Sprobes [51] and TZ-RKP [52] both utilize the ARM TrustZone [53] hardware facilities included in modern ARM processors.TrustZone is a hardware-protected context that can run tangentially to the regular operation of the processor.The hardware disables the normal processor context from accessing anything within the "secure world" created by TrustZone and transitions between the regular context and TrustZone's secure context are limited by hardware to a small well-specified interface.
Sprobes [51] utilizes TrustZone by installing an introspection handler in the secure world and installing, at load-or run-time, special instructions that invoke the secure world at predetermined points in the execution of the kernel.When one of these probes is executed, control transfers to the secure world in which kernel state can be interrogated, control flow or memory contents verified, or any other number of actions can be taken.Furthermore, restrictions are placed on the normal world's ability to manipulate the virtual memory settings of the processor.The requirement that these systems be updated by the secure world guarantees that a kernel cannot manipulate virtual memory in order to bypass the probes.
TrustZone-based Real-time Kernel Protection (TZ-RKP) [52] is a similar approach that forces vital control operations involving the virtual memory layer to be routed through the secure world.TZ-RKP forgoes the probes provided by Sprobes, but takes a more extreme approach by limiting the kernel's control over important system state such as virtual memory.TZ-RKP forces all attempts to control virtual memory and other hardware resources through the secure world, providing a mechanism to verify any changes to the system state.With a controlled and static system state, it is easier to make claims about what an attacker may do to manipulate the kernel state.
Both [52] and [51] are built on the TrustZone architecture.The hardware underlying their implementation allows each to be implemented with a reasonable performance cost (typically 10%).TrustZone is also attractive because it manages to avoid the "turtles all the way down" problem in which software layer x is protected by introducing software layer x − 1, which simply becomes the new target for attackers and instantiates the same problem again.Traditional virtualization can be criticized for this problem, but TrustZone holds itself off to the side of layer x rather than existing underneath it.
• Typical/Maximum Performance Cost: What is the typical and worst-case reported performance costs?
The performance costs listed represent only the maximum performance cost and an estimated average used only to illustrate differences between the techniques.In some cases these come from micro-benchmarks corresponding to small code segments, in other cases they come from macro-benchmarks corresponding to full applications.For the estimated average, they are often a mix of these tests.Each of the techniques offers thorough performance cost analyses that could not be summarized in a simple table.Interested readers should consult the original paper for each technique for a more complete treatment.
Table II compares  • Memory and/or Control Flow Integrity: Which is the primary mechanism by which the tool delivers its security guarantees?
• Code-Diversity Compatible: Is the technique sufficiently flexible to allow for advanced fine-grained address space layout randomization techniques?
• Code Size: How many lines of code (LoC), as a measure of the attack surface presented, are used in the implementation of the technique as presented?
It is clear from Table I that while KCoFI and SVA offer the most protection against the three different techniques associated with privilege escalation, they also come with dramatically more performance overhead than the other methods.This conforms to expectations in that the more thorough the security  [45] CF 5579 SVA [44] M & CF No Data SecVisor [41] M 4092 SBCFI [46] CF No Data kGuard [22] CF 1000 PaX [49], [50] M & CF No Data Return-less Kernel [48] CF 2100 Sprobes [51] M & CF No Data TZ-RKP [52] M No Data measure, the higher its performance impact.Sprobes and TZ-RKP appear exceptional as they enjoy the lowest performance costs and strong security claims.Unfortunately, each utilizes the ARM TrustZone architecture and consequently are unavailable on the Intel x86 architecture.Additionally, vulnerabilities have already been discovered in some TrustZone hardware implementations [54].

V. PARADIGM-SHIFT TECHNIQUES
The techniques compared in Tables I and II each provide a modification to some part of the conventional kernel design, implementation, or build process that mitigates a particular threat.There are a few approaches, however, that attempt to offer similar security benefits by redefining the security paradigm rather than simply patching the status quo best practices.This radical departure from the current state of the art means that they cannot easily be compared to the previously described techniques.In all cases, it also means that they have not yet been widely accepted.

A. Microkernels
The idea of a microkernel departs from the standard "monolithic" kernel architecture by emphasizing a small codebase for the operating system kernel.There have been several examples of microkernels presented in the literature such as Mach [55], Minix [56], L4 [57], QNX [58], Bear [59], and many others.
All microkernels aim to minimize the source code in order to decrease the likelihood of vulnerabilities [60].Additionally, a small code base allows for the possibility of using formal analysis and formal verification techniques [61], [62].In order to keep the microkernel small, core functionality such as device drivers are migrated into user level processes.Additionally, many microkernels use message-passing for all communication between two processes or a process and the kernel.This provides a more easily verified and secured narrow interface between components.
By exporting core functionality, such as device drivers, into user-space microkernels struggle to offer the same levels of performance as monolithic kernels.Consequently, they have yet to replace monolithic kernels in common applications on commodity hardware.www.ijacsa.thesai.org

B. ExoKernel
The ExoKernel [63] suggests redefining the nature of the kernel entirely.Rather than providing abstractions that the application developer can use to access hardware, the ExoKernel provides only the thinnest possible layer to manage the multiplexing of hardware resources.Therefore, the ExoKernel circumvents tasks normally reserved for the kernel such as buffering network communications, interrupt or exception handling, virtual memory management, and other normal kernel functions.Instead, each individual application must define its own abstractions to handle these tasks.
Although likely to offer more security for a system overall, the ExoKernel appears significantly complicate application development.Many of the tasks that a secure kernel can provide to protect all processes, such as virtual memory management, become the responsibility of the application developer.This is likely to make individual applications less secure since application programmers may lack the technical sophistication to interact directly with hardware, interrupts, atomicity, and concurrency.These central parts of the operating system exist to provide applications with well-defined interfaces to this complex functionality.The ExoKernel eliminates those interfaces by design.

C. Unikernels
Unikernels trade flexibility for security and performance by running a single process within a single address space [64].Eliminating the requirement to support multiple processes and/or multiple users simplifies the code base required to implement a unikernel and reduces the overhead required to complete a single unit of useful work.Several examples have been deployed alongside virtualization technologies in cloud applications [65]- [67].Despite their proven usefulness for providing fast, highly focused applications, unikernels don't, in isolation, provide protection from most of the attack vectors discussed in this paper.Additionally, in order to support the multiple-user multiple-job paradigm that conventional applications to operate they require a hypervisor for scheduling and other process-management type tasks.In a sense, this is simply asking the hypervisor to act as an operating system and the same issues with conventional operating system design will simply move one layer deeper in the software stack.

VI. CONCLUSION
Each of the techniques examined in this survey makes valuable contributions to the security of modern operating systems.Those that offer the most comprehensive security suffer from high performance costs or specialty hardware requirements.On the other hand, many mitigate a specific, focused risk to kernel security while suffering only a small performance cost.Unfortunately, there is no single solution that offers both acceptable performance and comprehensive security coverage on the popular x86 platform.The impact of combining the techniques to improve coverage is not well understood in terms of complexity, performance, or security.This survey has also examined techniques that, rather than presenting incremental improvements on the status quo, attempt to dramatically redefine the notion of an operating system.These techniques also suffer from nontrivial performance costs in addition to the logistical challenges associated with a paradigm shift.
Overall, the kernel developer has a wide variety of techniques to choose from, but must balance individual strengths in privilege escalation prevention with the associated penalties in performance and complexity.The authors believe that future work aimed at mitigating privilege escalation will continue to have performance issues without some change in the underlying hardware or kernel design paradigms.Modern commodity operating systems are so highly developed that there is unlikely to be some technique hiding in a dark corner that will not decreasing perforance by requiring extra work.

NOTICE
The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon.The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Defense Advanced Research Projects Agency (DARPA) or the U.S. Government.This material is based on research sponsored by DARPA under agreement number: FA8750-11-2-0257.www.ijacsa.thesai.org

Fig. 3 :
Fig. 3: kGuard's Protection Against ret2usr Attacks the techniques on the basis of general observations regarding their operation: • x86-64 compatible: Most desktop and server-class systems use the 64-bit x86 architecture.Is the technique viable with the hardware provided by the x86-64 hardware?
an attacker (IJACSA) International Journal of Advanced Computer Science and Applications,

TABLE I :
Summary of Examined Attack Mitigation Methods

TABLE II :
Further Characteristics of Examined Methods