{"id":110378,"date":"2024-10-16T07:00:00","date_gmt":"2024-10-16T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110378"},"modified":"2024-10-16T13:01:37","modified_gmt":"2024-10-16T20:01:37","slug":"20241016-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20241016-00\/?p=110378","title":{"rendered":"Effects of classic return address tricks on hardware-assisted return address protection"},"content":{"rendered":"

The x86-32 architecture notoriously does not offer direct access to the instruction pointer, and a common trick is to use call<\/code>\/pop<\/code> to read the instruction pointer.<\/p>\n

    ; read current address into register\r\n    call    @F\r\n@@: pop     eax     ; eax = current address\r\n<\/pre>\n
And since x86-64 does not offer an absolute jump instruction, it is a common trick to use a push<\/code>\/ret<\/code> as a substitute.<\/p>\n
    ; jump to absolute address\r\n    push    0x12345678\r\n    ret             ; jump to 0x12345678\r\n<\/pre>\n
We learned a while back that these unmatched call<\/code>\/ret<\/code> pairs  unbalance the return address predictor<\/a>\u00b9 and end up being net pessimizations.<\/p>\n
And we recently learned that  they also unbalance the hardware shadow stack<\/a>, and the consequences of that are even worse: Instead of merely damaging your performance, this code doesn’t run at all<\/i> because it also unbalances the hardware shadow stack, and an improper return results in an exception.<\/p>\n
In the case of Windows, the kernel receives the exception and checks whether the code performing the invalid ret<\/code> is marked as compatible with return address protection. If so, then any return address protection failure is considered fatal. If not, then the kernel tries to forgive the error by popping entries off the hardware shadow stack until it finds a return address that matches the one popped from the CPU stack. If no match is found, then the failure is treated as fatal.<\/p>\n
If you do a push<\/code>\/ret<\/code>, that return address you pushed is nowhere in the valid return address history, and the kernel will terminate the process.<\/p>\n
If you do a call<\/code>\/pop<\/code>, then you pushed an extra entry onto the shadow stack, and what happens next varies.<\/p>\n
If your function ends with a ret<\/code>, then that ret<\/code> will be mismatched, and the kernel notices that it occurred inside a DLL that is marked as “not CET compatible”, so the kernel will shake its head, “oh man, here’s a weirdo”, and it will look up the stack and find the true return address one entry higher.<\/p>\n
If your function ends with a tail call optimization that jumps to another function, then that other function’s ret<\/code> will be the one that takes the mismatch exception. If that other function is in a DLL that is marked as “CET compatible”, then the kernel will say, “That’s a paddlin’<\/a>” and terminate the process.<\/p>\n
So the push<\/code>\/ret<\/code> pattern results in a guaranteed process termination, whereas the call<\/code>\/pop<\/code> might result in a process termination depending on  how lucky you feel<\/a>.<\/p>\n
(Not recommended.)<\/p>\n
\u00b9 It appears that this specific pattern of call<\/code>\/pop<\/code>  is special-cased inside modern processors<\/a> and does not unbalance the return address predictor stack after all.<\/p>\n","protected":false},"excerpt":{"rendered":"
Return address manipulations that are possibly even more impermissible than they already were.<\/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-110378","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Return address manipulations that are possibly even more impermissible than they already were.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110378","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=110378"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110378\/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=110378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}