One important yet sometimes overlooked tool available to engineers for querying and retrieving system information is the CPUID instruction.

What is the CPUID Instruction?

The CPUID instruction is a low level instruction, inside the heart of every modern x86 and x86-64 processor that allows the software to query the CPU for information about the processor and its supported features.

By invoking this instruction, you can gather information such as the processor’s model, family, internal cache sizes, and supported features like SIMD or hardware virtualization. This can help you optimize performance and dynamically enable or disable supported features.

For bootloader or kernel developers, understanding what features a processor supports—such as hardware virtualization, cache sizes, or SIMD instructions—can ensure that the system runs efficiently and that the code you write is compatible across different CPUs. By utilizing the CPUID instruction, you can dynamically adjust your kernel’s behavior based on the specific processor it is running on.

In this article you will learn how to check if the CPUID instruction is available for your system, how it works and what information you can get from using it.

Prerequisites

• Some knowledge of assembly language (for this example I use FASM)

• Some knowledge of operating systems/kernels

• Access to low-level debugging tools (for example, GDB) or hardware emulators like QEMU to test your bootloader/kernel on various platforms.

Step 1: Check for CPUID Availability

Before executing the CPUID instruction, it's important to determine whether the processor supports it, as not all CPUs are guaranteed to have this functionality. The following code checks the availability of the CPUID instruction by modifying and testing the ID bit (bit 21) in the EFLAGS register.

Here’s a picture from wiki.osdev.org that shows each bit of the EFLAGS register:

If the processor allows this bit to be toggled, CPUID is supported; otherwise, it is not. Here's how the detection process works:

(most people think that in Real mode 32 registers are not accessible. That is not true. All 32bit registers are usable)

cpuid_check:
    pusha                                ; save state
    pushfd                               ; Save EFLAGS
    pushfd                               ; Store EFLAGS
    xor dword [esp],0x00200000           ; Invert the ID bit in stored EFLAGS
    popfd                                ; Load stored EFLAGS (with ID bit inverted)
    pushfd                               ; Store EFLAGS again (ID bit may or may not be inverted)
    pop eax                              ; eax = modified EFLAGS (ID bit may or may not be inverted)
    xor eax,[esp]                        ; eax = whichever bits were changed
    popfd                                ; Restore original EFLAGS
    and eax,0x00200000                   ; eax = zero if ID bit can't be changed, else non-zero
    cmp eax,0x00
    je .cpuid_instruction_not_is_available
.cpuid_instruction_is_available:
    ;handle CPUID exists
.cpuid_instruction_not_is_available:
    ;handle CPUID isn't supported
.cpuid_check_end:
    popa                                  ; restore state
    ret

pusha: Saves all the general purpose registers to ensure the original state can be restored at the end.

pushfd: Saves the current EFLAGS register.

pushfd: Stores a copy of the EFLAGS.

xor dword [esp], 0x00200000: The code flips the ID bit (21) of the EFLAGS using the XOR operator.

popfd: Restores the modified EFLAGS with the ID bit inverted.

pushfd: Pushes the modified EFLAGS back to the stack.

pop eax: Puts the modified EFLAGS (ID bit may or may not be inverted) in the EAX register.

xor eax, [esp]: After the XOR operation, the EAX will contain the bits that were changed.

popfd: Restores the original EFLAGS.

and eax, 0x00200000: The and operation isolates the 21st bit (ID bit) by masking all other bits. After this operation the EAX register will contain either 0x00200000 (if 21 bit was changed which means CPUID is supported) or 0×00 (21 bit hasn’t changed, CPUID not supported).

cmp eax, 0x00: The CMP instruction checks the result of the previous operation. If EAX equals 0×00, it means that the ID bit cannot be modified and the processor doesn’t support the CPUID instruction. If it is not zero, it means that the ID bit was flipped and your processor supports the CPUID instruction.

Step2: How to Use The CPUID Instruction

Get CPU Features

The CPUID instruction will return different information with different values in the EAX register.

mov eax, 0x1
cpuid

With EAX set to 1, the CPUID will return a bitfield in EDX, which will contain the following values. Different brands may give different meaning to these (source https://wiki.osdev.org/CPUID)

enum {
    CPUID_FEAT_ECX_SSE3         = 1 << 0,
    CPUID_FEAT_ECX_PCLMUL       = 1 << 1,
    CPUID_FEAT_ECX_DTES64       = 1 << 2,
    CPUID_FEAT_ECX_MONITOR      = 1 << 3,
    CPUID_FEAT_ECX_DS_CPL       = 1 << 4,
    CPUID_FEAT_ECX_VMX          = 1 << 5,
    CPUID_FEAT_ECX_SMX          = 1 << 6,
    CPUID_FEAT_ECX_EST          = 1 << 7,
    CPUID_FEAT_ECX_TM2          = 1 << 8,
    CPUID_FEAT_ECX_SSSE3        = 1 << 9,
    CPUID_FEAT_ECX_CID          = 1 << 10,
    CPUID_FEAT_ECX_SDBG         = 1 << 11,
    CPUID_FEAT_ECX_FMA          = 1 << 12,
    CPUID_FEAT_ECX_CX16         = 1 << 13,
    CPUID_FEAT_ECX_XTPR         = 1 << 14,
    CPUID_FEAT_ECX_PDCM         = 1 << 15,
    CPUID_FEAT_ECX_PCID         = 1 << 17,
    CPUID_FEAT_ECX_DCA          = 1 << 18,
    CPUID_FEAT_ECX_SSE4_1       = 1 << 19,
    CPUID_FEAT_ECX_SSE4_2       = 1 << 20,
    CPUID_FEAT_ECX_X2APIC       = 1 << 21,
    CPUID_FEAT_ECX_MOVBE        = 1 << 22,
    CPUID_FEAT_ECX_POPCNT       = 1 << 23,
    CPUID_FEAT_ECX_TSC          = 1 << 24,
    CPUID_FEAT_ECX_AES          = 1 << 25,
    CPUID_FEAT_ECX_XSAVE        = 1 << 26,
    CPUID_FEAT_ECX_OSXSAVE      = 1 << 27,
    CPUID_FEAT_ECX_AVX          = 1 << 28,
    CPUID_FEAT_ECX_F16C         = 1 << 29,
    CPUID_FEAT_ECX_RDRAND       = 1 << 30,
    CPUID_FEAT_ECX_HYPERVISOR   = 1 << 31,

    CPUID_FEAT_EDX_FPU          = 1 << 0,
    CPUID_FEAT_EDX_VME          = 1 << 1,
    CPUID_FEAT_EDX_DE           = 1 << 2,
    CPUID_FEAT_EDX_PSE          = 1 << 3,
    CPUID_FEAT_EDX_TSC          = 1 << 4,
    CPUID_FEAT_EDX_MSR          = 1 << 5,
    CPUID_FEAT_EDX_PAE          = 1 << 6,
    CPUID_FEAT_EDX_MCE          = 1 << 7,
    CPUID_FEAT_EDX_CX8          = 1 << 8,
    CPUID_FEAT_EDX_APIC         = 1 << 9,
    CPUID_FEAT_EDX_SEP          = 1 << 11,
    CPUID_FEAT_EDX_MTRR         = 1 << 12,
    CPUID_FEAT_EDX_PGE          = 1 << 13,
    CPUID_FEAT_EDX_MCA          = 1 << 14,
    CPUID_FEAT_EDX_CMOV         = 1 << 15,
    CPUID_FEAT_EDX_PAT          = 1 << 16,
    CPUID_FEAT_EDX_PSE36        = 1 << 17,
    CPUID_FEAT_EDX_PSN          = 1 << 18,
    CPUID_FEAT_EDX_CLFLUSH      = 1 << 19,
    CPUID_FEAT_EDX_DS           = 1 << 21,
    CPUID_FEAT_EDX_ACPI         = 1 << 22,
    CPUID_FEAT_EDX_MMX          = 1 << 23,
    CPUID_FEAT_EDX_FXSR         = 1 << 24,
    CPUID_FEAT_EDX_SSE          = 1 << 25,
    CPUID_FEAT_EDX_SSE2         = 1 << 26,
    CPUID_FEAT_EDX_SS           = 1 << 27,
    CPUID_FEAT_EDX_HTT          = 1 << 28,
    CPUID_FEAT_EDX_TM           = 1 << 29,
    CPUID_FEAT_EDX_IA64         = 1 << 30,
    CPUID_FEAT_EDX_PBE          = 1 << 31
};

A brief explanation of the CPU features above:

• PCLMUL, AES: Cryptographic instruction sets for fast encryption and decryption.

• VMX, SMX: Virtualization support for running virtual machines.

• SSE3, SSSE3, SSE4.1, SSE4.2, AVX: SIMD instruction sets for faster multimedia, math, and vector processing.

• FMA: Fused Multiply-Add, improves performance in floating-point calculations.

• RDRAND: Random number generator.

• X2APIC: Advanced interrupt handling in multiprocessor systems.

• PCID: Optimizes memory management during context switches.

• FPU: Hardware floating-point unit for faster math operations.

• PAE: Physical Address Extension, allows addressing more than 4 GB of memory.

• HTT: Allows a single CPU core to handle multiple threads.

• PAT, PGE: Memory management features for controlling caching and page mapping.

• MMX, SSE, SSE2: Older SIMD instruction sets for multimedia processing.

Get CPU Vendor String

If you want to get the CPU vendor string, EAX should be set to 0×0 before invoking the CPUID instruction.

mov eax, 0x0
cpuid

The vendor string is a unique identifier that CPU vendors like AMD and Intel use. Examples are: GenuineIntel (for Intel processors) or AuthenticAMD (for AMD processors). It basically specifies the manufacturer of the CPU.

The vendor string allows the kernel to identify the CPU manufacturer which is very useful because different manufacturers implement certain features differently. Also, software or drivers can interact differently based on the CPU manufacturer to ensure compatibility.

When used like this, the vendor id string will be returned in EBX, EDX, ECX registers. You can write them to a buffer and get the full 12 character string.

Example code:

Step 1: The Buffer

Create a buffer that can hold 12 bytes:

buffer: db 12 dup(0), 0xA, 0xD, 0

Step 2: Print the Buffer

We start by creating a string printing function.

This assembly code reads a string character by character and prints it to the screen using BIOS interrupt 0x10. The print function loops through the string and uses the lodsb instruction to load each character in the al register.

Then the print_char function uses the interrupt 0×10 to print it on the screen. When the code reaches the end of the string (null terminator), the loop ends.

print_string:
    call print
    ret
print:
.loop:  
    lodsb   ;read character to al and then increment
    cmp al ,0 ;check if we reached the end
    je .done  ;we reached null terminator, finish
    call print_char ;print character
    jmp .loop   ;jump back into the loop
.done:
    ret
print_char:
    mov ah, 0eh
    int 0x10
    ret

Step 3: Fill the Buffer and Print it

Here, after saving the current state using the pusha instruction and calling cpuid with 0×0 passed in the EAX register, we can store the contents of ebx, edx, ecx to the buffer. Then we call print_string to print it.

get_cpu_vendor:
    pusha
    mov eax, 0x0
    cpuid
    mov [buffer], ebx
    mov [buffer + 4], edx
    mov [buffer + 8], ecx
    mov si, buffer 
    call print_string
    popa
    ret

A video from my YouTube channel where I implement and explain the code above in detail

More information about what information CPUID instruction can give you according to the value passed in the EAX register, can be found here: https://gitlab.com/x86-cpuid.org/x86-cpuid-db

Epilogue

By understanding and using the CPUID instruction, you can make your bootloader/kernel more adaptable to a wide range of processors. Knowing how to detect the instruction's availability and retrieve crucial system information—such as CPU features, cache sizes, and supported technologies—can significantly enhance performance and compatibility.

After reading this article, you should have the tools and knowledge to start exploring the CPUID instruction and how you can use it in your own project!

Happy coding!

But not all memory is freely available for use. Some memory sections are reserved for system functions and others may be occupied by hardware devices. That’s why it is very important to get the system’s memory map.

What is a Memory Map?

But what is a memory map? A memory map is a representation (think about it like a table) that shows how physical memory is organized in your system. It shows the address of each memory region, it’s length and it’s type.

Type 1 means that the region is available for you to use freely and type 2 means that it is reserved by your system. Type 3 means that the region is reserved for the Advanced configuration and power interface (ACPI 3.x). While a type 3 region might not be used by the system, it can be reclaimed later.

Using a memory map will allow you to manage memory resources successfully without any issues such as crashes or system instability.

There are some ways you can detect your system’s available memory. One is by using the BIOS and interrupt 15h. Another one is by doing memory probing.

In this article you will learn which tools are available to help you get a memory map of your system, which ones you should use, and which ones you should avoid and why. Then finally, you will see some assembly code that you can use in your own bootloader / kernel.

Prerequisites

if you want to follow along with the code shown in this article, you’ll need:

• A Linux operating system

• Some knowledge of assembly language

• A text editor of your choice

• An emulator installed. For this example I use QEMU.

• FASM assembler installed

• Git to be able to clone the repository (https://github.com/nikolaospanagopoulos/memoryMapBoot)

A Few Words about BIOS int 15h

In Real mode, the BIOS offers many interrupts that interact with the hardware and can give you information.

There are some interrupts that can help with getting a memory map, but the most powerful one is int15h with E820h function (hexadecimal numbers! very important to remember. Decimal numbers will not work). This method offers a detailed memory map that you can use to safely determine which areas of memory can be used for vital tasks like setting up paging, memory allocation, and more.

In this article you will see how you can use this interrupt to get a detailed memory map of your system.

Now, before we go deeper, I would like to add a few things about memory probing and why you should avoid it.

Memory probing and why you should avoid it

Memory probing is the process of manually accessing physical memory and determining whether it is available or not. The issue is that not all memory is designed to be accessed directly.

Accessing parts of memory that you shouldn’t can cause unpredictable behavior like:

• System Crashes: some memory is reserved for BIOS structures, hardware devices etc. Accessing those areas can lead to system crashes or system instability.

• Memory Corruption: accessing reserved memory areas can lead to corruption of those areas. This can cause again crashes, instability, malfunctions etc

So, you should avoid memory probing because it’s an unnecessary risk to your kernel development process.

The Code

Step 1: Prepare to Call int 15h

In this part, you will basically setup the environment needed to invoke int 15h. The general purpose registers need to be stored so that no important data on them is lost during the interrupt invocation. Then the registers bp, ebx are cleared so that they can be set to their initial values.

The “SMAP” value is stored in the edx register to ensure the correct format that the BIOS will return. Finally, we setup the 0xe820 function and request memory map data.

pusha
mov di, 0x0504        ; Set DI register for memory storage
xor ebx, ebx          ; EBX must be 0
xor bp, bp            ; BP must be 0 (to keep an entry count)
mov edx, 0x534D4150   ; Place "SMAP" into edx | The "SMAP" signature ensures that the BIOS provides the correct memory map format
mov eax, 0xe820       ; Function 0xE820 to get memory map
mov dword [es:di + 20], 1 ; force a valid ACPI 3.X entry | allows us to get additional information (extended attributes)
mov ecx, 24           ; Request 24 bytes of data

• The pusha command pushed all general purpose registers to the stack to save their values during the interrupt call. They can be restored after the interrupt call to avoid corruption of other areas.

• The mov di, 0x0504 instruction sets the di register to 0×0504 (where the memory map entries will be stored).

• xor ebx, ebx the xor instruction uses the xor operator to clear the ebx register. It must be set to 0 to start retrieving entries.

• xor bp, bp use of the same xor operator here to set bp to 0. This will keep track of your memory entries.

• mov edx, 0x534D4150 this instruction will store 0x534D4150 (ASCII string “SMAP”) into the edx register. It makes certain that the BIOS will return the correct format for your memory map.

• mov eax, 0xe820 this instruction sets the function 0xe280 which will get the memory map along with int15h.

• mov dword [es:di + 20], 1 this instruction forces a valid ACPI (Advanced Configuration and Power Interface) 3.x entry. This way the BIOS provides extra information in the form of extra attributes.

• mov ecx, 24 this instruction asks the BIOS for 24 bytes of memory data. This is the size that ACPI 3.x entries need to include extra information.

Step 2: Call int15h

Here, you can finally invoke the interrupt to fetch the memory map. You need to check that the function is supported by the BIOS and that valid data is being fetched. You also need to ensure that the correct format is being fetched by setting again the “SMAP” into the edx register.

    int 0x15                 ; using interrupt
    jc short .failed         ; carry set on first call means "unsupported function"
    mov edx, 0x534D4150      ; Some BIOSes apparently trash this register? lets set it again
    cmp eax, edx             ; on success, eax must have been reset to "SMAP"
    jne short .failed
    test ebx, ebx            ; ebx = 0 implies list is only 1 entry long (worthless)
    je short .failed

• int 0x15 this instruction invokes the interrupt 0×15.

• jc short .failed is the carry flag that is set. It means the function is unsupported and the call has failed. It jumps to our error handler.

• mov edx, 0x534D4150 set again the “SMAP” because some BIOSes corrupt this register after the call.

• cmp eax, edx if the call is successfull, on success the BIOS will return the “SMAP” value in eax.

• jne short .failed if it doesn’t, it means the call has failed and it jumps to our error handling label.

• test ebx, ebx this instruction checks if ebx is 0 after the first call. This means that the memory map only contains one entry. This entry is probably invalid, so it jumps to the error handling label.

Step 3: Loop Through Memory Entries

After a successful first invocation, you need to loop through each entry of the memory map.

In the loop, you will invoke again int 15h to get all subsequent memory entries while checking each entry’s length and other attributes. If it meets the criteria, you increment the counter and you store the entry. This continues until there are no entries left to process.

    jmp short .jmpin
.e820lp:
    mov eax, 0xe820          ; eax, ecx get trashed on every int 0x15 call
    mov dword [es:di + 20], 1 ; force a valid ACPI 3.X entry
    mov ecx, 24              ; ask for 24 bytes again
    int 0x15
    jc short .e820f          ; carry set means "end of list already reached"
    mov edx, 0x534D4150      ; repair potentially trashed register
.jmpin:
    jcxz .skipent            ; skip any 0 length entries (If ecx is zero, skip this entry (indicates an invalid entry length))
    cmp cl, 20               ; got a 24 byte ACPI 3.X response?
    jbe short .notext
    test byte [es:di + 20], 1 ;if bit 0 is clear, the entry should be ignored
    je short .skipent         ; jump if bit 0 is clear 
.notext:
    mov eax, [es:di + 8]     ; get lower uint32_t of memory region length
    or eax, [es:di + 12]     ; "or" it with upper uint32_t to test for zero and form 64 bits (little endian)
    jz .skipent              ; if length uint64_t is 0, skip entry
    inc bp                   ; got a good entry: ++count, move to next storage spot
    add di, 24               ; move next entry into buffer
.skipent:
    test ebx, ebx            ; if ebx resets to 0, list is complete
    jne short .e820lp

• .e820lp is a label for looping through each memory map entry.

The next lines are used to call int15h to get the next memory entry:

• jc short .e820f if the carry flag is set, it means that we have reached the end of the list.

• jcxz .skipent if ecx register is 0, it means the length of the memory entry is invalid. So the code skips it.

• cmp cl, 20 checks if the memory entry is a valid ACPI 3.x entry. (It would be 24 bytes long). If it is not, the code jumps to .notext.

• test byte [es:di + 20], 1 checks if bit 0 is set in the memory entry's extended attributes, indicating a valid entry. If it's clear, the entry is skipped.

• mov eax, [es:di + 8] gets the lower 32 bits of the memory region length and then we combine it using the or operator, with the upper 32 bits. If the total length is 0, then the entry is skipped.

• inc bp increments entry count.

• add di, 24 moves the pointer di forward to the next memory entry. Each entry is 24 bytes long.

Step 4: End of Memory Entries Handling

Finally, you can store the entry count. And by using the popa instruction, you will restore all general purpose registers to their previous values. If an error occurs during the process, the code jumps to .failed label which is our error handling function.

.e820f:
    mov [mmap_ent], bp       ; store the entry count
    clc                      ; there is "jc" on end of list to this point, so the carry must be cleared

    popa
    ret
.failed:
    stc                      ; "function unsupported" error exit
    ret

• mov [mmap_ent], bp stores the entry count.

• clc clears the carry flag because it is already set.

• popa pops all general purpose registers back from the stack.

• .failed we use this label for error handling.

Here is a video from my YouTube account where I implement and explain the above code:

Epilogue

In kernel development, one of the most important tasks is managing memory. The above is a reliable way to detect your system’s memory layout information. This means that you can make safe decisions when allocating resources, implementing paging, and so on.

It might appear to be complex and it maybe is, but if you follow the code line by line you will be able to understand it. These techniques will allow you to build a robust kernel capable of running on different hardware configurations.

Keep Coding!