https://github.com/chip-red-pill/udbgInstr/raw/main/paper/undocumented_x86_i... https://www.youtube.com/watch?v=_eSAF_qT_FY God Mode https://www.youtube.com/watch?v=LA_DrBwkiJA Lern about puters and proggies https://www.youtube.com/watch?v=KrksBdWcZgQ Crunch Mode https://drwho.virtadpt.net/files/mov.pdf http://www.bitsavers.org/pdf/dec/vax/780/fiche/EP-ES0AA-DL-124_1of6_780uCode... ABSTRACT At the beginning of 2020, we discovered the Red Unlock technique that allows extracting microcode (ucode) and targeting Intel Atom CPUs. Using the technique we were able to research the internal structure of the microcode and then x86 instructions implementation. We found two undocumented x86 instructions which are intendent to control the microarhitecture for debug purposes. In this paper we are going to introduce these instructions and explain the conditions under which they can be used on public-available platforms. We believe, this is a unique opportunity for third-party researchers to better understand the x86 architecture. 1 Introduction The existence of undocumented mechanisms in the internals of modern CPUs has always been a concern for information security researchers and ordinary users. Assuming that such mechanisms do exist, the main worry is that it might be possible to bypass the implemented CPU protection mechanisms that control access to memory and peripherals containing personal user data. It is considered to be unacceptable for a processor manufacturer or any other organization to be able to get unauthorized access to data that the user regards as confidential by bypassing documented, well-known protection mechanisms and using methods that only the manufacturer knows about (whether those methods are based on the processor functionality or are intentionally designed for such purposes, or have a legitimate purpose but also allow bypassing protection due to certain architectural properties). Such mechanisms include the following: 1. Special CPU operating modes in which standard access control rules do not work or work differently compared to what is described in the documentation (for Intel CPUs, it is the Software Developer's Manual [1], which is intended for developers of applications running on Intel processors). 2. Special CPU microarchitectural states in which certain access control rules can be violated (for example, such states can be achieved by performing a specific instruction sequence). 3. Undocumented CPU instructions that allow bypassing protection mechanisms (for example, memory protec- tion) and grant special privileges to the calling code. The existence of such undocumented capabilities in Intel processors has always been a subject for debates and speculations among information security specialists. For more than 40 years of the existence of the x86 architecture, a number of significant studies have been conducted on this subject [2],[3],[4]. Several undocumented features have been discovered (e.g. undocumented instructions described in [3]), including one that allows bypassing implemented protection [5], but this was found for very old Intel processors (80286 and 80386). Thereafter no apparent undocumented methods to gain unauthorized access have been found in x86 processors manufactured directly by Intel. This is leaving aside multiple recently discovered transient execution vulnerabilities and data leaks caused by side-channel attacks (such as Meltdown and Spectre), which are by no means intentional and are generally admitted to be design errors due to prioritizing higher performance over security. However, our research team managed to find at least two undocumented x86 instructions and a special processor debugging mode called Red Unlock (detailed information about the mode is given in a separate section of this paper) in actual Intel CPUs. Combined, these capabilities make it possible to completely bypass the existing memory protection and equipment control mechanisms. Moreover, the discovered instructions provide access to the processor at the microcode level and thus allow overriding the semantics of the main x86 instructions (that is, a set of the most important instructions in terms of security). This is by far more dangerous than, for example, violating memory protection (x86 privilege levels, or so-called protection rings) because it enables malware to be implemented at a level where it is impossible to detect it with modern protection tools and defend the system against it. We should clarify in advance that, in our opinion, these instructions were initially introduced to facilitate the debugging of processors at the microarchitecture (hardware implementation) level exclusively by Intel engineers. However, due to a total absence of available documentation on these features (including description of all the possible ways to use them), we believe that these instructions are rather dangerous and that the Red Unlock service mode intended for processor debugging must not be implemented in production parts distributed by sales outlets and utilized by end users in their everyday tasks. In our view, Intel was obliged to at least inform users about the existence of these instructions and special CPU debugging mode so that users could be aware of the risks associated with the company's products. Moreover, on some platforms it is possible to enable this CPU debugging mode using hardware means that can be accessed by the Intel Converged Security and Management Engine (Intel CSME) [6]. A number of critical arbitrary code execution vulnerabilities [7], [8] recently discovered in the Intel CSME subsystem can be exploited to switch the CPU to the debugging mode, as was demonstrated by our company's experts [9]. This makes the Red Unlock mode available for virtually anyone who wishes to use it (rather than to Intel engineers only, as it was originally intended). ... 7 Conclusion As described in this paper, we discovered two undocumented x86 instructions that allow reading and writing microarchi- tectural data and called them udbgrd and udbgwr, respectively. One of the commands supported for the instructions is the CRBUS read/write command, which can be used to modify microcode in MSROM via Patch RAM and match/patch registers. We can prove the existence of these undocumented instructions in Atom Goldmont and Atom Goldmont Plus processors - see our PoC published together with the paper [14]. We found that the instructions must be activated through MSR 0x1e6 and that the processor executes them only after performing the DFX unlock procedure called Red Unlock. In our opinion, the instructions are intended for CPU microarchitecture debugging by Intel engineers; however, the existence of such instructions poses a security threat since there is publicly available PoC code [9] that can activate the Red Unlock mode on one of the modern Intel platforms. Moreover, we demonstrated that speculative execution of microoperations (rather than macroinstructions that they implement) is possible for udbgrd/udbgwr, which needs to be thoroughly examined with regard to all present-day Intel processors. For this purpose, we created a special tool [22] that, when run on a processor, checks whether the udbgrd and udbgwr instructions can be executed on it and, if not, checks whether the processor allows speculative writing and reading of microarchitectural data when calling the instructions. This tool executes the udbgwr instruction to write a specific URAM address (Time Stamp Counter (TSC) multiplier used by the rdtsc x86 instruction), which is known for Big Cores as well as for Atom Goldmont, and then attempts to read the written data using architectural mechanisms available in User Mode. The tool also tries to speculatively read the TSC multiplier in URAM with the udbgrd instruction by using CPU cache as a mechanism to retrieve the read data. On top of that, we were the first to publicly provide a list of all (as far as we can tell) possible ways to activate the Red Unlock mode for CPU debugging and to demonstrate that some of them are rather dangerous (for example, software-based unlocking via Intel CSME and PUNIT firmware and processor-specific OTP configuration).