capstone blog

Since the capstone will be about building a minimalistic operating system, a great starting place to investigate would be, what is there before we have the OS? If this is TLDR; go to end of blog for a nice process diagram with the important parts.

Content Sources

• wikipedia
• Intel Software Developer Manual Vol. I Chapter 3
• Rootkits and Bootkits [ISBN: 978-1-59327-716-1]
• Upgrading and Repairing PCs [ISBN: 978-0-7897-5610-7]
• https://www.computerhope.com/jargon/b/bios.htm
• https://infocenter.nordicsemi.com/pdf/S140_SDS_v2.1.pdf
• https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf
• https://www.manualslib.com/manual/892490/Nec-Cp-M-86.html#manual

Toto, I have a feeling we are not in Kansas anymore…

Before all ability to have an OS loaded and functioning, we are existing in a strange and peculiar place. This place is known as the CPU in real mode place. This real mode is a space, even before BIOS installation happens, it is like the air in the space. The original CPU chips would be in 16-bit register usage, which is what this mode is. You might be wondering why this is the case. For one note, Intel aimed at always being “backward compatible”, meaning even if the CPU was upgraded, legacy os/software could still be able to perform. Secondly, when we have the 16-bit real mode as the original start, it is not quite like the original 16-bit normal mode one could see back when these chips were the top-tech, as this had a huge flaw of critical memory being able to be handled by the general user — now, more steps have been in place to still give the 16-bit environment, with more security. The need of the OS can change this mode with a single line within their source code, however initially the state will be 16-bit.

Second part of growing the ecosystem within this space would be this installation of BIOS. BIOS is a way to have “bare bones” access to in and out devices, hence the name Basic Input Output System. How does the bare system even have loading capabilities to a BIOS? It is a chip, usually an EEROM chip. Fun fact, some earlier BIOS chips would have a window you could look inside, not the exact aim here. I mean it is always interesting to view the die’s internals, however there is another reason why this little window was here. Oh, no, it is also not the case either as a tribute to Windows OS as literally having a window. These little windows were for erasing with a UV light beam. There was a phase of chips created of which you could erase by UV light waves. Hoped you liked the fun fact, back to BIOS. You can make a connection between the ROM cartridges (think BIOS) for a NES system (think CPU), they have the game, and you already have base instruction set on what to do, if asked. BIOS is like another layer of interaction we can have to hardware, at the very start of the power up.

More on BIOS

First BIOS was created in 1974, developer Gary Kildall, for the CP/M operating system, produced in 1975 for IBM PC. His aim for BIOS literally was the sole piece of the system which loads to communicate with machine hardware. Today, most BIOS are installed within the motherboards of the whole system or some other type of adapter-like concept, like adapter boards. Companies which are used by most Western technology manufacturers include: American Megatrends, Inc. [AMI], Awards Software, Insyde Software, and Phoenix Technologies (owns Awards Software). There have been advances to make more efficient BIOS implementations for each particular purpose. The purposes could be for pcs, servers, mobile phones, USB devices, and also ones optimized for 32-bit or 64-bit needs, plus more! The Unified Extensible Firmware Interface (UEFI) is usually weaved into the BIOS, for needs of handling OS loading from hard drives with partitions larger than 2TB, all listed companies work within these product needs too.

That is all great, what about more details about BIOS capabilities?

BIOS has subroutines of which act as interrupt procedures. Each will have its own needed loaded parameters (or not) in particular registers before calling. Below is a list from Wikipedia.

int 0x05 -- detects bound failure
int 0x08 -- real time clock (18.2 times/sec) 
         -- increments time-of-day counter with
int 0x09 -- keyboard interrupt
int 0x10 -- video/display services (write something, teletype, etc.)
int 0x11 -- returns equipment list
int 0x12 -- returns base memory list (first 640 KB)
int 0x13 -- low level disk services 
         -- (read/write/get/set/extend/eject/etc.)
int 0x14 -- serial port servies
int 0x15 -- miscellaneous system services
int 0x16 -- keyboard input/storing services
int 0x17 -- printer services
int 0x18 -- execute Cassette BASIC, 
         -- modern,  will boot from a network
         -- modern, bootloader has failed at some task
int 0x19 -- used to load the OS
int 0x1A -- real time clock services and PCI servies
int 0x1B -- ctlr-break handler, called by int 0x09
int 0x1C -- timer tick handler, called by int 0x08
int 0x1D -- points to VPT (Video Parameter Table) holding video modes
int 0x1E -- points to DPT (Diskette Parameter Table) 
         -- info on diskettes
int 0x1F -- points to VGCT (Video Graphics Character Table) 
         -- ASCII characters
int 0x41 -- address pointer first hard drive
int 0x42 -- address pointer second hard drive
int 0x4A -- called by RTC for alarm

MBR Notes

Master Boot Record or MBR, is the place on the chip memory where the system vector is stored. You can think of this as a controller between the incoming exceptions and what next to do with forwarding to proper handlers. It should be noted here this data structure will not be erased during a firmware update, it is here to stay with this chip for the long haul, like a dear friend. Ultimately, this provides information on boot code and hard drive partitions within the whole system. Below is a nice comparison of MBR compositions. Capacity will always be 512 bytes on all, as you will note.

Main task of MBR is to determine the active partitions of bootable hard drive — this holds the OS to load. When the game of hide and seek is over, the MBR reads and executes the boot code. Here is the data struct for a MBR:

typedef struct _MASTER_BOOT_RECORD{
    BYTE BootCode[0x1BE];
    MBP_PARTITION_TABLE_ENTRY partitionTable[4];
    USHORT mbrSignature;
} MASTER_BOOT_RECORD, *PMASTER_BOOT_RECORD;

The BootCode with memory location is where the boot code exists, and the mbrSignature is the Magic Number or pattern, depending on if you check out the binary equivalent to 0xAA55. The internet will tell this is a nice pattern which was originally used for detection of errors within connecting devices. It probably is an easy pattern for the machine level parsing to pick up too. Something to note, this probably should have been placed earlier in the paragraph, the [0x1BE] is not the 512 bytes, it is actually 446 bytes, meaning that this is the maximum allotted space the boot code is allowed to have, as the other bytes between must be used for other useful things.

MBR Notes – Partition Table

This is the part within the above MASTER_BOOT_RECORD structure will be parsing, and like above states, it has four parts.

typedef struct _MBR_PARTITION_TABLE_ENTRY{
    BYTE status;
    BYTE chsFirst[3];
    BYTE type;
    BYTE chsLast[3];
    DWORD lbsStart;
    DWORD size;
} MBR_PARTITION_TABLE_ENTRY, *PMBR_PARTITION_TABLE_ENTRY

(1) Partition status will let the system know if this is the single active partition or not, it is another. (2) Partition types will be something similar to EXTENDED MBR, FAT12, FAT16, FAT32, IFS, LDM, NTFS, etc. Oh, if the type is labeled as ‘0’, this means it is unused. The MBR is not granted the ability to parse the particular file systems, so it will read and execute the first sector of the partition, known as VBR — houses other things, more on that later. (3) Partition lbsStart and (4) partition size will tell exactly the location of the partition on the disk, represented in sectors. For a floppy, for example, it could be given in the CSH (cylinder-sector-head) format, think about the organization of the platters!

VBR Notes

This is the first sector of the partition and readable by the MBR. Here you will find BIOS parameter block, bootstrap code. The layout of these will always be dependent of the filesystem structure of the main partition. Mainly, the VBR will load the IPL or initial program loader, BIOS parameter block is held here, text strings for human readable/printable error alerts, and Magic Number 0xAA55 as a signature.

VBR Notes – IPL

This Initial Program Loader will read and load the OS boot manager from the file system. Once this happens, the boot manager (windows) or boot loader will fully take over.

Putting it all together

Even though this listing will not be of today’s steps, the idea essentially remains the same. Having a step through outline on a process is usually helpful to solidify what is actually happening, which is why it is here for your viewing pleasure.

Legacy Boot Process Steps [1980s-2000s]

1. Cold Boot — power is connected/on
2. Power supply testing
3. ROM BIOS execution
4. ROM BIOS hardware testing
5. Video testing
6. Memory testing
7. Power-On Self-Test (POST) — full hardware test, skipped if warm/soft boot
8. MBR testing at defaulted first sector of boot drive, stated within the BIOS setup schema
9. MBR execution
10. OS file initialization
11. Base device driver initialization
12. device status check
13. configuration file reading
14. command shell loading
15. Startup command file execution of shell

Previously, one can note, a lot of care went into ensuring each piece of equipment was fully functioning enough to go to the next step in the sequence, a good idea.

Conclusion

Below is a high-level overview of all the topics briefly covered within this post, outlining what is to be expected in the states preceding the Minimalistic OS fully running and speaking directly to the hardware.

So the question remains, and will not be answered in this blog or a future post — is it possible to have the OS as a chip directly on the motherboard and skip all the steps of the BIOS interactions with hardware scheme. Can you have the OS as the starting point, and if you can, could this type of setup prevent more low level attacks from the venerable starting in the magic and spacey boot land?

Thank you for reading.

Tags: BIOS, boot sect, bootloader, magic number, nasm, researching