What mode do modern 64-bit Intel chip PCs run the boot sector in?
I know with older machines like 286s, the first 512 bytes loaded from the first sector of the boot drive to 0000:7C00 in memory were run in 16-bit real mode, but what about modern 64-bit architectures?
Edit: I guess this is a wrong question upon thinking about it. The writer of the boot loader is the decider of which mode assembly instructions to use, right? The hardware just does what it's told. Then my question should be, what mode do major OS boot loaders like Windows 7, Mac OS X (the latest) and GRUB on 64-bit machines use?
boot 64-bit mode
add a comment |
I know with older machines like 286s, the first 512 bytes loaded from the first sector of the boot drive to 0000:7C00 in memory were run in 16-bit real mode, but what about modern 64-bit architectures?
Edit: I guess this is a wrong question upon thinking about it. The writer of the boot loader is the decider of which mode assembly instructions to use, right? The hardware just does what it's told. Then my question should be, what mode do major OS boot loaders like Windows 7, Mac OS X (the latest) and GRUB on 64-bit machines use?
boot 64-bit mode
add a comment |
I know with older machines like 286s, the first 512 bytes loaded from the first sector of the boot drive to 0000:7C00 in memory were run in 16-bit real mode, but what about modern 64-bit architectures?
Edit: I guess this is a wrong question upon thinking about it. The writer of the boot loader is the decider of which mode assembly instructions to use, right? The hardware just does what it's told. Then my question should be, what mode do major OS boot loaders like Windows 7, Mac OS X (the latest) and GRUB on 64-bit machines use?
boot 64-bit mode
I know with older machines like 286s, the first 512 bytes loaded from the first sector of the boot drive to 0000:7C00 in memory were run in 16-bit real mode, but what about modern 64-bit architectures?
Edit: I guess this is a wrong question upon thinking about it. The writer of the boot loader is the decider of which mode assembly instructions to use, right? The hardware just does what it's told. Then my question should be, what mode do major OS boot loaders like Windows 7, Mac OS X (the latest) and GRUB on 64-bit machines use?
boot 64-bit mode
boot 64-bit mode
edited Oct 10 '11 at 13:34
mring
asked Oct 10 '11 at 13:28
mringmring
492719
492719
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
All current x86-compatible computers (this includes x64 architecture too, both from Intel and AMD, but not Itanium) execute boot sector code in x86 real mode, exactly like the original IBM PC did 20+ years ago. It is not kernel mode, it's the original segmented mode without memory protection, multitasking, or code privilege levels.
If you can get hold of a floppy drive, put MS-DOS (or FreeDOS) on it, and stuck into today's computer, it will start booting.
It is boot code's task to switch into protected mode, set up memory protection etc. So your guess is partially right. The boot loader starts execution as x86 real mode and switches into protected mode, loads and starts actually executing OS Kernel in "kernel" (ring 0) mode.
For more information, you can visit Wikipedia article on Windows NT startup process, which has quite a few details on this subject.
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
add a comment |
what about modern 64-bit architectures?
That depends from the firmware that is on the modern 64-bit machine with the modern 64-bit architecture. haimg's answer would have been the case some five to six years ago for the x86 world, but is out of date for the x86 world today.
Old PC/AT firmwares
Some of those modern 64-bit machines have old PC/AT style firmwares. As noted in other answers, they load and run the bootstrap program from sector #0 of a disc in pretty much the same way as the PC/AT did. This is the old PC/AT bootstrap process.
New EFI firmwares
Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.
EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)
As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
1
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
add a comment |
As far as I know, the boot code always runs in Kernel mode.
For one, it's impossible for anything to decide what mode to use as it's ran from the boot sector, simply because it's the first instructions to be executed by the firmware. There is no way for the code to set what instructions are available to it before it starts running. Thus, by design, the assembly set available for the code on the boot sector is predetermined by the architecture.
Had any underprivileged mode were to be chosen for that, it would have been impossible to ever use instructions from higher privileged modes, which pretty much forces the fact that the boot code runs with the most privileged mode available.
add a comment |
Intel manual Volume 3 System Programming Guide 325384-053US January 2015:
2.2 MODES OF OPERATION
The processor is placed in real-address mode following power-up or a reset.
Just for the kicks, a nice diagram from the manual:

GRUB starts multiboot OSes in protected mode. Multiboot specification 0.6.96 Machine state:
'CR0' Bit 0 (PE) must be set.
Not sure about GRUB and x86_64.
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses themultibootkeyword; for Linux, there are dedicatedlinux,linux16and, in UEFI versions of GRUB,linuxefikeywords, telling GRUB to use a Linux-specific boot protocol.
– telcoM
Dec 16 '18 at 11:36
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f344954%2fwhat-mode-do-modern-64-bit-intel-chip-pcs-run-the-boot-sector-in%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
All current x86-compatible computers (this includes x64 architecture too, both from Intel and AMD, but not Itanium) execute boot sector code in x86 real mode, exactly like the original IBM PC did 20+ years ago. It is not kernel mode, it's the original segmented mode without memory protection, multitasking, or code privilege levels.
If you can get hold of a floppy drive, put MS-DOS (or FreeDOS) on it, and stuck into today's computer, it will start booting.
It is boot code's task to switch into protected mode, set up memory protection etc. So your guess is partially right. The boot loader starts execution as x86 real mode and switches into protected mode, loads and starts actually executing OS Kernel in "kernel" (ring 0) mode.
For more information, you can visit Wikipedia article on Windows NT startup process, which has quite a few details on this subject.
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
add a comment |
All current x86-compatible computers (this includes x64 architecture too, both from Intel and AMD, but not Itanium) execute boot sector code in x86 real mode, exactly like the original IBM PC did 20+ years ago. It is not kernel mode, it's the original segmented mode without memory protection, multitasking, or code privilege levels.
If you can get hold of a floppy drive, put MS-DOS (or FreeDOS) on it, and stuck into today's computer, it will start booting.
It is boot code's task to switch into protected mode, set up memory protection etc. So your guess is partially right. The boot loader starts execution as x86 real mode and switches into protected mode, loads and starts actually executing OS Kernel in "kernel" (ring 0) mode.
For more information, you can visit Wikipedia article on Windows NT startup process, which has quite a few details on this subject.
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
add a comment |
All current x86-compatible computers (this includes x64 architecture too, both from Intel and AMD, but not Itanium) execute boot sector code in x86 real mode, exactly like the original IBM PC did 20+ years ago. It is not kernel mode, it's the original segmented mode without memory protection, multitasking, or code privilege levels.
If you can get hold of a floppy drive, put MS-DOS (or FreeDOS) on it, and stuck into today's computer, it will start booting.
It is boot code's task to switch into protected mode, set up memory protection etc. So your guess is partially right. The boot loader starts execution as x86 real mode and switches into protected mode, loads and starts actually executing OS Kernel in "kernel" (ring 0) mode.
For more information, you can visit Wikipedia article on Windows NT startup process, which has quite a few details on this subject.
All current x86-compatible computers (this includes x64 architecture too, both from Intel and AMD, but not Itanium) execute boot sector code in x86 real mode, exactly like the original IBM PC did 20+ years ago. It is not kernel mode, it's the original segmented mode without memory protection, multitasking, or code privilege levels.
If you can get hold of a floppy drive, put MS-DOS (or FreeDOS) on it, and stuck into today's computer, it will start booting.
It is boot code's task to switch into protected mode, set up memory protection etc. So your guess is partially right. The boot loader starts execution as x86 real mode and switches into protected mode, loads and starts actually executing OS Kernel in "kernel" (ring 0) mode.
For more information, you can visit Wikipedia article on Windows NT startup process, which has quite a few details on this subject.
edited Mar 21 '17 at 17:17
unforgettableid
6532926
6532926
answered Oct 10 '11 at 17:02
haimghaimg
16.8k1670110
16.8k1670110
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
add a comment |
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
– mring
Oct 10 '11 at 17:11
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
Now's the time to edit this, otherwise you disagree with your own answer :-)
– Daniel Beck♦
Oct 10 '11 at 17:14
add a comment |
what about modern 64-bit architectures?
That depends from the firmware that is on the modern 64-bit machine with the modern 64-bit architecture. haimg's answer would have been the case some five to six years ago for the x86 world, but is out of date for the x86 world today.
Old PC/AT firmwares
Some of those modern 64-bit machines have old PC/AT style firmwares. As noted in other answers, they load and run the bootstrap program from sector #0 of a disc in pretty much the same way as the PC/AT did. This is the old PC/AT bootstrap process.
New EFI firmwares
Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.
EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)
As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
1
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
add a comment |
what about modern 64-bit architectures?
That depends from the firmware that is on the modern 64-bit machine with the modern 64-bit architecture. haimg's answer would have been the case some five to six years ago for the x86 world, but is out of date for the x86 world today.
Old PC/AT firmwares
Some of those modern 64-bit machines have old PC/AT style firmwares. As noted in other answers, they load and run the bootstrap program from sector #0 of a disc in pretty much the same way as the PC/AT did. This is the old PC/AT bootstrap process.
New EFI firmwares
Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.
EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)
As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
1
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
add a comment |
what about modern 64-bit architectures?
That depends from the firmware that is on the modern 64-bit machine with the modern 64-bit architecture. haimg's answer would have been the case some five to six years ago for the x86 world, but is out of date for the x86 world today.
Old PC/AT firmwares
Some of those modern 64-bit machines have old PC/AT style firmwares. As noted in other answers, they load and run the bootstrap program from sector #0 of a disc in pretty much the same way as the PC/AT did. This is the old PC/AT bootstrap process.
New EFI firmwares
Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.
EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)
As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.
what about modern 64-bit architectures?
That depends from the firmware that is on the modern 64-bit machine with the modern 64-bit architecture. haimg's answer would have been the case some five to six years ago for the x86 world, but is out of date for the x86 world today.
Old PC/AT firmwares
Some of those modern 64-bit machines have old PC/AT style firmwares. As noted in other answers, they load and run the bootstrap program from sector #0 of a disc in pretty much the same way as the PC/AT did. This is the old PC/AT bootstrap process.
New EFI firmwares
Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.
EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)
As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.
edited Aug 17 '18 at 13:21
answered Oct 11 '11 at 14:13
JdeBPJdeBP
22.5k14890
22.5k14890
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
1
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
add a comment |
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
1
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
– slm
Aug 17 '18 at 13:07
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
This yours? - jdebp.eu/FGA/pcat-boot-process.html
– slm
Aug 17 '18 at 13:08
1
1
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
– slm
Aug 17 '18 at 13:09
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
I think you moved things from ntlworld, is that correct?
– slm
Aug 17 '18 at 13:12
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
– slm
Aug 17 '18 at 13:15
add a comment |
As far as I know, the boot code always runs in Kernel mode.
For one, it's impossible for anything to decide what mode to use as it's ran from the boot sector, simply because it's the first instructions to be executed by the firmware. There is no way for the code to set what instructions are available to it before it starts running. Thus, by design, the assembly set available for the code on the boot sector is predetermined by the architecture.
Had any underprivileged mode were to be chosen for that, it would have been impossible to ever use instructions from higher privileged modes, which pretty much forces the fact that the boot code runs with the most privileged mode available.
add a comment |
As far as I know, the boot code always runs in Kernel mode.
For one, it's impossible for anything to decide what mode to use as it's ran from the boot sector, simply because it's the first instructions to be executed by the firmware. There is no way for the code to set what instructions are available to it before it starts running. Thus, by design, the assembly set available for the code on the boot sector is predetermined by the architecture.
Had any underprivileged mode were to be chosen for that, it would have been impossible to ever use instructions from higher privileged modes, which pretty much forces the fact that the boot code runs with the most privileged mode available.
add a comment |
As far as I know, the boot code always runs in Kernel mode.
For one, it's impossible for anything to decide what mode to use as it's ran from the boot sector, simply because it's the first instructions to be executed by the firmware. There is no way for the code to set what instructions are available to it before it starts running. Thus, by design, the assembly set available for the code on the boot sector is predetermined by the architecture.
Had any underprivileged mode were to be chosen for that, it would have been impossible to ever use instructions from higher privileged modes, which pretty much forces the fact that the boot code runs with the most privileged mode available.
As far as I know, the boot code always runs in Kernel mode.
For one, it's impossible for anything to decide what mode to use as it's ran from the boot sector, simply because it's the first instructions to be executed by the firmware. There is no way for the code to set what instructions are available to it before it starts running. Thus, by design, the assembly set available for the code on the boot sector is predetermined by the architecture.
Had any underprivileged mode were to be chosen for that, it would have been impossible to ever use instructions from higher privileged modes, which pretty much forces the fact that the boot code runs with the most privileged mode available.
answered Oct 10 '11 at 14:57
DesheDeshe
271
271
add a comment |
add a comment |
Intel manual Volume 3 System Programming Guide 325384-053US January 2015:
2.2 MODES OF OPERATION
The processor is placed in real-address mode following power-up or a reset.
Just for the kicks, a nice diagram from the manual:

GRUB starts multiboot OSes in protected mode. Multiboot specification 0.6.96 Machine state:
'CR0' Bit 0 (PE) must be set.
Not sure about GRUB and x86_64.
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses themultibootkeyword; for Linux, there are dedicatedlinux,linux16and, in UEFI versions of GRUB,linuxefikeywords, telling GRUB to use a Linux-specific boot protocol.
– telcoM
Dec 16 '18 at 11:36
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
add a comment |
Intel manual Volume 3 System Programming Guide 325384-053US January 2015:
2.2 MODES OF OPERATION
The processor is placed in real-address mode following power-up or a reset.
Just for the kicks, a nice diagram from the manual:

GRUB starts multiboot OSes in protected mode. Multiboot specification 0.6.96 Machine state:
'CR0' Bit 0 (PE) must be set.
Not sure about GRUB and x86_64.
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses themultibootkeyword; for Linux, there are dedicatedlinux,linux16and, in UEFI versions of GRUB,linuxefikeywords, telling GRUB to use a Linux-specific boot protocol.
– telcoM
Dec 16 '18 at 11:36
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
add a comment |
Intel manual Volume 3 System Programming Guide 325384-053US January 2015:
2.2 MODES OF OPERATION
The processor is placed in real-address mode following power-up or a reset.
Just for the kicks, a nice diagram from the manual:

GRUB starts multiboot OSes in protected mode. Multiboot specification 0.6.96 Machine state:
'CR0' Bit 0 (PE) must be set.
Not sure about GRUB and x86_64.
Intel manual Volume 3 System Programming Guide 325384-053US January 2015:
2.2 MODES OF OPERATION
The processor is placed in real-address mode following power-up or a reset.
Just for the kicks, a nice diagram from the manual:

GRUB starts multiboot OSes in protected mode. Multiboot specification 0.6.96 Machine state:
'CR0' Bit 0 (PE) must be set.
Not sure about GRUB and x86_64.
edited Dec 16 '18 at 11:44
answered Oct 3 '15 at 15:51
Ciro Santilli 新疆改造中心 六四事件 法轮功Ciro Santilli 新疆改造中心 六四事件 法轮功
3,91622734
3,91622734
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses themultibootkeyword; for Linux, there are dedicatedlinux,linux16and, in UEFI versions of GRUB,linuxefikeywords, telling GRUB to use a Linux-specific boot protocol.
– telcoM
Dec 16 '18 at 11:36
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
add a comment |
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses themultibootkeyword; for Linux, there are dedicatedlinux,linux16and, in UEFI versions of GRUB,linuxefikeywords, telling GRUB to use a Linux-specific boot protocol.
– telcoM
Dec 16 '18 at 11:36
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses the
multiboot keyword; for Linux, there are dedicated linux, linux16 and, in UEFI versions of GRUB, linuxefi keywords, telling GRUB to use a Linux-specific boot protocol.– telcoM
Dec 16 '18 at 11:36
GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses the
multiboot keyword; for Linux, there are dedicated linux, linux16 and, in UEFI versions of GRUB, linuxefi keywords, telling GRUB to use a Linux-specific boot protocol.– telcoM
Dec 16 '18 at 11:36
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
@telcoM fair enough
– Ciro Santilli 新疆改造中心 六四事件 法轮功
Dec 16 '18 at 11:44
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f344954%2fwhat-mode-do-modern-64-bit-intel-chip-pcs-run-the-boot-sector-in%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown