the sub x86-instruction question
Assume that we have the following c code
void fun(void){
printf("this is funn");
}
Then, we compile it with debug mode, we get the following disassemble code:
push ebp
mov ebp,esp
sub esp, 0xc0
...
Ok,we just discuss:
sub esp, 0xc0
My question is: why is the default value here 0xc0
, not the other value, such as 0xF0
, 0xFF
… and so on?
x86
migrated from unix.stackexchange.com Dec 18 at 11:09
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
add a comment |
Assume that we have the following c code
void fun(void){
printf("this is funn");
}
Then, we compile it with debug mode, we get the following disassemble code:
push ebp
mov ebp,esp
sub esp, 0xc0
...
Ok,we just discuss:
sub esp, 0xc0
My question is: why is the default value here 0xc0
, not the other value, such as 0xF0
, 0xFF
… and so on?
x86
migrated from unix.stackexchange.com Dec 18 at 11:09
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
There is nothing here that is actually specific to Unix and Linux.
– JdeBP
Dec 18 at 10:17
Where do you get0xf0
from?
– ctrl-alt-delor
Dec 18 at 10:30
Assuming that disassembly uses Intel syntax and I understood it correctly, the disassembly stores the previous value of the EBP register to the stack, copies the stack pointer to EBP, and then decrements the stack pointer by 0xc0, effectively allocating 192 bytes of stack space as some temporary storage area. Why 192? Probably because the routine that follows will only need exactly that much at maximum!
– telcoM
Dec 18 at 10:46
2
@telcoM yes, it’s a standard stack frame setup, but the 0xC0 value isn’t easy to explain (I get 8 with my GCC). Stack guards perhaps (red zones etc.)? The difficult part is guessing what “compile it with debug mode” means in terms of an actual compiler command.
– Stephen Kitt
Dec 18 at 10:59
@StephenKitt: Only x86-64 System V has a red-zone, out of any standard x86 calling convention. Unless this is x32 (32-bit pointers in long mode), code usingesp
doesn't have a red zone. Besides that, a red zone means you don't have tosub rsp, anything
to reserve space in a leaf function, because you can simply use space below the stack pointer and be guaranteed that it won't be asynchronously clobbered. I wondered if0xc0
is a typo for0x0c
, but that wouldn't make sense afterpush ebp
. We only need 8 more bytes to re-align the stack by 16 before acall
.
– Peter Cordes
Dec 18 at 20:25
add a comment |
Assume that we have the following c code
void fun(void){
printf("this is funn");
}
Then, we compile it with debug mode, we get the following disassemble code:
push ebp
mov ebp,esp
sub esp, 0xc0
...
Ok,we just discuss:
sub esp, 0xc0
My question is: why is the default value here 0xc0
, not the other value, such as 0xF0
, 0xFF
… and so on?
x86
Assume that we have the following c code
void fun(void){
printf("this is funn");
}
Then, we compile it with debug mode, we get the following disassemble code:
push ebp
mov ebp,esp
sub esp, 0xc0
...
Ok,we just discuss:
sub esp, 0xc0
My question is: why is the default value here 0xc0
, not the other value, such as 0xF0
, 0xFF
… and so on?
x86
x86
asked Dec 18 at 10:04
user327399
migrated from unix.stackexchange.com Dec 18 at 11:09
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
migrated from unix.stackexchange.com Dec 18 at 11:09
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
There is nothing here that is actually specific to Unix and Linux.
– JdeBP
Dec 18 at 10:17
Where do you get0xf0
from?
– ctrl-alt-delor
Dec 18 at 10:30
Assuming that disassembly uses Intel syntax and I understood it correctly, the disassembly stores the previous value of the EBP register to the stack, copies the stack pointer to EBP, and then decrements the stack pointer by 0xc0, effectively allocating 192 bytes of stack space as some temporary storage area. Why 192? Probably because the routine that follows will only need exactly that much at maximum!
– telcoM
Dec 18 at 10:46
2
@telcoM yes, it’s a standard stack frame setup, but the 0xC0 value isn’t easy to explain (I get 8 with my GCC). Stack guards perhaps (red zones etc.)? The difficult part is guessing what “compile it with debug mode” means in terms of an actual compiler command.
– Stephen Kitt
Dec 18 at 10:59
@StephenKitt: Only x86-64 System V has a red-zone, out of any standard x86 calling convention. Unless this is x32 (32-bit pointers in long mode), code usingesp
doesn't have a red zone. Besides that, a red zone means you don't have tosub rsp, anything
to reserve space in a leaf function, because you can simply use space below the stack pointer and be guaranteed that it won't be asynchronously clobbered. I wondered if0xc0
is a typo for0x0c
, but that wouldn't make sense afterpush ebp
. We only need 8 more bytes to re-align the stack by 16 before acall
.
– Peter Cordes
Dec 18 at 20:25
add a comment |
There is nothing here that is actually specific to Unix and Linux.
– JdeBP
Dec 18 at 10:17
Where do you get0xf0
from?
– ctrl-alt-delor
Dec 18 at 10:30
Assuming that disassembly uses Intel syntax and I understood it correctly, the disassembly stores the previous value of the EBP register to the stack, copies the stack pointer to EBP, and then decrements the stack pointer by 0xc0, effectively allocating 192 bytes of stack space as some temporary storage area. Why 192? Probably because the routine that follows will only need exactly that much at maximum!
– telcoM
Dec 18 at 10:46
2
@telcoM yes, it’s a standard stack frame setup, but the 0xC0 value isn’t easy to explain (I get 8 with my GCC). Stack guards perhaps (red zones etc.)? The difficult part is guessing what “compile it with debug mode” means in terms of an actual compiler command.
– Stephen Kitt
Dec 18 at 10:59
@StephenKitt: Only x86-64 System V has a red-zone, out of any standard x86 calling convention. Unless this is x32 (32-bit pointers in long mode), code usingesp
doesn't have a red zone. Besides that, a red zone means you don't have tosub rsp, anything
to reserve space in a leaf function, because you can simply use space below the stack pointer and be guaranteed that it won't be asynchronously clobbered. I wondered if0xc0
is a typo for0x0c
, but that wouldn't make sense afterpush ebp
. We only need 8 more bytes to re-align the stack by 16 before acall
.
– Peter Cordes
Dec 18 at 20:25
There is nothing here that is actually specific to Unix and Linux.
– JdeBP
Dec 18 at 10:17
There is nothing here that is actually specific to Unix and Linux.
– JdeBP
Dec 18 at 10:17
Where do you get
0xf0
from?– ctrl-alt-delor
Dec 18 at 10:30
Where do you get
0xf0
from?– ctrl-alt-delor
Dec 18 at 10:30
Assuming that disassembly uses Intel syntax and I understood it correctly, the disassembly stores the previous value of the EBP register to the stack, copies the stack pointer to EBP, and then decrements the stack pointer by 0xc0, effectively allocating 192 bytes of stack space as some temporary storage area. Why 192? Probably because the routine that follows will only need exactly that much at maximum!
– telcoM
Dec 18 at 10:46
Assuming that disassembly uses Intel syntax and I understood it correctly, the disassembly stores the previous value of the EBP register to the stack, copies the stack pointer to EBP, and then decrements the stack pointer by 0xc0, effectively allocating 192 bytes of stack space as some temporary storage area. Why 192? Probably because the routine that follows will only need exactly that much at maximum!
– telcoM
Dec 18 at 10:46
2
2
@telcoM yes, it’s a standard stack frame setup, but the 0xC0 value isn’t easy to explain (I get 8 with my GCC). Stack guards perhaps (red zones etc.)? The difficult part is guessing what “compile it with debug mode” means in terms of an actual compiler command.
– Stephen Kitt
Dec 18 at 10:59
@telcoM yes, it’s a standard stack frame setup, but the 0xC0 value isn’t easy to explain (I get 8 with my GCC). Stack guards perhaps (red zones etc.)? The difficult part is guessing what “compile it with debug mode” means in terms of an actual compiler command.
– Stephen Kitt
Dec 18 at 10:59
@StephenKitt: Only x86-64 System V has a red-zone, out of any standard x86 calling convention. Unless this is x32 (32-bit pointers in long mode), code using
esp
doesn't have a red zone. Besides that, a red zone means you don't have to sub rsp, anything
to reserve space in a leaf function, because you can simply use space below the stack pointer and be guaranteed that it won't be asynchronously clobbered. I wondered if 0xc0
is a typo for 0x0c
, but that wouldn't make sense after push ebp
. We only need 8 more bytes to re-align the stack by 16 before a call
.– Peter Cordes
Dec 18 at 20:25
@StephenKitt: Only x86-64 System V has a red-zone, out of any standard x86 calling convention. Unless this is x32 (32-bit pointers in long mode), code using
esp
doesn't have a red zone. Besides that, a red zone means you don't have to sub rsp, anything
to reserve space in a leaf function, because you can simply use space below the stack pointer and be guaranteed that it won't be asynchronously clobbered. I wondered if 0xc0
is a typo for 0x0c
, but that wouldn't make sense after push ebp
. We only need 8 more bytes to re-align the stack by 16 before a call
.– Peter Cordes
Dec 18 at 20:25
add a comment |
1 Answer
1
active
oldest
votes
This is a standard stack frame setup, saving the stack pointer then using EBP for indexing. The amount subtracted from ESP is what is allocated for the procedure's local variable storage, and local variables will be accessed by referencing [EBP-??].
Without seeing the code for your procedure it is difficult to say why it allocates that much storage. There is no default value used by the compiler, it always allocates exactly what is needed. It can do this because local variables types must be explicitly declared, and the compiler knows how much space is used by each type. There is no randomness or uncertainty in it, and no benefit to allocating extra storage. I also can't see how randomizing the local variable storage size would prevent any kind of stack-based attack. Most modern processors have hardware data execution prevention measures in place, making these attacks impossible anyway.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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%2fstackoverflow.com%2fquestions%2f53831736%2fthe-sub-x86-instruction-question%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a standard stack frame setup, saving the stack pointer then using EBP for indexing. The amount subtracted from ESP is what is allocated for the procedure's local variable storage, and local variables will be accessed by referencing [EBP-??].
Without seeing the code for your procedure it is difficult to say why it allocates that much storage. There is no default value used by the compiler, it always allocates exactly what is needed. It can do this because local variables types must be explicitly declared, and the compiler knows how much space is used by each type. There is no randomness or uncertainty in it, and no benefit to allocating extra storage. I also can't see how randomizing the local variable storage size would prevent any kind of stack-based attack. Most modern processors have hardware data execution prevention measures in place, making these attacks impossible anyway.
add a comment |
This is a standard stack frame setup, saving the stack pointer then using EBP for indexing. The amount subtracted from ESP is what is allocated for the procedure's local variable storage, and local variables will be accessed by referencing [EBP-??].
Without seeing the code for your procedure it is difficult to say why it allocates that much storage. There is no default value used by the compiler, it always allocates exactly what is needed. It can do this because local variables types must be explicitly declared, and the compiler knows how much space is used by each type. There is no randomness or uncertainty in it, and no benefit to allocating extra storage. I also can't see how randomizing the local variable storage size would prevent any kind of stack-based attack. Most modern processors have hardware data execution prevention measures in place, making these attacks impossible anyway.
add a comment |
This is a standard stack frame setup, saving the stack pointer then using EBP for indexing. The amount subtracted from ESP is what is allocated for the procedure's local variable storage, and local variables will be accessed by referencing [EBP-??].
Without seeing the code for your procedure it is difficult to say why it allocates that much storage. There is no default value used by the compiler, it always allocates exactly what is needed. It can do this because local variables types must be explicitly declared, and the compiler knows how much space is used by each type. There is no randomness or uncertainty in it, and no benefit to allocating extra storage. I also can't see how randomizing the local variable storage size would prevent any kind of stack-based attack. Most modern processors have hardware data execution prevention measures in place, making these attacks impossible anyway.
This is a standard stack frame setup, saving the stack pointer then using EBP for indexing. The amount subtracted from ESP is what is allocated for the procedure's local variable storage, and local variables will be accessed by referencing [EBP-??].
Without seeing the code for your procedure it is difficult to say why it allocates that much storage. There is no default value used by the compiler, it always allocates exactly what is needed. It can do this because local variables types must be explicitly declared, and the compiler knows how much space is used by each type. There is no randomness or uncertainty in it, and no benefit to allocating extra storage. I also can't see how randomizing the local variable storage size would prevent any kind of stack-based attack. Most modern processors have hardware data execution prevention measures in place, making these attacks impossible anyway.
answered Dec 18 at 11:43
Craig Parton
887
887
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fstackoverflow.com%2fquestions%2f53831736%2fthe-sub-x86-instruction-question%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
There is nothing here that is actually specific to Unix and Linux.
– JdeBP
Dec 18 at 10:17
Where do you get
0xf0
from?– ctrl-alt-delor
Dec 18 at 10:30
Assuming that disassembly uses Intel syntax and I understood it correctly, the disassembly stores the previous value of the EBP register to the stack, copies the stack pointer to EBP, and then decrements the stack pointer by 0xc0, effectively allocating 192 bytes of stack space as some temporary storage area. Why 192? Probably because the routine that follows will only need exactly that much at maximum!
– telcoM
Dec 18 at 10:46
2
@telcoM yes, it’s a standard stack frame setup, but the 0xC0 value isn’t easy to explain (I get 8 with my GCC). Stack guards perhaps (red zones etc.)? The difficult part is guessing what “compile it with debug mode” means in terms of an actual compiler command.
– Stephen Kitt
Dec 18 at 10:59
@StephenKitt: Only x86-64 System V has a red-zone, out of any standard x86 calling convention. Unless this is x32 (32-bit pointers in long mode), code using
esp
doesn't have a red zone. Besides that, a red zone means you don't have tosub rsp, anything
to reserve space in a leaf function, because you can simply use space below the stack pointer and be guaranteed that it won't be asynchronously clobbered. I wondered if0xc0
is a typo for0x0c
, but that wouldn't make sense afterpush ebp
. We only need 8 more bytes to re-align the stack by 16 before acall
.– Peter Cordes
Dec 18 at 20:25