\n| garbage<\/td>\n | <- ESP<\/td>\n<\/tr>\n<\/table>\n \nThe function doesn’t really feel any damage yet. The parameters\nare still accessible at the same positive offsets and the local\nvariables are still accessible at the same negative offsets.\n<\/p>\n \nThe real damage doesn’t occur until it’s time to clean up.\nLook at the function epilogue:<\/p>\n \n pop edi ; restore for caller\n pop esi ; restore for caller\n pop ebx ; restore for caller\n mov esp, ebp ; discard locals\n pop ebp ; restore for caller\n retd 8 ; return and clean stack\n<\/pre>\n\nIn a normal stack, the three “pop” instructions match with the\nactual values on the stack and nobody gets hurt. But on the\ngarbage stack, the “pop edi” actually loads garbage into the EDI\nregister, as does the “pop esi”. And the “pop ebx” – which thinks\nit’s restoring the original value of EBX – actually loads the\noriginal value of the EDI register into EBX. But then the\n“mov esp, ebp” instruction fixes the stack back up, so the\n“pop ebp” and “retd” are executed with a repaired stack.\n<\/p>\n \nWhat happened here? Things sort of got put back on their feet.\nWell, except that the ESI, EDI, and EBX registers got corrupted.\nIf you’re lucky, the values in ESI, EDI and EBX weren’t important\nand could have survived corruption. Or all that was important was\nwhether the value was zero or not, and you were lucky and replaced\none nonzero value with another. For whatever reason, the corruption\nof those three registers is not immediately apparent, and you end up\nnever realizing what you did wrong.\n<\/p>\n \nMaybe the corruption has a subtle effect (say, you changed a value\nfrom zero to nonzero, causing the caller to go down the wrong codepath),\nbut it’s subtle enough that you don’t notice, so you ship it,\nthrow a party, and start the next project.\n<\/p>\n \nBut then a new compiler comes along, say one that does FPO optimization.\n<\/p>\n \nFPO stands for “frame pointer omission”; the function dispenses with the\nEBP register as a frame register and instead just uses it like any other\nregister. On the x86,\n\nwhich has comparatively few registers<\/a>, an extra\narithmetic register goes a long way.\n<\/p>\n\nWith FPO, the function prologue goes like this:<\/p>\n \n sub esp, nn*4 ; local variables\n push ebp ; must be preserved for caller\n push ebx ; must be preserved for caller\n push esi ; must be preserved for caller\n push edi ; must be preserved for caller\n<\/pre>\nThe resulting stack frame looks like this:<\/p>\n \n\n\n| .. rest of stack ..<\/td>\n | <\/td>\n<\/tr>\n | \n| param2<\/td>\n | <\/td>\n<\/tr>\n | \n| param1<\/td>\n | <\/td>\n<\/tr>\n | \n| return address<\/td>\n | <\/td>\n<\/tr>\n | \n| local1<\/td>\n | <\/td>\n<\/tr>\n | \n| local2<\/td>\n | <\/td>\n<\/tr>\n | \n| …<\/td>\n | <\/td>\n<\/tr>\n | \n| local-nn<\/td>\n | <\/td>\n<\/tr>\n | \n| saved EBP<\/td>\n | <\/td>\n<\/tr>\n | \n| saved EBX<\/td>\n | <\/td>\n<\/tr>\n | \n| saved ESI<\/td>\n | <\/td>\n<\/tr>\n | \n| saved EDI<\/td>\n | <- ESP<\/td>\n<\/tr>\n<\/table>\n \nEverything is now accessed relative to the ESP register.\nFor example, local-nn is [esp+0x10].\n<\/p>\n \nUnder these conditions, garbage on the stack is much more fatal.\nThe function epilogue goes like this:<\/p>\n \n pop edi ; restore for caller\n pop esi ; restore for caller\n pop ebx ; restore for caller\n pop ebp ; restore for caller\n add esp, nn*4 ; discard locals\n retd 8 ; return and clean stack\n<\/pre>\n\nIf there is garbage on the stack, the four “pop” instructions will\nrestore the wrong values, as before, but this time, the cleanup of\nlocal variables won’t fix anything.\nThe “add esp, nn*4” will adjust the stack by what the function believes\nto be the correct amount, but since there was garbage on the stack,\nthe stack pointer will be off.<\/p>\n \n\n\n| .. rest of stack ..<\/td>\n | <\/td>\n<\/tr>\n | \n| param2<\/td>\n | <\/td>\n<\/tr>\n | \n| param1<\/td>\n | <\/td>\n<\/tr>\n | \n| return address<\/td>\n | <\/td>\n<\/tr>\n | \n| local1<\/td>\n | <\/td>\n<\/tr>\n | \n| local2<\/td>\n | <- ESP (oops)<\/td>\n<\/tr>\n<\/table>\n \nThe “retd 8” instruction now attempts to return to the caller,\nbut instead it returns to whatever is in local2, which is probably\nnot valid code.\n<\/p>\n \nSo this is an example of where optimizing your code reveals\nother people’s bugs.\n<\/p>\n \nMonday, I’ll give a much more subtle example of something\nthat can go wrong if you use the wrong function signature for a\ncallback.<\/p>\n","protected":false},"excerpt":{"rendered":" Continuing from yesterday: The x86 architecture traditionally uses the EBP register to establish a stack frame. A typical function prologue goes like this: push ebp ; save old ebp mov ebp, esp ; establish new ebp sub esp, nn*4 ; local variables push ebx ; must be preserved for caller push esi ; must be […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-41023","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" Continuing from yesterday: The x86 architecture traditionally uses the EBP register to establish a stack frame. A typical function prologue goes like this: push ebp ; save old ebp mov ebp, esp ; establish new ebp sub esp, nn*4 ; local variables push ebx ; must be preserved for caller push esi ; must be […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/41023","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=41023"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/41023\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=41023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=41023"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=41023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} | | |