[MS] Why don't we just make the entire stack out of guard pages? - devamazonaws.blogspot.com

In my earlier overview of how compilers on different architectures perform stack probes, Cole Tobin asked, "Why not have a page fault handler that detects the faulting address being the stack and page in the other pages?"

Csaba Varga replied, "My guess: you don't want an invalid pointer dereference to allocate a huge chunk of stack, just because the pointer happens to be pointing where the stack might grow, eventually. You want an invalid pointer dereference to segfault most of the time."

I agree with Csaba on this.

If the entire stack were made of guard pages, then it means that a single page fault far below the stack limit could take arbitrary long and allocate arbitrarily large quantities of memory. The program might have said that it wants stacks to default to 1GB, and now a single page fault on the stack could result in a long pause as the system allocates 1GB of memory. If you study the problem in the debugger, what you see is that a single memory read takes several minutes.

And even worse is that there's no way to stop it, since it's happening in kernel mode. You see a program starting to balloon and consume all the memory in the system, so you go to Task Manager and terminate it, but the process doesn't die. It just keeps on growing!

Even if the guard page is more than one page, it's still a small fixed number of pages, the system can satisfy a guard page fault in a short amount of time. And more importantly, the amount of work is bounded.


Post Updated on July 13, 2026 at 03:00PM
Thanks for reading
from devamazonaws.blogspot.com

Comments

Post a Comment

Popular posts from this blog

[MS] Pulling a single item from a C++ parameter pack by its index, remarks - devamazonaws.blogspot.com

In my earlier discussion of pulling a single item from a C++ parameter pack by its index , I noted that with the Pack Indexing proposal, you would be able to write this to pull an item from a parameter pack while preserving its reference category. template<int index, typename...Args> void example(Args&&... args) { auto&& arg = (Args...[index]&&)args...[index]; using Arg = Args...[index]&&; } Why did I need to apply the (Args...[index]&&) cast ? Why can't I just write this: auto&& arg = args...[index]; or possibly decltype(auto) arg = args...[index]; Well, when you write the name of a variable, the result is an lvalue reference, even if the variable is an rvalue reference . Watch: struct S { S(S&); // construct from lvalue S(S&&); // construct from rvalue }; void whathappens(S&& s) { S t = s; // which will it use? } Try it out in your favorite compiler. This code construc...
Read more

[MS] Boosting Azure DevOps Security with GHAS Code Scanning - devamazonaws.blogspot.com

Image
Debjyoti Ganguly shares insights on the security benefits and configuration of GHAS Code Scanning with Azure DevOps. Boosting Azure DevOps Security with GHAS Code Scanning Code scanning, a pipeline-based tool available in GitHub Advanced Security, is designed to detect code vulnerabilities and bugs within the source code of ADO (Azure DevOps) repositories. Utilizing CodeQL as a static analysis tool, it performs query analysis and variant analysis. When vulnerabilities are found, it generates security alerts. CodeQL CodeQL is a powerful static analysis tool used for showing vulnerabilities and bugs in source code. It enables developers to write custom queries that analyze codebases, searching for specific patterns and potential security issues. By converting code into a database format, CodeQL allows for sophisticated, database-like queries to detect flaws. CodeQL in Action 1. Preparing the Code Create a CodeQL Database : Extract and structure the code into a database for analy...
Read more

[MS] How can I check that all the changes in a git branch have been cherry-picked or rebased into its upstream branch? - devamazonaws.blogspot.com

If you try to delete a branch that contains changes that haven't been merged to its upstream, git warns you, the branch is not fully merged. If you are sure you want to delete it, run 'git branch -D xxx' . Suppose you want to check that all of the changes in the branch have been cherry-picked or rebased into the upstream branch. How can you confirm this? How can you do the "If you are sure" step? One way to do this is to merge the branch into its upstream and see if the result produces any changes. # Detach the HEAD from the upstream so we can do some tinkering. $ git checkout --detach featurebranch{@u} # Propose a merge of the feature branch. $ git merge featurebranch $ ⟦ resolve any merge conflicts and commit ⟧ # See if anything would have changed. $ git diff HEAD HEAD~1 # Return to original branch, abandon detached HEAD. $ git checkout - If the git diff produces no output, then everything in your featurebranch is already present in the upstream, so you ...
Read more