How to get to know the memory address at which my code/data is actually loaded at boot initialization stage?

In embedded software development, sometimes when you're writing a PIC (position independent code) boot code, you might need to know at which memory address my bootstrap code/data is loaded by a loader at runtime. This article discusses the solutions to this question with assembly language implementation (x86). 

Good practices for programming with hardcode

What a contradiction!

Programming with many hardcodes is not a good practice because it is hard to understand and also has maintainability issue, for example, when a condition is changed for some reason, the previous well-tuned hardcode value might not be working any more.

However, when there are some conditions under which we must have to write hardcodes when programming, then what're good practices? The rest of this article is focusing on this. 

Approach to retrieving the physical memory map on different system (SFI, LEGACY,UEFI)

According to Wikipedia, in computer science a memory map is a structure of data (which usually resides in memory itself) that indicates how the memory space is laid out. In the boot process, a memory map is passed on from the firmware in order to instruct an operating system kernel about memory layout. It contains the information regarding the size of total memory, the range of specific memory space and any reserved regions, it may also provide other details specific to the architecture and platform.

Monitoring Windows OS scheduling events in a noninvasive way with Hardware Virtualization technology (Anti-Rootkit)

A rootkit is a stealthy type of software, typically malicious, designed to hide the existence of itself or certain processes/programs from normal methods of detection and enable continued privileged access to a computer. However, even though the malicious process/program can be invisible to users, internally it must have to get time slices for running, otherwise if it has no chance to get scheduled by CPU, such an existence is meaningless for malware author. 

This article provides a solution to detect the malware and inspect its behaviors by monitoring each OS thread scheduling event.

Debug Registers on Intel x86 Processor Architecture (with or without VT-x)

Intel processor architectures provide debug facilities for use in debugging code and monitoring system behaviors. Such a debug support is accessed using debug registers (DR0 through DR7), and handled by a dedicated exception routine. 

Debug registers (Dr0~DR3) hold the addresses of memory and I/O locations called breakpoints. Breakpoints are user selected locations in a program, a data-storage area in memory, or specific I/O ports. They are set where a programmer or system designer wishes to halt execution of a program and examine the state of the processor by invoking debugger software. A debug exception (#DB, vector = 1) is generated when a memory or I/O access is made to a breakpoint address.

Multiboot Specification and limitations (Bootloader -> OS)

Typically in a computer system, the boot sequence is like this: firmware -> bootloader -> Operating System.  The problem is that nowadays we have the largest variety of operating systems, boot loaders, and firmwares (UEFI/Legacy), and even some of them are proprietary software that are not public. So, the interaction might be a problem if the interface is not well-defined. 

TESTING

This is a test, just a test!