Operating System Boot and operating system boot

Operating System Boot and operating system boot

System guidance is the most important link in the operating system startup process and one of the most vulnerable links. In accordance with the hardware standards of personal computers, the boot phase occurs after the computer's Hardware System has been detected. The specific boot work is completed by the BIOS. The BIOS maintains a list of hardware devices that can be used to guide the computer, such as the local hard disk, local optical drive, network, and USB interface devices. The BIOS tries to check the status and boot capability from the first device in the entire sequence. For example, for the optical drive, the system first checks whether there is a CD in the optical drive. If not, the optical drive device is skipped and the next device is inspected. If a disc exists, read the first slice of the disc and check whether it is a bootable slice (for example, check whether the last two bytes of the slice are 0x55AA ). If it is not found to be a bootable sector, it is also to skip the disc, and then check the next device in the boot sequence until a bootable sector is found. If you do not find any sector code when traversing the complete list of boot devices, the boot process fails and the BIOS will prompt you That the boot device cannot be found. If a bootable sector can be found in this process, the BIOS loads the content of this sector to the memory, jumps to this sector, and executes the boot code. This jump command is the last command of the BIOS program during the startup of the computer. At this point, the BIOS is finished. The subsequent work will be completed by the guide sector code.

It can be seen that the role of BIOS in the computer boot process is very important and complex. However, because it is independent from the implementation of the operating system, it is not the scope of our analysis. In this article, we will focus on the process of loading the Boot Sector to the memory and starting execution. This process belongs to the role of the operating system and is the initial part of the operating system lifecycle. This article takes the hard disk as an example. First, it analyzes the logic structure of the hard disk and the role of the Master Boot Record (MBR), and then analyzes the different file systems, differences in features and implementations of the Operating System Boot Sector and functional defects of each implementation. Finally, we provide a bootstrap Program Creation Method to overcome these defects-the preset bootstrap method, and use the Hello China Operating System Bootstrap program as an example to describe the application of this method.

Hardware logic structure and boot sector functions

You can logically think of a hard disk as a linear array. The element of this array is the sector. Each sector is numbered based on its location on the hard disk. the first sector is the well-known MBR (Master Boot Record ).

For ease of management, a hard disk can be divided into several logical partitions, each occupying part of the continuous storage space on the hard disk. Generally, the location and size of the partition on the hard disk can be described by the START sector number and number of sectors on the hard disk. The current implementation is that a physical hard disk can be divided into up to four partitions. The partition location, size, attributes, and other information are recorded in a linear table with only four elements. This table is a partition table.

The partition table is stored in the MBR and fixed in the MBR. Generally, the capacity of each sector of the hard disk is 512 bytes. if the location of the partition table in MBR is not fixed, the content of the partition table cannot be clearly read. However, the partition table is not the only content of MBR, and MBR also stores the Boot Sector Code. After the BIOS finds a bootable hard disk, it reads the MBR code into the memory and jumps to the start point for execution. Note that the MBR code is generally unrelated to the operating system. This may cause some doubts. I will explain it later.

The operating system is installed on the hard disk partition. at least so far, I still don't know which operating system I have installed directly without partitioning the hard disk (or taking the entire hard disk as a partition. The operating system's specific Boot Code is placed on the first sector of its partition. For example, a hard disk is divided into two partitions. The starting fan area number of a partition is 2 (the fan area number of MBR is 1), and the number of sectors is M. The START fan ID of another partition is M + 2, and the number of slice is N. Assume that the WINDOWS operating system is installed on the first partition, And the Linux operating system is installed on the second partition. In this way, the Boot Sector of the WINDOWS operating system is two physical sectors (the first sector of the first partition), while the Linux boot sector is the M + two physical sectors. Obviously, these two boot sectors (2nd and M + 2) are strongly related to the operating system.

However, the BIOS initially reads MBR. Once you jump into the MBR for execution, the BIOS will be idle. At this time, the MBR code must be able to find the Boot Sector for Windows or Linux, and read them into the memory to complete the boot of the corresponding operating system. Therefore, the MBR function code must complete two decisions:

1. There are multiple partitions on the hard disk, and each partition may have an operating system installed. How can I select a partition for further boot?

2. If a partition is determined, how can we obtain the physical location of the Boot Sector of the partition (that is, the number of the sector on the entire physical disk )?

Obviously, when the first problem is identified, the second problem can be easily solved. At this time, the partition number has been determined. As long as you read the partition table and find the corresponding record, you can read the number of the first sector of the partition, which is the Boot Sector. The first problem is solved by setting an activity flag in the partition table. Each partition table item (corresponding to a partition) has a byte called the activity flag, and only one of the four Partition Table items must have an activity flag set, this partition is the active partition. The operating system installed on this partition will be guided. Who will set this flag? The answer is the operating system. During Operating System installation, you will be asked to select the partition to be installed (for example, Windows will list the partition information of the hard disk, which is expressed by drive letters such as C: And D ). Once a partition is selected, the Windows Installer sets the activity flag of the Partition Table item corresponding to the partition to 1, and clears the activity flag of other partition table items.

According to this rule, the last installed operating system will often "Suppress" the previously installed operating system, making the previously installed operating system unable to boot. But as long as we know this process, we can use some tools to change this situation. For example, if you last installed windows, you can change the partition of the Linux operating system to an active partition by running a tool on Windows. In this way, Linux will be guided during the next startup. However, for the sake of security, the operating system provides protection for MBR and cannot directly write data to MBR. This is very troublesome. Once you install windows, it means that the original Linux (which is different from the newly installed windows) cannot be used. However, this is not absolute. For example, you can modify the MBR through the operating system guided by the CD. Alternatively, you can install Hello China on the WIN partition. Hello China helps you modify the active partition flag.

Back to the original question, MBR selects a partition based on the activity indicator, and determines the operating system boot sector based on the start position of the partition in the partition table, then reads the sector into the memory, and jumps to the start position for further execution. It can be seen that MBR itself has nothing to do with a specific operating system. In fact, the executable code of the MBR sector has never changed since DOS.

A physical hard disk can have up to four partitions. Some software companies, such as MS, think this is not enough. So I invented another technology called extended partitioning. An extended partition is essentially a hard disk partition (one of the four partitions). On this basis, it is further extended to further segment a partition, it is divided into smaller partitions (these smaller partitions are called logical partitions), that is, the structure of the partition set partition. Like the hard disk MBR, information about logical partitions is recorded on the first sector of the extended partition. However, unlike normal partitions, logical partitions on extended partitions cannot guide the operating system, that is, the operating system cannot be installed on logical partitions. Since the operating system cannot be installed in a logical partition, it certainly cannot be installed in an extended partition. Because the extended partition is the "Container" of the logical partition, there is no storage space for the operating system file. Therefore, to install the operating system, you must install it on a common disk partition. To display this feature of "accommodating" the operating system, common partitions are named "primary partitions.

At this point, you should be clear about the following concepts or principles:

1. MBR and partition tables;

2. the MBR code has nothing to do with the operating system;

3. the operating system's specific boot sector is the first sector of the installed partition;

4. logo of partition activity;

5. Main partitions, extended partitions, and logical partitions;

6. Relationship between MBR and Operating System Boot Sector.

Features and limitations of Operating System Boot Sector

Next we will focus on the operating system boot sector, that is, the first sector of the operating system partition. The operating system boot sector is closely related to the operating system. Its main function is to find the file related to the operating system kernel in the operating system partition to load the operating system. The "boot operating system-related files" mentioned here may be the core modules of the operating system or some executable code prepared to further guide the core modules of the operating system. After all, the modern operating system is very complex, and the core module is very large and cannot be directly guided. In this way, there may be some auxiliary boot modules. After all, the function of the boot sector code is very limited.

However, in any case, the code of the boot sector must find a module (actually a file) in the file system of the partition where the operating system is located and load it To the memory. Therefore, the following two functions are at the core of the Boot Sector Code:

1. Find a specific file on the partitioned file system;

2. Load the file into the memory and jump to the execution.

The second task is relatively easy. Generally, the boot sector is still running in the actual CPU mode (taking PC as an example) And you can call the disk read/write service provided by BIOS, it is easy to read files into the memory. The key is the first task: how to find a specific file in a file system. In fact, "Finding a file" is not the key. The key is how to find a desired file in a complicated file system using "one sector" code. There is a conflict between the two factors:

1. The size of the Boot Sector Code is limited. For example, the size is only 512 bytes, which cannot meet complicated computing requirements;

2. The structure of the file system is complex and requires a large amount of code to access the file system.

The boot sector must be well balanced so that the boot process can continue. In general, there are several ways to solve this problem:

1. Expand the size of the boot sector. Generally, the Boot Sector of the operating system is 512 bytes, and the initial boot of the operating system is completely completed by the 512 bytes of code. In fact, many operating systems, such as Windows, have greatly expanded the size of the boot sector. Since the entire partition is the territory of the operating system, the operating system determines how to use each partition. The boot sector is the first sector of the partition, which cannot be changed. Then I can take the second, third ,... The Nth sector is also used as the guiding sector. The first sector is just a stepping stone. After the MBR reads the first sector into the memory and runs, the first sector then reads the next consecutive sector into the memory. All these sectors form a pilot module. In this way, no matter how complicated the file system is, I only need to allocate several more slices to install the code to access the file system. Obviously, this method is very effective and widely used. For example, in windows, there are 16 boot sectors on the NTFS file system (0 ~ Sector 15), with 8 K code space. This is enough to analyze the NTFS file system and read the boot file (such as NTLDR;

2. the boot sector remains unchanged, but the operating system core or related files are fixed on the disk. In other words, the whole site is mine. I am willing to arrange where anyone is. The operating system can fix the boot-related code on a specific disk location, such as the position of sector No. 1024. In this way, the boot sector does not need to analyze the file system. You can simply read the core of the operating system from Sector 1024. This strategy seems to have been used in the DOS era. I remember when I went to college, I made a DOS boot floppy disk with files such as IO. SYS. Once I deleted the IO. SYS file and copied it again, the DOS cannot be started. According to this, DOS may fix IO. SYS and so on to a certain position of the floppy disk. Once the copy operation is deleted, the position of the copy operation changes, which directly causes no guidance.

Both solutions have their own limitations. The first solution is to install only one operating system in one partition, or install different operating systems of the same software vendor. However, if the operating systems of two different vendors are installed, there may be problems. Assume that operating systems A and B use the first policy. A is first installed on the partition. When installing the second operating system B, in order to guide the system at the same time, B will set the leading sector of A (the first sector) back up data to a file (for example, BOOTSECT in windows. DOS), and then write your own Boot Sector (several consecutive) to the start of the partition. In this way, all boot sectors except the first operating system A are overwritten by B. Obviously, system A cannot be guided again at this time. However, if A and B are products of the same software company, such as Windows 98 series and Windows 2000/XP series, because they are both developed by Microsoft, the structure and quantity of the boot sector are known, in this way, when xp or other later OS versions are installed on windows 98, a later OS (such as XP) all the boot sectors of the original system will be packaged into a single file, so that there will be no overwriting problems. If there is still a problem with this packaging (for example, the first sector will call the BIOS service to read the subsequent sector, and this action cannot be changed even if it is packaged ), xp may even modify the packaged Boot Sector file. The key here is that the operating system of the latest version can identify and effectively handle the operating system of the original version.

The disadvantage of the second solution is that the file system must be well supported. For example, if you fix the location of a file and require that the location cannot be changed (unless the file is deleted ), in this way, the file system cannot change the file location (or perform separate processing on the operating system files). Otherwise, this method will become invalid. This is obviously harsh, and the result is that the file system cannot change the location of existing files, resulting in a large number of disk fragments. Common file systems, such as FAT, NTFS, and EXT, do not provide this function. Therefore, the application scope of the second solution is very limited. Only some early operating systems will be used. Currently, most operating systems adopt the first solution.

At this point, you should be clear about the following concepts or principles:

1. The operating system may have more than one boot sector;

2. for complex file systems such as FAT32 and NTFS, multiple boot sectors are required to fully accommodate the Boot Code;

3. Fixed the location of the core file of the operating system on the disk to ensure that the Boot Code occupies only one sector;

4. The reason why operating systems of different vendors are difficult to coexist in the same partition.

 

So, does it mean that the operating systems provided by different manufacturers cannot be installed on the same partition? I think the answer is no. We can use some designs to effectively coordinate the operating systems of different vendors and coexist in the same partition. In the design of the Hello China operating system, a policy called "preset Guide" was adopted, effectively avoiding the above two problems.

The overall idea of the preset boot method is to read the physical location of the core modules of the operating system on the disk in advance according to the actual file system of the hard disk during operating system installation, and directly write the Boot Sector. In this way, when the Boot Sector is guiding the operating system, you no longer need to analyze the file system and determine the location of the core file of the operating system, as long as the pre-set location from the boot sector, find the physical location of the file on the disk and load it into the memory. It can be seen that the preset boot method has one premise: once the core file of the operating system is written to the hard disk, its location cannot be changed. Because the location of the core file on the disk is written to the boot sector. If the file location changes, the file cannot be booted. This is obviously harsh, and it has the same limits as the fixed operating system's location policy on the disk (but the two are fundamentally different, the preset boot method requires that the location of the core file of the operating system remain unchanged on the disk. The location is determined when the file is copied to the disk. The fixed operating system core module requires that the system file be located at a fixed position on the disk, such as starting from 1024 sectors ).

We can use some policies to improve the preset guidance method so that this method can avoid the above limitations. The overall improvement policy is to dynamically generate (or dynamically configure) the content of the boot sector during operating system installation, and write fixed data into the Boot Sector in advance, avoid manually calculating these parameters for the boot sector, thus reducing the amount of code for the Boot Sector. For example, the size of a cluster needs to be calculated for most boot sectors. The specific calculation method is to multiply the number of slices of each cluser by the number of bytes of each sector. Obviously, the cluster size is fixed during operating system installation. Therefore, you can directly set a variable (cluster size) in the boot sector and write the size value of the cluster. In this way, the pilot sector does not need to calculate the cluster size, but can be directly referenced. This method can greatly reduce the amount of code in the boot sector.

The following uses the Hello China operating system boot program as an example to describe the design idea of the preset Boot Method for different file systems.

Implementation of Preset guidance on FAT32 File System

Obviously, the FAT32 file system is a relatively complex file system, and it is difficult to load complete boot code in the space of a boot sector, because even if the core file of the operating system is placed in the root directory, you also need to search the entire root directory, find the operating system file, and load the file. This process requires the amount of code between two slices. However, by preset variables to the boot sector, you can greatly reduce the size of the Boot Sector of the FAT32 file system, so that it can be accommodated in one boot sector. For example, the following figure shows the Standard Guide sector layout:

Field Name field offset field length meaning

BS_jmpBoot 0 3 jump code

BS_OEMName 3 8 OEM name

BPB_BytsPerSec 11 2 length per slice (bytes)

BPB_SecPerClus 13 1 Number of sectors per cluster

BPB_RsvdSecCnt 14 2 Number of reserved sectors

BPB_NumFATs 16 16 1 FAT16 quantity

How many root directories does BPB_RootEntCnt 17 2 have?

BPB_TotSec16 19 2 FAT32 abandoned

BPB_Media 21 1 media type

BPB_FATSz16 22 2 FAT16 File Allocation Table Length

BPB_SecPerTrk 24 2 Number of sectors per track

BPB_NumHeads 26 2 cores

BPB_HiddSec 28 4 hidden sector count

BPB_TotSec32 32 4 Total number of partitions

......

This is the executable boot code.

Obviously, much of this information is useless, especially in the FAT32 file system. For example, BPB_TotSec16 and other variables. When configuring the startup sector, we can omit these variables to free up more space for guiding code, so that the analysis function code of the FAT32 file system can be placed in one sector. The following is the structure of the boot sector after "preset" processing:

; 3-byte jump command

Jmp short _ BOOT_CODE; jump to the real Boot Code

NOP; NULL command to ensure the number of bytes is 3

SectorsPerCluster DB 00; number of sectors of each cluster (1 2 4 8 16 32 64 128)

ReservedSectors DW 00; number of reserved sectors starting from the first slice of the volume;

NumberOfFATs DB 00; number of FAT data structures on the volume. The value is usually 2.

HiddenSectors DD 00; number of hidden sectors before the partition of the FAT volume

SectorsPerFAT32 DD 00; For FAT32, this field contains a FAT size

RootDirectoryStart DD 00; the starting cluster number of the root directory, usually 2;

DriveNumber DB 00; used for INT 0x13 drive letter, 0x00 is a floppy disk, 0x80 is a hard disk

The real executable code will be followed later.

In this way, not only does the preset save about 20 bytes of space, but many variables have been preset (these preset variables are called preset variables) and do not need to be calculated (such as cluster size ). If you follow the traditional Boot Sector, You need to arrange special code to calculate these variable values. In this way, we can save about 60 bytes of space. Do not underestimate the 60 bytes. In the boot sector implemented by the Assembly Language, 60 bytes can be used to analyze FAT32 root directory items, which is the core function of FAT32 Boot Sector.

At the same time, you can optimize the startup sector code and omit unnecessary judgments. For example, the int13 call function. Currently, basically all BIOS provide this function, you do not need to determine whether the BIOS supports int13 call. At the same time, because the operating system runs on a 32-bit CPU, you can increase the data processing range by using 32-bit CPU registers (such as EAX and EBX) and 32-bit instructions, to save the amount of code.

The specific implementation process is to provide a disk analysis tool during the installation of Hello China to read or compute preset variables such as the cluster size, and then write them into the Boot Sector.

After the above measures, Hello China has implemented the function of guiding the operating system on the FAT32 File System in a boot sector. In general, these functions need to be implemented in more than two sectors.

In this way, the core file of the operating system is not required to be fixed on the hard disk. Although some variables are preset, the boot process has not changed. The Boot Sector should first read the root directory and search for the core file of the operating system in the root directory. Find the FAT table, find the location of the core file of the operating system on the disk, and then read it in sequence. Therefore, the loading of the operating system is not affected even if the location of the core file of the operating system is constantly changing. Obviously, this "preset Boot Method" not only overcomes the problem that the Boot Sector of the operating system is too large, but also avoids the disadvantage of fixing the Core File Location of the operating system.

Implementation of Preset guide method on NTFS file system

NTFS is a more complex file system than FAT32. By using the preset boot method, we can barely plug the FAT32 boot code into a single sector, but this is absolutely impossible for NTFS. In MS windows operating systems, there are a total of 16 boot sectors in the NTFS partition (that is, 8 KB of code space is required to guide the operating system files on NTFS ). Therefore, the preset guide method can only be used further.

The most thorough usage of the preset boot method is to write all the locations and distribution of the operating system core files on the disk into the Boot Sector. The boot sector does not have any file system-related analysis code. You can directly read the disk partition based on the written data. For example, the operating system core file storage layout on the disk is as follows:

Number of start sector numbers and sectors

2048 512

4096 512

8000 256

That is, the core file of the operating system is stored in three parts on the disk. the first and second parts occupy 512 consecutive sectors, and the third part occupy 256 consecutive sectors. It can be calculated that the core file size of the operating system is 640 kb. In this case, you can directly write the above table into the Boot Sector. For example, the following code is the start part of the boot sector:

Jmp short _ BOOT_CODE; jump to the real Boot Code

NOP; NULL command to ensure the number of bytes is 3

StartSectNum1 DD 00

SectorCount1 DD 00

StartSectNum2 DD 00

SectorCount2 DD 00

StartSectNum3 DD 00

SectorCount3 DD 00

Then follow the real boot code.

Once the operating system is installed on the NTFS disk partition, the location of the core file of the operating system is fixed (that is, the description in the table above ). At this time, you can use a tool software to read the location information of the core file of the operating system, and then write it to the position of startSectNum and sectorCount in the boot sector. In this way, the real Boot Sector Code does not require any NTFS file system analysis. You only need to read the corresponding sector into the memory according to the information at startSectNum and sectorCount. Obviously, such preset variables and disk read Code cannot exceed 512 bytes.

However, it is obvious that the core file of the operating system must be fixed on the disk. Once the file system moves the location of the core file of the operating system, it cannot be guided. Obviously, this is almost impossible for the NTFS file system. To fully avoid fragmentation, NTFS may regularly scan and fragment the file system, and link discontinuous disk space by moving the specific location of the file on the disk.

To avoid the issue of unguided due to changes in the file location, we need to further write content with a more stable position to the boot sector. To locate more stable content, we first start by analyzing the principles of the NTFS file system. It should be noted that the NTFS file system contains a huge amount of content. Here we will only describe several key concepts. For more information about the NTFS file system, see NTFS file specifications.

In the NTFS file system, the location of any file on the partition is recorded in MFT (main file table. The starting position of the MFT itself is stored in the boot sector. When the operating system processes the NTFS file system, it first obtains the MFT position from the Boot Sector of the NTFS partition and then reads the MFT content. To search for any file, NTFS also searches for MFT based on key fields such as file names (in fact, from the root directory) and finds the corresponding file records, then obtain the storage location of the file on the disk (NTFS is called data running and data run ). Once a file is created or copied to a disk, the NTFS file system code allocates a record in MFT to record the information of the file. For us, the file location information is the most critical. In general, the location of file records in MFT is fixed. At the same time, the location of MFT itself is also fixed (although theoretically, the location of MFT itself can be not fixed, but generally, the location of MFT is fixed for the implementation of NTFS file systems ). Even if the file itself is moved, the NTFS file system code only modifies the MFT record of the file. More specifically, it is the data run attribute in the file record ), the latest file location information in the partition has been reflected.

Therefore, from the above analysis, as long as we pre-place the sector of the MFT record corresponding to the core file of the operating system into the Boot Sector, No problem can be guaranteed. If the operating system core file is moved, the NTFS file system code will modify the corresponding MFT record, and the location of the MFT record will not change.

Based on this principle, the preset guide method on the NTFS file system is pre-embedded with the position of the MFT record corresponding to the core file of the operating system. In this way, as long as the Boot Sector reads the MFT record of the Operating System File Based on the preset position, and then reads the data running (that is, the location information) of the file from the record ), analyze the data and load the operating system file.

The Hello China operating system's boot program on the NTFS file system is implemented in this way. In the Hello China installation program, the installation program first sets the operating system core file (HCNIMGE. BIN) copy to the root directory of the NTFS partition, and then run an NTFS file system analysis tool to read the HCNIMGE. the MFT corresponding to the binfile records the fan area number on the disk, and then writes the fan area number to the preset variable of the boot sector. In this way, when guiding the operating system, you only need to read the HCNIMGE according to the preset disk sector number. BIN corresponding to the file records, and then find the data run according to the file records, analyze the data run, and read it.

Even so, it is difficult to implement the NTFS file system boot program in the 512-byte Boot Sector. The main reason is that the decoding program running data is a little complicated and occupies most of the code space.

Description of the implementation code of the Hello China Bootstrap program

The boot program for FAT32 and NTFS file systems in Hello China V1.69 is implemented through the preset boot method. You can further understand this article by reading the source code of the Bootstrap program. You can download all the code (including the core module code of the Hello China operating system) through the following link:

Http://download.csdn.net/detail/hellochina15/3846735

The source files related to the boot program are described as follows:

1. The Boot Sector Code of FAT32 and NTFS file systems (compiled in assembly language) is stored in the sysinit directory. HDBS. ASM is the Boot Sector Code for the FAT32 file system, while NTFSBS. ASM is the NTFS Boot Sector Code;

2. The Dumpf32 directory stores the FAT32 File System Boot Sector modification program. This program reads information about the installation partition, and then writes it to the Boot Sector Program;

3. The MKNTFSBS directory stores the guide sector modification tool in the NTFS file system. This tool analyzes the root directory of the Hello China installation partition, finds the disk sector number recorded in the file corresponding to HCNIMGE. BIN (core module of the operating system), and writes it to the boot sector. Other preset variables, such as the cluster size, are also written.

If you have any questions, contact him or her.

Http://www.cnblogs.com/roucheng/