A gentle introduction to automated reasoning

{"value":"\n\nThe new automated-reasoning icon\n\nThis week, Amazon Science added automated reasoning to its list of ++[research areas](https://www.amazon.science/research-areas)++. We made this change because of the impact that automated reasoning is having here at Amazon. For example, Amazon Web Services’ customers now have direct access to automated-reasoning-based features such as ++[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)++, ++[S3 Block Public Access](https://aws.amazon.com/blogs/aws/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/)++, or ++[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)++. We also see Amazon development teams ++[integrating automated-reasoning tools ](https://www.amazon.science/blog/how-automated-reasoning-improves-the-prime-video-experience)++ into their development processes, raising the bar on the ++[security](https://www.amazon.science/latest-news/how-awss-automated-reasoning-group-helps-make-aws-and-other-amazon-products-more-secure)++, ++[durability](https://www.amazon.science/blog/aws-team-wins-best-paper-award-for-work-on-automated-reasoning)++, availability, and quality of our products.\n\nThe goal of this article is to provide a gentle introduction to automated reasoning for the industry professional who knows nothing about the area but is curious to learn more. All you will need to make sense of this article is to be able to read a few small C and Python code fragments. I will refer to a few specialist concepts along the way, but only with the goal of introducing them in an informal manner. I close with links to some of our favorite publicly available tools, videos, books, and articles for those looking to go more in-depth.\n\nLet’s start with a simple example. Consider the following C function:\n\n```\\nbool f(unsigned int x, unsigned int y) {\\n return (x+y == y+x);\\n}\\n```\n\nTake a few moments to answer the question “Could f ever return false?” This is not a trick question: I’ve purposefully used a simple example to make a point.\n\nTo check the answer with exhaustive testing, we could try executing the following doubly nested test loop, which calls f on all possible pairs of values of the type unsigned int:\n\n```\\n#include<stdio.h>\\n#include<stdbool.h>\\n#include<limits.h>\\n\\nbool f(unsigned int x, unsigned int y) {\\n return (x+y == y+x);\\n}\\n\\nvoid main() {\\n for (unsigned int x=0;1;x++) {\\n for (unsigned int y=0;1;y++) {\\n if (!f(x,y)) printf(\\"Error!\\\\n\\");\\n if (y==UINT_MAX) break;\\n }\\n if (x==UINT_MAX) break;\\n }\\n}\\n```\n\nUnfortunately, even on modern hardware, this doubly nested loop will run for a very long time. I compiled it and ran it on a 2.6 GHz Intel processor for over 48 hours before giving up.\n\nWhy does testing take so long? Because UINT_MAX is typically 4,294,967,295, there are 18,446,744,065,119,617,025 separate f calls to consider. On my 2.6 GHz machine, the compiled test loop called f approximately 430 million times a second. But to test all 18 quintillion cases at this performance, we would need over 1,360 years.\n\nWhen we show the above code to industry professionals, they almost immediately work out that f can't return false as long as the underlying compiler/interpreter and hardware are correct. How do they do that? They reason about it. They remember from their school days that x + y can be rewritten as y + x and conclude that f always returns true.\n\n#### **Re:Invent 2021 keynote address by Peter DeSantis, senior vice president for utility computing at Amazon Web Services**\n\nSkip to ++[15:49](https://youtu.be/9NEQbFLtDmg?t=949)++ for a discussion of Amazon Web Services' work on automated reasoning.\n\nAn automated reasoning tool does this work for us: it attempts to answer questions about a program (or a logic formula) by using known techniques from mathematics. In this case, the tool would use algebra to deduce that x + y == y + x can be replaced with the simple expression true.\n\nAutomated-reasoning tools can be incredibly fast, even when the domains are infinite (e.g., unbounded mathematical integers rather than finite C ints). Unfortunately, the tools may answer “Don’t know” in some instances. We'll see a famous example of that below.\n\nThe science of automated reasoning is essentially focused on driving the frequency of these “Don’t know” answers down as far as possible: the less often the tools report \"Don't know\" (or time out while trying), the more useful they are.\n\nToday’s tools are able to give answers for programs and queries where yesterday’s tools could not. Tomorrow’s tools will be even more powerful. We are seeing rapid progress in this field, which is why at Amazon, we are increasingly getting so much value from it. In fact, we see automated reasoning forming its own Amazon-style virtuous cycle, where more input problems to our tools drive improvements to the tools, which encourages more use of the tools.\n\nA slightly more complex example. Now that we know the rough outlines of what automated reasoning is, the next small example gives a slightly more realistic taste of the sort of complexity that the tools are managing for us.\n\n```\\nvoid g(int x, int y) {\\n if (y > 0)\\n while (x > y)\\n x = x - y;\\n}\\n```\nOr, alternatively, consider a similar Python program over unbounded integers:\n\n```\\ndef g(x, y):\\n assert isinstance(x, int) and isinstance(y, int)\\n if y > 0:\\n while x > y:\\n x = x - y\\n```\nTry to answer this question: “Does g always eventually return control back to its caller?”\n\nWhen we show this program to industry professionals, they usually figure out the right answer quickly. A few, especially those who are aware of results in theoretical computer science, sometimes mistakenly think that we can't answer this question, with the rationale “This is an example of the ++[halting problem](https://en.wikipedia.org/wiki/Halting_problem)++, which has been proved insoluble”. In fact, we can reason about the halting behavior for specific programs, including this one. We’ll talk more about that later.\n\nHere’s the reasoning that most industry professionals use when looking at this problem:\n\n1、In the case where y is not positive, execution jumps to the end of the function g. That’s the easy case.\n2、If, in every iteration of the loop, the value of the variable x decreases, then eventually, the loop condition x > y will fail, and the end of g will be reached.\n3、The value of x always decreases only if y is always positive, because only then does the update to x (i.e., x = x - y) decrease x. But y’s positivity is established by the conditional expression, so x always decreases.\n\nThe experienced programmer will usually worry about underflow in the x = x - y command of the C program but will then notice that x > y before the update to x and thus cannot underflow.\n\nIf you carried out the three steps above yourself, you now have a very intuitive view of the type of thinking an automated-reasoning tool is performing on our behalf when reasoning about a computer program. There are many nitty-gritty details that the tools have to face (e.g., heaps, stacks, strings, pointer arithmetic, recursion, concurrency, callbacks, etc.), but there’s also decades of research papers on techniques for handling these and other topics, along with various practical tools that put these ideas to work.\n\n\n\nAutomated reasoning can be applied to both policies (top) and code (bottom). In both cases, an essential step is reasoning about what's always true.\n\nThe main takeaway is that automated-reasoning tools are usually working through the three steps above on our behalf: Item 1 is reasoning about the program’s control structure. Item 2 is reasoning about what is eventually true within the program. Item 3 is reasoning about what is always true in the program.\n\nNote that configuration artifacts such as Amazon Web Services resource policies, VPC network descriptions, or even makefiles can be thought of as code. This viewpoint allows us to use the same techniques we use to reason about C or Python code to answer questions about the interpretation of configurations. It’s this insight that gives us tools like IAM Access Analyzer or VPC Reachability Analyzer.\n\n#### **An end to testing?**\n\nAs we saw above when looking at f and g, automated reasoning can be dramatically faster than exhaustive testing. With tools available today, we can show properties of f or g in milliseconds, rather than waiting lifetimes with exhaustive testing.\n\nCan we throw away our testing tools now and just move to automated reasoning? Not quite. Yes, we can dramatically reduce our dependency on testing, but we will not be completely eliminating it any time soon, if ever. Consider our first example:\n\n```\\nbool f(unsigned int x, unsigned int y) {\\n return (x + y == y + x);\\n}\\n```\n\nRecall the worry that a buggy compiler or microprocessor could in fact cause an executable program constructed from this source code to return false. We might also need to worry about the language runtime. For example, the C math library or the Python garbage collector might have bugs that cause a program to misbehave.\n\nWhat’s interesting about testing, and something we often forget, is that it’s doing much more than just telling us about the C or Python source code. It’s also testing the compiler, the runtime, the interpreter, the microprocessor, etc. A test failure could be rooted in any of those tools in the stack.\n\nAutomated reasoning, in contrast, is usually applied to just one layer of that stack — the source code itself, or sometimes the compiler or the microprocessor. What we find so valuable about reasoning is it allows us to clearly define both what we do know and what we do not know about the layer under inspection.\n\nFurthermore, the models of the surrounding environment (e.g., the compiler or the procedure calling our procedure) used by the automated-reasoning tool make our assumptions very precise. Separating the layers of the computational stack helps make better use of our time, energy, and money and the capabilities of the tools today and tomorrow.\n\nUnfortunately, we will almost always need to make assumptions about something when using automated reasoning — for example, the principles of physics that govern our silicon chips. Thus, testing will never be fully replaced. We will want to perform end-to-end testing to try and validate our assumptions as best we can.\n\n#### **An impossible program**\n\nI previously mentioned that automated-reasoning tools sometimes return “Don’t know” rather than “yes” or “no”. They also sometimes run forever (or time out), thus never returning an answer. Let’s look at the famous \"halting problem\" program, in which we know tools cannot return “yes” or “no”.\n\nImagine that we have an automated-reasoning API, called terminates, that returns “yes” if a C function always terminates or “no” when the function could execute forever. As an example, we could build such an API using the tool described here (shameless self-promotion of author’s previous work). To get the idea of what a termination tool can do for us, consider two basic C functions, g (from above),\n\n```\\nvoid g(int x, int y) {\\n if (y > 0)\\n while (x > y)\\n x = x - y;\\n}\\n```\nand g2:\n\n```\\nvoid g2(int x, int y) {\\n while (x > y)\\n x = x - y;\\n}\\n```\n\nFor the reasons we have already discussed, the function g always returns control back to its caller, so terminates(g) should return true. Meanwhile, terminates(g2) should return false because, for example, g2(5, 0) will never terminate.\n\nNow comes the difficult function. Consider h:\n\n```\\nvoid h() {\\n if terminates(h) while(1){}\\n}\\n\\n```\n\nNotice that it's recursive. What’s the right answer for terminates(h)? The answer cannot be \"yes\". It also cannot be \"no\". Why?\n\nImagine that terminates(h) were to return \"yes\". If you read the code of h, you’ll see that in this case, the function does not terminate because of the conditional statement in the code of h that will execute the infinite loop while(1){}. Thus, in this case, the terminates(h) answer would be wrong, because h is defined recursively, calling terminates on itself.\n\nSimilarly, if terminates(h) were to return \"no\", then h would in fact terminate and return control to its caller, because the if case of the conditional statement is not met, and there is no else branch. Again, the answer would be wrong. This is why the “Don’t know” answer is actually unavoidable in this case.\n\nThe program h is a variation of examples given in Turing’s ++[famous 1936 paper](https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf)++ on decidability and ++[Gödel’s incompleteness theorems](https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems)++ from 1931. These papers tell us that problems like the halting problem cannot be “solved”, if by“solved” we mean that the solution procedure itself always terminates and answers either “yes” or “no” but never “Don’t know”. But that is not the definition of “solved” that many of us have in mind. For many of us, a tool that sometimes times out or occasionally returns “Don’t know” but, when it gives an answer, always gives the right answer is good enough.\n\nThis problem is analogous to airline travel: we know it’s not 100% safe, because crashes have happened in the past, and we are sure that they will happen in the future. But when you land safely, you know it worked that time. The goal of the airline industry is to reduce failure as much as possible, even though it’s in principle unavoidable.\n\nTo put that in the context of automated reasoning: for some programs, like h, we can never improve the tool enough to replace the \"Don't know\" answer. But there are many other cases where today's tools answer \"Don't know\", but future tools may be able to answer \"yes\" or \"no\". The modern scientific challenge for automated-reasoning subject-matter experts is to get the practical tools to return “yes” or “no” as often as possible. As an example of current work, check out CMU professor and ++[Amazon scholar](https://www.amazon.science/scholars)++ ++[Marijn Heule](https://www.cs.cmu.edu/~mheule/)++ and his ++[quest to solve the Collatz termination problem](https://www.quantamagazine.org/computer-scientists-attempt-to-corner-the-collatz-conjecture-20200826/)++.\n\nAnother thing to keep in mind is that automated-reasoning tools are regularly trying to solve “intractable” problems, e.g., problems in the NP complexity class. Here, the same thinking applies that we saw in the case of the halting problem: automated-reasoning tools have powerful heuristics that often work around the intractability problem for specific cases, but those heuristics can (and sometimes do) fail, resulting in “Don’t know” answers or impractically long execution time. The science is to improve the heuristics to minimize that problem.\n\n#### **Nomenclature**\n\nA host of names are used in the scientific literature to describe interrelated topics, of which automated reasoning is just one. Here’s a quick glossary:\n\n- A logic is a formal and mechanical system for defining what is true and untrue. Examples: ++[propositional logic](https://en.wikipedia.org/wiki/Propositional_calculus)++ or ++[first-order logic](https://en.wikipedia.org/wiki/First-order_logic)++.\n- A theorem is a true statement in logic. Example: the ++[four-color theorem](https://en.wikipedia.org/wiki/Four_color_theorem)++.\n\n\n- A proof is a valid argument in logic of a theorem. Example: Gonthier's ++[proof of the four-color theorem](http://www.ams.org/notices/200811/tx081101382p.pdf)++. \n\n\n\n- A mechanical theorem prover is a semi-automated-reasoning tool that checks a machine-readable expression of a proof often written down by a human. These tools often require human guidance. Example: ++[HOL-light](https://github.com/jrh13/hol-light/)++, from Amazon researcher ++[John Harrison](https://www.cl.cam.ac.uk/~jrh13/)++. \n- Formal verification is the use of theorem proving when applied to models of computer systems to prove desired properties of the systems. Example: the ++[CompCert verified C compiler](https://compcert.org/doc/)++. \n- Formal methods is the broadest term, meaning simply the use of logic to reason formally about models of systems. \n- Automated reasoning focuses on the automation of formal methods. \n- A semi-automated-reasoning tool is one that requires hints from the user but still finds valid proofs in logic. \n\nAs you can see, we have a choice of monikers when working in this space. At Amazon, we’ve chosen to use automated reasoning, as we think it best captures our ambition for automation and scale. In practice, some of our internal teams use both automated and semi-automated reasoning tools, because the scientists we've hired can often get semi-automated reasoning tools to succeed where the heuristics in fully automated reasoning might fail. For our externally facing customer features, we currently use only fully automated approaches.\n\n#### **Next steps**\n\nIn this essay, I’ve introduced the idea of automated reasoning, with the smallest of toy programs. I haven’t described how to handle realistic programs, with heap or concurrency. In fact, there are a wide variety of automated-reasoning tools and techniques, solving problems in all kinds of different domains, some of them quite narrow. To describe them all and the many branches and sub-disciplines of the field (e.g. “SMT solving”, “higher-order logic theorem proving”, “separation logic”) would take thousands of blogs posts and books.\n\nAutomated reasoning goes back to the early inventors of computers. And logic itself (which automated reasoning attempts to solve) is thousands of years old. In order to keep this post brief, I’ll stop here and suggest further reading. Note that it’s very easy to get lost in the weeds reading depth-first into this area, and you could emerge more confused than when you started. I encourage you to use a bounded depth-first search approach, looking sequentially at a wide variety of tools and techniques in only some detail and then moving on, rather than learning only one aspect deeply.\n\n#### **Suggested books:**\n\n- ++[Handbook of Practical Logic and Automated Reasoning](https://www.amazon.com/Handbook-Practical-Logic-Automated-Reasoning/dp/0521899575)++\n- ++[Temporal Verification of Reactive Systems](https://link.springer.com/book/10.1007/978-1-4612-4222-2)++\n- ++[Decision Procedures](https://www.decision-procedures.org/)++\n- ++[Model Checking](https://mitpress.mit.edu/books/model-checking-second-edition)++\n- ++[Software Foundations](https://softwarefoundations.cis.upenn.edu/current/index.html)++\n- ++[Specifying Systems](https://lamport.azurewebsites.net/tla/book.html#download)++\n- ++[Introduction to Static Analysis](https://mitpress.mit.edu/books/introduction-static-analysis)++\n- ++[Logic in Computer Science: Modelling and Reasoning about Systems](https://www.amazon.com/Logic-Computer-Science-Modelling-Reasoning/dp/052154310X)++\n- ++[Functional Algorithms, Verified!](https://functional-algorithms-verified.org/)++\n- ++[Handbook of Satisfiability](https://ebooks.iospress.nl/volume/handbook-of-satisfiability-second-edition)++\n- ++[The Calculus of Computation](https://link.springer.com/book/10.1007/978-3-540-74113-8)++\n\n#### **International conferences/workshops:**\n\n- ++[https://etaps.org/2020/tacas](https://etaps.org/2020/tacas)++\n- ++[http://i-cav.org/2020/](http://i-cav.org/2020/)++\n- ++[https://ijcar2020.org/](https://ijcar2020.org/)++\n- ++[https://popl21.sigplan.org/](https://popl21.sigplan.org/)++\n- ++[https://sat2020.idea-researchlab.org/](https://sat2020.idea-researchlab.org/)++\n- ++[http://smt-workshop.cs.uiowa.edu/](http://smt-workshop.cs.uiowa.edu/)++\n\n#### **Tool competitions:**\n\n- ++[http://termination-portal.org/wiki/Termination_Competition](http://termination-portal.org/wiki/Termination_Competition)++\n- ++[https://sv-comp.sosy-lab.org/2020/](https://sv-comp.sosy-lab.org/2020/)++\n- ++[https://smt-comp.github.io/2020/](https://smt-comp.github.io/2020/)++\n- ++[http://www.satcompetition.org/](http://www.satcompetition.org/)++\n- ++[http://www.tptp.org/CASC/27/](http://www.tptp.org/CASC/27/)++\n\n#### **Some tools:**\n\n- AGREE: ++[http://loonwerks.com/tools/agree.html](http://loonwerks.com/tools/agree.html)++\n- Alloy: ++[https://alloytools.org/](https://alloytools.org/)++\n- Aprove: ++[https://aprove.informatik.rwth-aachen.de/](https://aprove.informatik.rwth-aachen.de/)++\n- BioModelAnalzyer: ++[https://biomodelanalyzer.com/](https://biomodelanalyzer.com/)++\n- Boogie: ++[https://github.com/boogie-org/boogie.git](https://github.com/boogie-org/boogie.git)++\n- CBMC: ++[https://www.cprover.org/cbmc/](https://www.cprover.org/cbmc/)++\n- Checked C: ++[https://plum-umd.github.io/projects/checkedc.html](https://plum-umd.github.io/projects/checkedc.html)++\n- Checker Framework: ++[https://checkerframework.org/](https://checkerframework.org/)++\n- CoCoSim: ++[https://github.com/NASA-SW-VnV/CoCoSim](https://github.com/NASA-SW-VnV/CoCoSim)++\n- Coq: ++[https://coq.inria.fr/](https://coq.inria.fr/)++\n- CPA Checker: ++[https://cpachecker.sosy-lab.org/](https://cpachecker.sosy-lab.org/)++\n- CVC4: ++[https://cvc4.github.io/](https://cvc4.github.io/)++\n- Dafny: ++[https://github.com/dafny-lang/dafny](https://github.com/dafny-lang/dafny)++\n- Dreal: ++[https://github.com/dreal/dreal4](https://github.com/dreal/dreal4)++\n- HOL light: ++[https://www.cl.cam.ac.uk/~jrh13/hol-light/](https://www.cl.cam.ac.uk/~jrh13/hol-light/)++\n- Infer: ++[https://fbinfer.com](https://fbinfer.com/)++\n- Iris: ++[https://iris-project.org/](https://iris-project.org/)++\n- Isabelle: ++[https://isabelle.in.tum.de/](https://isabelle.in.tum.de/)++\n- Java PathFinder: ++[https://github.com/javapathfinder](https://github.com/javapathfinder)++\n- JKind: ++[https://github.com/loonwerks/jkind](https://github.com/loonwerks/jkind)++\n- Keymaera X: ++[https://keymaerax.org/](https://keymaerax.org/)++\n- Kind2: ++[https://kind2-mc.github.io/kind2](https://kind2-mc.github.io/kind2)++\n- KLEE: ++[https://klee.github.io](https://klee.github.io/)++\n- Lean: ++[https://leanprover.github.io/](https://leanprover.github.io/)++\n- MiniSat: ++[http://minisat.se/](http://minisat.se/)++\n- Nagini: ++[https://github.com/marcoeilers/nagini](https://github.com/marcoeilers/nagini)++\n- P: ++[https://github.com/p-org/P](https://github.com/p-org/P)++\n- PRISM:++[https://www.prismmodelchecker.org](https://www.prismmodelchecker.org/)++\n- PVS: ++[https://pvs.csl.sri.com](https://pvs.csl.sri.com/)++\n- Rosette: ++[http://emina.github.io/rosette/](http://emina.github.io/rosette/)++\n- Rust programming language: ++[https://www.rust-lang.org/ ](https://www.rust-lang.org/)++ [When you are programming in Rust you are essentially proving the absence of memory corruption in a type system (assuming you're not using \"unsafe\" regions)]\n- Sally: ++[https://github.com/SRI-CSL/sally](https://github.com/SRI-CSL/sally)++\n- SAW: ++[https://saw.galois.com/](https://saw.galois.com/)++\n- SeaHorn: ++[http://seahorn.github.io/](http://seahorn.github.io/)++\n- SMACK: ++[https://smackers.github.io](https://smackers.github.io/)++\n- Soot: ++[http://soot-oss.github.io/soot/](http://soot-oss.github.io/soot/)++\n- SPIN: ++[http://spinroot.com/spin/whatispin.html](http://spinroot.com/spin/whatispin.html)++\n- T2: ++[https://mmjb.github.io/T2/](https://mmjb.github.io/T2/)++\n- TLA+: ++[https://lamport.azurewebsites.net/tla/tla.html](https://lamport.azurewebsites.net/tla/tla.html)++\n- Vampire: ++[https://vprover.github.io/](https://vprover.github.io/)++\n- VCC: ++[https://github.com/microsoft/vcc](https://github.com/microsoft/vcc)++\n- Verifast: ++[https://github.com/verifast/verifast](https://github.com/verifast/verifast)++\n- Z3: ++[https://github.com/Z3Prover/z3](https://github.com/Z3Prover/z3)++\n\n#### **Interviews of Amazon staff about their use of automated reasoning:**\n- ++[Byron Cook PLDI'20 Ask Me Anything](https://www.youtube.com/watch?v=MHON17HzPZI)++\n- ++[Byron Cook on The CUBE](https://www.youtube.com/watch?v=J9Da3VsLH44)++\n- ++[Neha Rungta on The CUBE](https://www.youtube.com/watch?v=CWVehV9PsPQ)++\n- ++[Neha Rungta discusses constraint-based reasoning tools in Amazon Web Services Config Rules](https://www.youtube.com/watch?v=Awy04VNIFJg)++\n- ++[Serdar Tasiran CAV'21 Ask Me Anything](https://ucl-pplv.github.io/CAV21/poster_P_k15/)++\n- ++[LogMeIn: How LogMeIn Automates Governance and Empowers Developers at Scale](https://www.youtube.com/watch?v=le8h_dpqroo)++\n\n#### **Amazon Web Services Lectures aimed at customers and industry:**\n\n- ++[Automating Compliance Verification on Amazon Web Services Using Provable Security](https://www.youtube.com/watch?v=BbXK_-b3DTk)++, lecture with Amazon Web Services VP of compliance Chad Woolf, and compliance auditor Coalfire's CEO Tom McAndrew\n- ++[An Amazon Web Services Approach to Higher Standards of Assurance w/ Provable Security](https://www.youtube.com/watch?v=UKqVY0SSbus)++, Byron Cook\n- ++[Dive Deep into IAM Access Analyze](https://www.youtube.com/watch?v=i5apYXya2m0)++, lecture by Andrew Gacek and others\n- ++[The Evolution of automated reasoning Technology at Amazon Web Services](https://www.youtube.com/watch?v=x6wsTFnU3eY)++, lecture with Amazon Web Services VP of security Eric Brandwine\n- ++[Lecture](https://www.youtube.com/watch?v=Wvyc-VEUOns&t=2214)++ by Amazon Web Services CISO and VP of security Steve Schmidt about on the development and use of formal/constraint-based tools in Amazon Web Services\n- ++[Re:Invent Keynote](https://www.youtube.com/watch?v=jt-gV1YwmnI&t=2975s)++, lecture by CTO Werner Vogels\n\n#### **Amazon Web Services talks aimed at the automated-reasoning science community:**\n- ++[Debugging Network Reachability with Blocked Paths](https://ucl-pplv.github.io/CAV21/poster_P_215/)++, CAV'21\n- ++[Embedded World 2021: Formally Verifying the FreeRTOS IPC Mechanism](https://www.youtube.com/watch?v=Y_DeKKhbNUs)++, Embedded World '21\n- ++[Formal reasoning about the security of Amazon Web Services](https://youtu.be/JfjLKBO27nw)++, FLoC 2018 plenary lecture\n- ++[Formal reasoning about the security of Amazon Web Services](https://www.youtube.com/watch?v=9lPR0d2uijo)++, OOPSLA/SPLASH 2018 keynote lecture\n- ++[How I learned to stop worrying and start applying automated reasoning](https://ucl-pplv.github.io/CAV21/poster_facc_10/)++, FACC'21 (other relevant talks at FACC website)\n- ++[On automated reasoning for compliance certification](https://ucl-pplv.github.io/CAV21/poster_facc_10/)++, CAV workshop on Formal Approaches to Certifying Compliance (FACC)\n- ++[Pre-Deployment Security Assessment for Cloud Services through Semantic Reasoning](https://ucl-pplv.github.io/CAV21/poster_P_315/)++, CAV'21\n- ++[Provable Security at Amazon Web Services](https://www.youtube.com/watch?v=bO-vfLpFI3I)++, USENIX Enigma 2019\n- [Skip to 30mins in]: ++[SideTrail: Verifying Time-Balancing of Cryptosystems](https://www.facebook.com/ze.jaloto/videos/10157040968367975/)++\n- ++[Stratified abstraction of access control policies](https://www.youtube.com/watch?v=TjSQ1P3tM2I)++, CAV'20\n- ++[Verified Cryptographic Code for Everybody](https://ucl-pplv.github.io/CAV21/poster_P_46/)++, CAV'21\n- ++[What is automated reasoning? How Is it Used at Amazon Web Services?](https://www.youtube.com/watch?v=sS-x_NQ-CsI)++\n\n#### **Amazon Web Services blog posts and informational videos:**\n\n- ++[A simpler way to assess the network exposure of EC2 instances: Amazon Web Services releases new network reachability assessments in Amazon Inspector](https://aws.amazon.com/blogs/security/amazon-inspector-assess-network-exposure-ec2-instances-aws-network-reachability-assessments/)++\n- ++[AAmazon Web Services CTO blogs about automated reasoning Group: Proving security at scale with automated reasoning](https://www.allthingsdistributed.com/2019/06/proving-security-at-scale-with-automated-reasoning.html)++\n- ++[Amazon Web Services CTO discusses S3 consistency](https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html)++\n- Amazon Web Services Podcast interview: ++[Provable security podcast: Byron interviews Moshe Vardi](https://aws.amazon.com/blogs/security/provable-security-podcast-automated-reasonings-past-present-and-future-with-moshe-vardi/?fbclid=IwAR1lHco10mnp7yPEDwUFMgMCpCMoKVIxKOCGLGvwEUzHoL1TAW_cWAwoD8w)++\n- Amazon Web Services Podcast interview: ++[Next Generation Security with automated reasoning, an Artificial Intelligence Technology](https://aws.amazon.com/podcasts/aws-podcast/#266)++\n- ++[Blog post](https://aws.amazon.com/blogs/aws/aws-config-update-new-managed-rules-to-secure-s3-buckets/)++ about event-driven checks in ++[Amazon Web Services Config](https://aws.amazon.com/config/)++ powered by automated constraint solving techniques over IAM policies [++[attend this session at NY summit](https://awsnyc17.smarteventscloud.com/connect/sessionDetail.ww?SESSION_ID=121651)++] ... and ++[more detail](https://aws.amazon.com/blogs/mt/example-scenarios-for-aws-config-continuous-monitoring-of-amazon-s3-bucket-access-controls/)++\n- ++[Blog post](https://aws.amazon.com/blogs/aws/new-amazon-s3-encryption-security-features/)++ on the use of constraint-based reasoning about policies in the Amazon Web Services S3 console\n- Blogs ++[1](https://galois.com/blog/2016/09/verifying-s2n-hmac-with-saw/)++, ++[2](https://galois.com/blog/2016/09/specifying-hmac-in-cryptol/)++, and ++[3](https://galois.com/blog/2016/09/proving-program-equivalence-with-saw/)++ about work with ++[Galois](https://galois.com/)++ to prove the correctness of Amazon's crypto infrastructure component ++[s2n](https://aws.amazon.com/blogs/security/introducing-s2n-a-new-open-source-tls-implementation/)++\n- ++[Chad Wolff (VP of compliance at Amazon Web Services) discusses his interest in using automated reasoning to simplify and raise the bar on compliance certification](https://aws.amazon.com/blogs/security/aws-security-profiles-chad-woolf-vp-of-aws-security/)++\n- ++[Daniel Schwartz-Narbonne shares how automated reasoning is helping achieve the provable security of Amazon Web Services boot code](https://aws.amazon.com/blogs/security/automated-reasoning-provable-security-of-boot-code/)++\n- ++[How automated reasoning helps us innovate at S3 scale](https://aws.amazon.com/blogs/storage/how-automated-reasoning-helps-us-innovate-at-s3-scale/)++\n- ++[How automated reasoning improves Prime Vdeo experience](https://www.amazon.science/blog/how-automated-reasoning-improves-the-prime-video-experience)++\n- ++[How Amazon Web Services SideTrail verifies key Amazon Web Services cryptography code](https://aws.amazon.com/blogs/security/how-aws-sidetrail-verifies-key-aws-cryptography-code/)++\n- ++[How Amazon Web Services uses automated reasoning to help you achieve security at scale](https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/)++\n- ++[Jeff Barr about tools for IoT configuration verification](https://aws.amazon.com/blogs/aws/aws-iot-device-defender-now-available-keep-your-connected-devices-safe/)++\n- ++[On VPC Reachablity Analyzer](https://aws.amazon.com/blogs/aws/new-vpc-insights-analyzes-reachability-and-visibility-in-vpcs/)++\n- ++[New (Zelkova-based) Amazon Web Services Config rules s3-blacklisted-actions-prohibited and bucket-policy-not-more-permissive are released](https://aws.amazon.com/about-aws/whats-new/2018/09/aws-config-announces-new-managed-rules/)++\n- ++[Podcast: AI tech named automated reasoning provides next-gen cloud security](https://aws.amazon.com/blogs/security/podcast-automated-reasoning-aws-next-gen-security-ai/)++\n- Some detail about constraint-based IAM policy analysis used in ++[Amazon Macie](https://aws.amazon.com/macie/)++ can be found ++[here](http://docs.aws.amazon.com/macie/latest/userguide/macie-research.html#s3bucketsdata)++\n- ++[Tightening application security with Amazon CodeGuru](https://aws.amazon.com/blogs/devops/tightening-application-security-with-amazon-codeguru/)++\n- ++[Using Formal Methods to validate OTA Protocol](https://freertos.org/2020/12/using-formal-methods-to-validate-ota-protocol.html)++\n- ++[... more Amazon Web Services blogs](https://aws.amazon.com/blogs/security/tag/automated-reasoning/)++\n\n#### **Some course notes by Amazon Scholars who are also university professors:**\n\n- ++[https://courses.cs.washington.edu/courses/cse507/21au/](https://courses.cs.washington.edu/courses/cse507/21au/)++\n- ++[http://www.cs.cmu.edu/~mheule/15816-f21/](http://www.cs.cmu.edu/~mheule/15816-f21/)++\n- ++[https://www.cs.cmu.edu/~mheule/15217-f21/](https://www.cs.cmu.edu/~mheule/15217-f21/)++\n\n#### **A fun deep track:**\n\nSome algorithms found in the automated theorem provers we use today date as far back as 1959, ++[when Hao Wang used automated reasoning to prove the theorems from](https://dl.acm.org/doi/abs/10.1147/rd.41.0002)++ ++[Principia Mathematica.](https://dl.acm.org/doi/abs/10.1147/rd.41.0002)++\n\nABOUT THE AUTHOR\n\n#### **[Byron Cook](https://www.amazon.science/author/byron-cook)**\n\nByron Cook is a leader in the field of formal verification, known for his contributions to SAT, SMT, and symbolic model checking, with applications to biological systems, computer operating systems, programming languages, and security. Byron’s work on automated reasoning at Amazon has led to higher levels of assurance in the cloud as well as new customer features.\n\n\n\n\n\n","render":"<p><img src=\\"https://dev-media.amazoncloud.cn/d85d99f2a98845d59cb14867c8091377_image.png\\" alt=\\"image.png\\" /></p>\n<p>The new automated-reasoning icon</p>\n<p>This week, Amazon Science added automated reasoning to its list of <ins><a href=\\"https://www.amazon.science/research-areas\\" target=\\"_blank\\">research areas</a></ins>. We made this change because of the impact that automated reasoning is having here at Amazon. For example, Amazon Web Services’ customers now have direct access to automated-reasoning-based features such as <ins><a href=\\"https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html\\" target=\\"_blank\\">IAM Access Analyzer</a></ins>, <ins><a href=\\"https://aws.amazon.com/blogs/aws/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/\\" target=\\"_blank\\">S3 Block Public Access</a></ins>, or <ins><a href=\\"https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html\\" target=\\"_blank\\">VPC Reachability Analyzer</a></ins>. We also see Amazon development teams <ins><a href=\\"https://www.amazon.science/blog/how-automated-reasoning-improves-the-prime-video-experience\\" target=\\"_blank\\">integrating automated-reasoning tools </a></ins> into their development processes, raising the bar on the <ins><a href=\\"https://www.amazon.science/latest-news/how-awss-automated-reasoning-group-helps-make-aws-and-other-amazon-products-more-secure\\" target=\\"_blank\\">security</a></ins>, <ins><a href=\\"https://www.amazon.science/blog/aws-team-wins-best-paper-award-for-work-on-automated-reasoning\\" target=\\"_blank\\">durability</a></ins>, availability, and quality of our products.</p>\n<p>The goal of this article is to provide a gentle introduction to automated reasoning for the industry professional who knows nothing about the area but is curious to learn more. All you will need to make sense of this article is to be able to read a few small C and Python code fragments. I will refer to a few specialist concepts along the way, but only with the goal of introducing them in an informal manner. I close with links to some of our favorite publicly available tools, videos, books, and articles for those looking to go more in-depth.</p>\n<p>Let’s start with a simple example. Consider the following C function:</p>\n<pre><code class=\\"lang-\\">bool f(unsigned int x, unsigned int y) {\\n return (x+y == y+x);\\n}\\n</code></pre>\\n<p>Take a few moments to answer the question “Could f ever return false?” This is not a trick question: I’ve purposefully used a simple example to make a point.</p>\n<p>To check the answer with exhaustive testing, we could try executing the following doubly nested test loop, which calls f on all possible pairs of values of the type unsigned int:</p>\n<pre><code class=\\"lang-\\">#include&lt;stdio.h&gt;\\n#include&lt;stdbool.h&gt;\\n#include&lt;limits.h&gt;\\n\\nbool f(unsigned int x, unsigned int y) {\\n return (x+y == y+x);\\n}\\n\\nvoid main() {\\n for (unsigned int x=0;1;x++) {\\n for (unsigned int y=0;1;y++) {\\n if (!f(x,y)) printf(&quot;Error!\\\\n&quot;);\\n if (y==UINT_MAX) break;\\n }\\n if (x==UINT_MAX) break;\\n }\\n}\\n</code></pre>\\n<p>Unfortunately, even on modern hardware, this doubly nested loop will run for a very long time. I compiled it and ran it on a 2.6 GHz Intel processor for over 48 hours before giving up.</p>\n<p>Why does testing take so long? Because UINT_MAX is typically 4,294,967,295, there are 18,446,744,065,119,617,025 separate f calls to consider. On my 2.6 GHz machine, the compiled test loop called f approximately 430 million times a second. But to test all 18 quintillion cases at this performance, we would need over 1,360 years.</p>\n<p>When we show the above code to industry professionals, they almost immediately work out that f can’t return false as long as the underlying compiler/interpreter and hardware are correct. How do they do that? They reason about it. They remember from their school days that x + y can be rewritten as y + x and conclude that f always returns true.</p>\n<h4><a id=\\"ReInvent_2021_keynote_address_by_Peter_DeSantis_senior_vice_president_for_utility_computing_at_Amazon_Web_Services_46\\"></a><strong>Re:Invent 2021 keynote address by Peter DeSantis, senior vice president for utility computing at Amazon Web Services</strong></h4>\\n<p>Skip to <ins><a href=\\"https://youtu.be/9NEQbFLtDmg?t=949\\" target=\\"_blank\\">15:49</a></ins> for a discussion of Amazon Web Services’ work on automated reasoning.</p>\n<p>An automated reasoning tool does this work for us: it attempts to answer questions about a program (or a logic formula) by using known techniques from mathematics. In this case, the tool would use algebra to deduce that x + y == y + x can be replaced with the simple expression true.</p>\n<p>Automated-reasoning tools can be incredibly fast, even when the domains are infinite (e.g., unbounded mathematical integers rather than finite C ints). Unfortunately, the tools may answer “Don’t know” in some instances. We’ll see a famous example of that below.</p>\n<p>The science of automated reasoning is essentially focused on driving the frequency of these “Don’t know” answers down as far as possible: the less often the tools report “Don’t know” (or time out while trying), the more useful they are.</p>\n<p>Today’s tools are able to give answers for programs and queries where yesterday’s tools could not. Tomorrow’s tools will be even more powerful. We are seeing rapid progress in this field, which is why at Amazon, we are increasingly getting so much value from it. In fact, we see automated reasoning forming its own Amazon-style virtuous cycle, where more input problems to our tools drive improvements to the tools, which encourages more use of the tools.</p>\n<p>A slightly more complex example. Now that we know the rough outlines of what automated reasoning is, the next small example gives a slightly more realistic taste of the sort of complexity that the tools are managing for us.</p>\n<pre><code class=\\"lang-\\">void g(int x, int y) {\\n if (y &gt; 0)\\n while (x &gt; y)\\n x = x - y;\\n}\\n</code></pre>\\n<p>Or, alternatively, consider a similar Python program over unbounded integers:</p>\n<pre><code class=\\"lang-\\">def g(x, y):\\n assert isinstance(x, int) and isinstance(y, int)\\n if y &gt; 0:\\n while x &gt; y:\\n x = x - y\\n</code></pre>\\n<p>Try to answer this question: “Does g always eventually return control back to its caller?”</p>\n<p>When we show this program to industry professionals, they usually figure out the right answer quickly. A few, especially those who are aware of results in theoretical computer science, sometimes mistakenly think that we can’t answer this question, with the rationale “This is an example of the <ins><a href=\\"https://en.wikipedia.org/wiki/Halting_problem\\" target=\\"_blank\\">halting problem</a></ins>, which has been proved insoluble”. In fact, we can reason about the halting behavior for specific programs, including this one. We’ll talk more about that later.</p>\n<p>Here’s the reasoning that most industry professionals use when looking at this problem:</p>\n<p>1、In the case where y is not positive, execution jumps to the end of the function g. That’s the easy case.<br />\\n2、If, in every iteration of the loop, the value of the variable x decreases, then eventually, the loop condition x &gt; y will fail, and the end of g will be reached.<br />\\n3、The value of x always decreases only if y is always positive, because only then does the update to x (i.e., x = x - y) decrease x. But y’s positivity is established by the conditional expression, so x always decreases.</p>\n<p>The experienced programmer will usually worry about underflow in the x = x - y command of the C program but will then notice that x &gt; y before the update to x and thus cannot underflow.</p>\n<p>If you carried out the three steps above yourself, you now have a very intuitive view of the type of thinking an automated-reasoning tool is performing on our behalf when reasoning about a computer program. There are many nitty-gritty details that the tools have to face (e.g., heaps, stacks, strings, pointer arithmetic, recursion, concurrency, callbacks, etc.), but there’s also decades of research papers on techniques for handling these and other topics, along with various practical tools that put these ideas to work.</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/41f19c6eae0e4332a0d258ebe7e84836_%E4%B8%8B%E8%BD%BD%20%281%29.gif\\" alt=\\"下载 1.gif\\" /></p>\n<p>Automated reasoning can be applied to both policies (top) and code (bottom). In both cases, an essential step is reasoning about what’s always true.</p>\n<p>The main takeaway is that automated-reasoning tools are usually working through the three steps above on our behalf: Item 1 is reasoning about the program’s control structure. Item 2 is reasoning about what is eventually true within the program. Item 3 is reasoning about what is always true in the program.</p>\n<p>Note that configuration artifacts such as Amazon Web Services resource policies, VPC network descriptions, or even makefiles can be thought of as code. This viewpoint allows us to use the same techniques we use to reason about C or Python code to answer questions about the interpretation of configurations. It’s this insight that gives us tools like IAM Access Analyzer or VPC Reachability Analyzer.</p>\n<h4><a id=\\"An_end_to_testing_98\\"></a><strong>An end to testing?</strong></h4>\\n<p>As we saw above when looking at f and g, automated reasoning can be dramatically faster than exhaustive testing. With tools available today, we can show properties of f or g in milliseconds, rather than waiting lifetimes with exhaustive testing.</p>\n<p>Can we throw away our testing tools now and just move to automated reasoning? Not quite. Yes, we can dramatically reduce our dependency on testing, but we will not be completely eliminating it any time soon, if ever. Consider our first example:</p>\n<pre><code class=\\"lang-\\">bool f(unsigned int x, unsigned int y) {\\n return (x + y == y + x);\\n}\\n</code></pre>\\n<p>Recall the worry that a buggy compiler or microprocessor could in fact cause an executable program constructed from this source code to return false. We might also need to worry about the language runtime. For example, the C math library or the Python garbage collector might have bugs that cause a program to misbehave.</p>\n<p>What’s interesting about testing, and something we often forget, is that it’s doing much more than just telling us about the C or Python source code. It’s also testing the compiler, the runtime, the interpreter, the microprocessor, etc. A test failure could be rooted in any of those tools in the stack.</p>\n<p>Automated reasoning, in contrast, is usually applied to just one layer of that stack — the source code itself, or sometimes the compiler or the microprocessor. What we find so valuable about reasoning is it allows us to clearly define both what we do know and what we do not know about the layer under inspection.</p>\n<p>Furthermore, the models of the surrounding environment (e.g., the compiler or the procedure calling our procedure) used by the automated-reasoning tool make our assumptions very precise. Separating the layers of the computational stack helps make better use of our time, energy, and money and the capabilities of the tools today and tomorrow.</p>\n<p>Unfortunately, we will almost always need to make assumptions about something when using automated reasoning — for example, the principles of physics that govern our silicon chips. Thus, testing will never be fully replaced. We will want to perform end-to-end testing to try and validate our assumptions as best we can.</p>\n<h4><a id=\\"An_impossible_program_120\\"></a><strong>An impossible program</strong></h4>\\n<p>I previously mentioned that automated-reasoning tools sometimes return “Don’t know” rather than “yes” or “no”. They also sometimes run forever (or time out), thus never returning an answer. Let’s look at the famous “halting problem” program, in which we know tools cannot return “yes” or “no”.</p>\n<p>Imagine that we have an automated-reasoning API, called terminates, that returns “yes” if a C function always terminates or “no” when the function could execute forever. As an example, we could build such an API using the tool described here (shameless self-promotion of author’s previous work). To get the idea of what a termination tool can do for us, consider two basic C functions, g (from above),</p>\n<pre><code class=\\"lang-\\">void g(int x, int y) {\\n if (y &gt; 0)\\n while (x &gt; y)\\n x = x - y;\\n}\\n</code></pre>\\n<p>and g2:</p>\n<pre><code class=\\"lang-\\">void g2(int x, int y) {\\n while (x &gt; y)\\n x = x - y;\\n}\\n</code></pre>\\n<p>For the reasons we have already discussed, the function g always returns control back to its caller, so terminates(g) should return true. Meanwhile, terminates(g2) should return false because, for example, g2(5, 0) will never terminate.</p>\n<p>Now comes the difficult function. Consider h:</p>\n<pre><code class=\\"lang-\\">void h() {\\n if terminates(h) while(1){}\\n}\\n\\n</code></pre>\\n<p>Notice that it’s recursive. What’s the right answer for terminates(h)? The answer cannot be “yes”. It also cannot be “no”. Why?</p>\n<p>Imagine that terminates(h) were to return “yes”. If you read the code of h, you’ll see that in this case, the function does not terminate because of the conditional statement in the code of h that will execute the infinite loop while(1){}. Thus, in this case, the terminates(h) answer would be wrong, because h is defined recursively, calling terminates on itself.</p>\n<p>Similarly, if terminates(h) were to return “no”, then h would in fact terminate and return control to its caller, because the if case of the conditional statement is not met, and there is no else branch. Again, the answer would be wrong. This is why the “Don’t know” answer is actually unavoidable in this case.</p>\n<p>The program h is a variation of examples given in Turing’s <ins><a href=\\"https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf\\" target=\\"_blank\\">famous 1936 paper</a></ins> on decidability and <ins><a href=\\"https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems\\" target=\\"_blank\\">Gödel’s incompleteness theorems</a></ins> from 1931. These papers tell us that problems like the halting problem cannot be “solved”, if by“solved” we mean that the solution procedure itself always terminates and answers either “yes” or “no” but never “Don’t know”. But that is not the definition of “solved” that many of us have in mind. For many of us, a tool that sometimes times out or occasionally returns “Don’t know” but, when it gives an answer, always gives the right answer is good enough.</p>\n<p>This problem is analogous to airline travel: we know it’s not 100% safe, because crashes have happened in the past, and we are sure that they will happen in the future. But when you land safely, you know it worked that time. The goal of the airline industry is to reduce failure as much as possible, even though it’s in principle unavoidable.</p>\n<p>To put that in the context of automated reasoning: for some programs, like h, we can never improve the tool enough to replace the “Don’t know” answer. But there are many other cases where today’s tools answer “Don’t know”, but future tools may be able to answer “yes” or “no”. The modern scientific challenge for automated-reasoning subject-matter experts is to get the practical tools to return “yes” or “no” as often as possible. As an example of current work, check out CMU professor and <ins><a href=\\"https://www.amazon.science/scholars\\" target=\\"_blank\\">Amazon scholar</a></ins> <ins><a href=\\"https://www.cs.cmu.edu/~mheule/\\" target=\\"_blank\\">Marijn Heule</a></ins> and his <ins><a href=\\"https://www.quantamagazine.org/computer-scientists-attempt-to-corner-the-collatz-conjecture-20200826/\\" target=\\"_blank\\">quest to solve the Collatz termination problem</a></ins>.</p>\n<p>Another thing to keep in mind is that automated-reasoning tools are regularly trying to solve “intractable” problems, e.g., problems in the NP complexity class. Here, the same thinking applies that we saw in the case of the halting problem: automated-reasoning tools have powerful heuristics that often work around the intractability problem for specific cases, but those heuristics can (and sometimes do) fail, resulting in “Don’t know” answers or impractically long execution time. The science is to improve the heuristics to minimize that problem.</p>\n<h4><a id=\\"Nomenclature_167\\"></a><strong>Nomenclature</strong></h4>\\n<p>A host of names are used in the scientific literature to describe interrelated topics, of which automated reasoning is just one. Here’s a quick glossary:</p>\n<ul>\\n<li>\\n<p>A logic is a formal and mechanical system for defining what is true and untrue. Examples: <ins><a href=\\"https://en.wikipedia.org/wiki/Propositional_calculus\\" target=\\"_blank\\">propositional logic</a></ins> or <ins><a href=\\"https://en.wikipedia.org/wiki/First-order_logic\\" target=\\"_blank\\">first-order logic</a></ins>.</p>\n</li>\\n<li>\\n<p>A theorem is a true statement in logic. Example: the <ins><a href=\\"https://en.wikipedia.org/wiki/Four_color_theorem\\" target=\\"_blank\\">four-color theorem</a></ins>.</p>\n</li>\\n<li>\\n<p>A proof is a valid argument in logic of a theorem. Example: Gonthier’s <ins><a href=\\"http://www.ams.org/notices/200811/tx081101382p.pdf\\" target=\\"_blank\\">proof of the four-color theorem</a></ins>.</p>\n</li>\\n<li>\\n<p>A mechanical theorem prover is a semi-automated-reasoning tool that checks a machine-readable expression of a proof often written down by a human. These tools often require human guidance. Example: <ins><a href=\\"https://github.com/jrh13/hol-light/\\" target=\\"_blank\\">HOL-light</a></ins>, from Amazon researcher <ins><a href=\\"https://www.cl.cam.ac.uk/~jrh13/\\" target=\\"_blank\\">John Harrison</a></ins>.</p>\n</li>\\n<li>\\n<p>Formal verification is the use of theorem proving when applied to models of computer systems to prove desired properties of the systems. Example: the <ins><a href=\\"https://compcert.org/doc/\\" target=\\"_blank\\">CompCert verified C compiler</a></ins>.</p>\n</li>\\n<li>\\n<p>Formal methods is the broadest term, meaning simply the use of logic to reason formally about models of systems.</p>\n</li>\\n<li>\\n<p>Automated reasoning focuses on the automation of formal methods.</p>\n</li>\\n<li>\\n<p>A semi-automated-reasoning tool is one that requires hints from the user but still finds valid proofs in logic.</p>\n</li>\\n</ul>\n<p>As you can see, we have a choice of monikers when working in this space. At Amazon, we’ve chosen to use automated reasoning, as we think it best captures our ambition for automation and scale. In practice, some of our internal teams use both automated and semi-automated reasoning tools, because the scientists we’ve hired can often get semi-automated reasoning tools to succeed where the heuristics in fully automated reasoning might fail. For our externally facing customer features, we currently use only fully automated approaches.</p>\n<h4><a id=\\"Next_steps_187\\"></a><strong>Next steps</strong></h4>\\n<p>In this essay, I’ve introduced the idea of automated reasoning, with the smallest of toy programs. I haven’t described how to handle realistic programs, with heap or concurrency. In fact, there are a wide variety of automated-reasoning tools and techniques, solving problems in all kinds of different domains, some of them quite narrow. To describe them all and the many branches and sub-disciplines of the field (e.g. “SMT solving”, “higher-order logic theorem proving”, “separation logic”) would take thousands of blogs posts and books.</p>\n<p>Automated reasoning goes back to the early inventors of computers. And logic itself (which automated reasoning attempts to solve) is thousands of years old. In order to keep this post brief, I’ll stop here and suggest further reading. Note that it’s very easy to get lost in the weeds reading depth-first into this area, and you could emerge more confused than when you started. I encourage you to use a bounded depth-first search approach, looking sequentially at a wide variety of tools and techniques in only some detail and then moving on, rather than learning only one aspect deeply.</p>\n<h4><a id=\\"Suggested_books_193\\"></a><strong>Suggested books:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://www.amazon.com/Handbook-Practical-Logic-Automated-Reasoning/dp/0521899575\\" target=\\"_blank\\">Handbook of Practical Logic and Automated Reasoning</a></ins></li>\n<li><ins><a href=\\"https://link.springer.com/book/10.1007/978-1-4612-4222-2\\" target=\\"_blank\\">Temporal Verification of Reactive Systems</a></ins></li>\n<li><ins><a href=\\"https://www.decision-procedures.org/\\" target=\\"_blank\\">Decision Procedures</a></ins></li>\n<li><ins><a href=\\"https://mitpress.mit.edu/books/model-checking-second-edition\\" target=\\"_blank\\">Model Checking</a></ins></li>\n<li><ins><a href=\\"https://softwarefoundations.cis.upenn.edu/current/index.html\\" target=\\"_blank\\">Software Foundations</a></ins></li>\n<li><ins><a href=\\"https://lamport.azurewebsites.net/tla/book.html#download\\" target=\\"_blank\\">Specifying Systems</a></ins></li>\n<li><ins><a href=\\"https://mitpress.mit.edu/books/introduction-static-analysis\\" target=\\"_blank\\">Introduction to Static Analysis</a></ins></li>\n<li><ins><a href=\\"https://www.amazon.com/Logic-Computer-Science-Modelling-Reasoning/dp/052154310X\\" target=\\"_blank\\">Logic in Computer Science: Modelling and Reasoning about Systems</a></ins></li>\n<li><ins><a href=\\"https://functional-algorithms-verified.org/\\" target=\\"_blank\\">Functional Algorithms, Verified!</a></ins></li>\n<li><ins><a href=\\"https://ebooks.iospress.nl/volume/handbook-of-satisfiability-second-edition\\" target=\\"_blank\\">Handbook of Satisfiability</a></ins></li>\n<li><ins><a href=\\"https://link.springer.com/book/10.1007/978-3-540-74113-8\\" target=\\"_blank\\">The Calculus of Computation</a></ins></li>\n</ul>\\n<h4><a id=\\"International_conferencesworkshops_207\\"></a><strong>International conferences/workshops:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://etaps.org/2020/tacas\\" target=\\"_blank\\">https://etaps.org/2020/tacas</a></ins></li>\n<li><ins><a href=\\"http://i-cav.org/2020/\\" target=\\"_blank\\">http://i-cav.org/2020/</a></ins></li>\n<li><ins><a href=\\"https://ijcar2020.org/\\" target=\\"_blank\\">https://ijcar2020.org/</a></ins></li>\n<li><ins><a href=\\"https://popl21.sigplan.org/\\" target=\\"_blank\\">https://popl21.sigplan.org/</a></ins></li>\n<li><ins><a href=\\"https://sat2020.idea-researchlab.org/\\" target=\\"_blank\\">https://sat2020.idea-researchlab.org/</a></ins></li>\n<li><ins><a href=\\"http://smt-workshop.cs.uiowa.edu/\\" target=\\"_blank\\">http://smt-workshop.cs.uiowa.edu/</a></ins></li>\n</ul>\\n<h4><a id=\\"Tool_competitions_216\\"></a><strong>Tool competitions:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"http://termination-portal.org/wiki/Termination_Competition\\" target=\\"_blank\\">http://termination-portal.org/wiki/Termination_Competition</a></ins></li>\n<li><ins><a href=\\"https://sv-comp.sosy-lab.org/2020/\\" target=\\"_blank\\">https://sv-comp.sosy-lab.org/2020/</a></ins></li>\n<li><ins><a href=\\"https://smt-comp.github.io/2020/\\" target=\\"_blank\\">https://smt-comp.github.io/2020/</a></ins></li>\n<li><ins><a href=\\"http://www.satcompetition.org/\\" target=\\"_blank\\">http://www.satcompetition.org/</a></ins></li>\n<li><ins><a href=\\"http://www.tptp.org/CASC/27/\\" target=\\"_blank\\">http://www.tptp.org/CASC/27/</a></ins></li>\n</ul>\\n<h4><a id=\\"Some_tools_224\\"></a><strong>Some tools:</strong></h4>\\n<ul>\\n<li>AGREE: <ins><a href=\\"http://loonwerks.com/tools/agree.html\\" target=\\"_blank\\">http://loonwerks.com/tools/agree.html</a></ins></li>\n<li>Alloy: <ins><a href=\\"https://alloytools.org/\\" target=\\"_blank\\">https://alloytools.org/</a></ins></li>\n<li>Aprove: <ins><a href=\\"https://aprove.informatik.rwth-aachen.de/\\" target=\\"_blank\\">https://aprove.informatik.rwth-aachen.de/</a></ins></li>\n<li>BioModelAnalzyer: <ins><a href=\\"https://biomodelanalyzer.com/\\" target=\\"_blank\\">https://biomodelanalyzer.com/</a></ins></li>\n<li>Boogie: <ins><a href=\\"https://github.com/boogie-org/boogie.git\\" target=\\"_blank\\">https://github.com/boogie-org/boogie.git</a></ins></li>\n<li>CBMC: <ins><a href=\\"https://www.cprover.org/cbmc/\\" target=\\"_blank\\">https://www.cprover.org/cbmc/</a></ins></li>\n<li>Checked C: <ins><a href=\\"https://plum-umd.github.io/projects/checkedc.html\\" target=\\"_blank\\">https://plum-umd.github.io/projects/checkedc.html</a></ins></li>\n<li>Checker Framework: <ins><a href=\\"https://checkerframework.org/\\" target=\\"_blank\\">https://checkerframework.org/</a></ins></li>\n<li>CoCoSim: <ins><a href=\\"https://github.com/NASA-SW-VnV/CoCoSim\\" target=\\"_blank\\">https://github.com/NASA-SW-VnV/CoCoSim</a></ins></li>\n<li>Coq: <ins><a href=\\"https://coq.inria.fr/\\" target=\\"_blank\\">https://coq.inria.fr/</a></ins></li>\n<li>CPA Checker: <ins><a href=\\"https://cpachecker.sosy-lab.org/\\" target=\\"_blank\\">https://cpachecker.sosy-lab.org/</a></ins></li>\n<li>CVC4: <ins><a href=\\"https://cvc4.github.io/\\" target=\\"_blank\\">https://cvc4.github.io/</a></ins></li>\n<li>Dafny: <ins><a href=\\"https://github.com/dafny-lang/dafny\\" target=\\"_blank\\">https://github.com/dafny-lang/dafny</a></ins></li>\n<li>Dreal: <ins><a href=\\"https://github.com/dreal/dreal4\\" target=\\"_blank\\">https://github.com/dreal/dreal4</a></ins></li>\n<li>HOL light: <ins><a href=\\"https://www.cl.cam.ac.uk/~jrh13/hol-light/\\" target=\\"_blank\\">https://www.cl.cam.ac.uk/~jrh13/hol-light/</a></ins></li>\n<li>Infer: <ins><a href=\\"https://fbinfer.com/\\" target=\\"_blank\\">https://fbinfer.com</a></ins></li>\n<li>Iris: <ins><a href=\\"https://iris-project.org/\\" target=\\"_blank\\">https://iris-project.org/</a></ins></li>\n<li>Isabelle: <ins><a href=\\"https://isabelle.in.tum.de/\\" target=\\"_blank\\">https://isabelle.in.tum.de/</a></ins></li>\n<li>Java PathFinder: <ins><a href=\\"https://github.com/javapathfinder\\" target=\\"_blank\\">https://github.com/javapathfinder</a></ins></li>\n<li>JKind: <ins><a href=\\"https://github.com/loonwerks/jkind\\" target=\\"_blank\\">https://github.com/loonwerks/jkind</a></ins></li>\n<li>Keymaera X: <ins><a href=\\"https://keymaerax.org/\\" target=\\"_blank\\">https://keymaerax.org/</a></ins></li>\n<li>Kind2: <ins><a href=\\"https://kind2-mc.github.io/kind2\\" target=\\"_blank\\">https://kind2-mc.github.io/kind2</a></ins></li>\n<li>KLEE: <ins><a href=\\"https://klee.github.io/\\" target=\\"_blank\\">https://klee.github.io</a></ins></li>\n<li>Lean: <ins><a href=\\"https://leanprover.github.io/\\" target=\\"_blank\\">https://leanprover.github.io/</a></ins></li>\n<li>MiniSat: <ins><a href=\\"http://minisat.se/\\" target=\\"_blank\\">http://minisat.se/</a></ins></li>\n<li>Nagini: <ins><a href=\\"https://github.com/marcoeilers/nagini\\" target=\\"_blank\\">https://github.com/marcoeilers/nagini</a></ins></li>\n<li>P: <ins><a href=\\"https://github.com/p-org/P\\" target=\\"_blank\\">https://github.com/p-org/P</a></ins></li>\n<li>PRISM:<ins><a href=\\"https://www.prismmodelchecker.org/\\" target=\\"_blank\\">https://www.prismmodelchecker.org</a></ins></li>\n<li>PVS: <ins><a href=\\"https://pvs.csl.sri.com/\\" target=\\"_blank\\">https://pvs.csl.sri.com</a></ins></li>\n<li>Rosette: <ins><a href=\\"http://emina.github.io/rosette/\\" target=\\"_blank\\">http://emina.github.io/rosette/</a></ins></li>\n<li>Rust programming language: <ins><a href=\\"https://www.rust-lang.org/\\" target=\\"_blank\\">https://www.rust-lang.org/ </a></ins> [When you are programming in Rust you are essentially proving the absence of memory corruption in a type system (assuming you’re not using “unsafe” regions)]</li>\n<li>Sally: <ins><a href=\\"https://github.com/SRI-CSL/sally\\" target=\\"_blank\\">https://github.com/SRI-CSL/sally</a></ins></li>\n<li>SAW: <ins><a href=\\"https://saw.galois.com/\\" target=\\"_blank\\">https://saw.galois.com/</a></ins></li>\n<li>SeaHorn: <ins><a href=\\"http://seahorn.github.io/\\" target=\\"_blank\\">http://seahorn.github.io/</a></ins></li>\n<li>SMACK: <ins><a href=\\"https://smackers.github.io/\\" target=\\"_blank\\">https://smackers.github.io</a></ins></li>\n<li>Soot: <ins><a href=\\"http://soot-oss.github.io/soot/\\" target=\\"_blank\\">http://soot-oss.github.io/soot/</a></ins></li>\n<li>SPIN: <ins><a href=\\"http://spinroot.com/spin/whatispin.html\\" target=\\"_blank\\">http://spinroot.com/spin/whatispin.html</a></ins></li>\n<li>T2: <ins><a href=\\"https://mmjb.github.io/T2/\\" target=\\"_blank\\">https://mmjb.github.io/T2/</a></ins></li>\n<li>TLA+: <ins><a href=\\"https://lamport.azurewebsites.net/tla/tla.html\\" target=\\"_blank\\">https://lamport.azurewebsites.net/tla/tla.html</a></ins></li>\n<li>Vampire: <ins><a href=\\"https://vprover.github.io/\\" target=\\"_blank\\">https://vprover.github.io/</a></ins></li>\n<li>VCC: <ins><a href=\\"https://github.com/microsoft/vcc\\" target=\\"_blank\\">https://github.com/microsoft/vcc</a></ins></li>\n<li>Verifast: <ins><a href=\\"https://github.com/verifast/verifast\\" target=\\"_blank\\">https://github.com/verifast/verifast</a></ins></li>\n<li>Z3: <ins><a href=\\"https://github.com/Z3Prover/z3\\" target=\\"_blank\\">https://github.com/Z3Prover/z3</a></ins></li>\n</ul>\\n<h4><a id=\\"Interviews_of_Amazon_staff_about_their_use_of_automated_reasoning_270\\"></a><strong>Interviews of Amazon staff about their use of automated reasoning:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://www.youtube.com/watch?v=MHON17HzPZI\\" target=\\"_blank\\">Byron Cook PLDI’20 Ask Me Anything</a></ins></li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=J9Da3VsLH44\\" target=\\"_blank\\">Byron Cook on The CUBE</a></ins></li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=CWVehV9PsPQ\\" target=\\"_blank\\">Neha Rungta on The CUBE</a></ins></li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=Awy04VNIFJg\\" target=\\"_blank\\">Neha Rungta discusses constraint-based reasoning tools in Amazon Web Services Config Rules</a></ins></li>\n<li><ins><a href=\\"https://ucl-pplv.github.io/CAV21/poster_P_k15/\\" target=\\"_blank\\">Serdar Tasiran CAV’21 Ask Me Anything</a></ins></li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=le8h_dpqroo\\" target=\\"_blank\\">LogMeIn: How LogMeIn Automates Governance and Empowers Developers at Scale</a></ins></li>\n</ul>\\n<h4><a id=\\"Amazon_Web_Services_Lectures_aimed_at_customers_and_industry_278\\"></a><strong>Amazon Web Services Lectures aimed at customers and industry:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://www.youtube.com/watch?v=BbXK_-b3DTk\\" target=\\"_blank\\">Automating Compliance Verification on Amazon Web Services Using Provable Security</a></ins>, lecture with Amazon Web Services VP of compliance Chad Woolf, and compliance auditor Coalfire’s CEO Tom McAndrew</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=UKqVY0SSbus\\" target=\\"_blank\\">An Amazon Web Services Approach to Higher Standards of Assurance w/ Provable Security</a></ins>, Byron Cook</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=i5apYXya2m0\\" target=\\"_blank\\">Dive Deep into IAM Access Analyze</a></ins>, lecture by Andrew Gacek and others</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=x6wsTFnU3eY\\" target=\\"_blank\\">The Evolution of automated reasoning Technology at Amazon Web Services</a></ins>, lecture with Amazon Web Services VP of security Eric Brandwine</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=Wvyc-VEUOns&amp;t=2214\\" target=\\"_blank\\">Lecture</a></ins> by Amazon Web Services CISO and VP of security Steve Schmidt about on the development and use of formal/constraint-based tools in Amazon Web Services</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=jt-gV1YwmnI&amp;t=2975s\\" target=\\"_blank\\">Re:Invent Keynote</a></ins>, lecture by CTO Werner Vogels</li>\n</ul>\\n<h4><a id=\\"Amazon_Web_Services_talks_aimed_at_the_automatedreasoning_science_community_287\\"></a><strong>Amazon Web Services talks aimed at the automated-reasoning science community:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://ucl-pplv.github.io/CAV21/poster_P_215/\\" target=\\"_blank\\">Debugging Network Reachability with Blocked Paths</a></ins>, CAV’21</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=Y_DeKKhbNUs\\" target=\\"_blank\\">Embedded World 2021: Formally Verifying the FreeRTOS IPC Mechanism</a></ins>, Embedded World '21</li>\n<li><ins><a href=\\"https://youtu.be/JfjLKBO27nw\\" target=\\"_blank\\">Formal reasoning about the security of Amazon Web Services</a></ins>, FLoC 2018 plenary lecture</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=9lPR0d2uijo\\" target=\\"_blank\\">Formal reasoning about the security of Amazon Web Services</a></ins>, OOPSLA/SPLASH 2018 keynote lecture</li>\n<li><ins><a href=\\"https://ucl-pplv.github.io/CAV21/poster_facc_10/\\" target=\\"_blank\\">How I learned to stop worrying and start applying automated reasoning</a></ins>, FACC’21 (other relevant talks at FACC website)</li>\n<li><ins><a href=\\"https://ucl-pplv.github.io/CAV21/poster_facc_10/\\" target=\\"_blank\\">On automated reasoning for compliance certification</a></ins>, CAV workshop on Formal Approaches to Certifying Compliance (FACC)</li>\n<li><ins><a href=\\"https://ucl-pplv.github.io/CAV21/poster_P_315/\\" target=\\"_blank\\">Pre-Deployment Security Assessment for Cloud Services through Semantic Reasoning</a></ins>, CAV’21</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=bO-vfLpFI3I\\" target=\\"_blank\\">Provable Security at Amazon Web Services</a></ins>, USENIX Enigma 2019</li>\n<li>[Skip to 30mins in]: <ins><a href=\\"https://www.facebook.com/ze.jaloto/videos/10157040968367975/\\" target=\\"_blank\\">SideTrail: Verifying Time-Balancing of Cryptosystems</a></ins></li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=TjSQ1P3tM2I\\" target=\\"_blank\\">Stratified abstraction of access control policies</a></ins>, CAV’20</li>\n<li><ins><a href=\\"https://ucl-pplv.github.io/CAV21/poster_P_46/\\" target=\\"_blank\\">Verified Cryptographic Code for Everybody</a></ins>, CAV’21</li>\n<li><ins><a href=\\"https://www.youtube.com/watch?v=sS-x_NQ-CsI\\" target=\\"_blank\\">What is automated reasoning? How Is it Used at Amazon Web Services?</a></ins></li>\n</ul>\\n<h4><a id=\\"Amazon_Web_Services_blog_posts_and_informational_videos_301\\"></a><strong>Amazon Web Services blog posts and informational videos:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/amazon-inspector-assess-network-exposure-ec2-instances-aws-network-reachability-assessments/\\" target=\\"_blank\\">A simpler way to assess the network exposure of EC2 instances: Amazon Web Services releases new network reachability assessments in Amazon Inspector</a></ins></li>\n<li><ins><a href=\\"https://www.allthingsdistributed.com/2019/06/proving-security-at-scale-with-automated-reasoning.html\\" target=\\"_blank\\">AAmazon Web Services CTO blogs about automated reasoning Group: Proving security at scale with automated reasoning</a></ins></li>\n<li><ins><a href=\\"https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html\\" target=\\"_blank\\">Amazon Web Services CTO discusses S3 consistency</a></ins></li>\n<li>Amazon Web Services Podcast interview: <ins><a href=\\"https://aws.amazon.com/blogs/security/provable-security-podcast-automated-reasonings-past-present-and-future-with-moshe-vardi/?fbclid=IwAR1lHco10mnp7yPEDwUFMgMCpCMoKVIxKOCGLGvwEUzHoL1TAW_cWAwoD8w\\" target=\\"_blank\\">Provable security podcast: Byron interviews Moshe Vardi</a></ins></li>\n<li>Amazon Web Services Podcast interview: <ins><a href=\\"https://aws.amazon.com/podcasts/aws-podcast/#266\\" target=\\"_blank\\">Next Generation Security with automated reasoning, an Artificial Intelligence Technology</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/aws/aws-config-update-new-managed-rules-to-secure-s3-buckets/\\" target=\\"_blank\\">Blog post</a></ins> about event-driven checks in <ins><a href=\\"https://aws.amazon.com/config/\\" target=\\"_blank\\">Amazon Web Services Config</a></ins> powered by automated constraint solving techniques over IAM policies [<ins><a href=\\"https://awsnyc17.smarteventscloud.com/connect/sessionDetail.ww?SESSION_ID=121651\\" target=\\"_blank\\">attend this session at NY summit</a></ins>] … and <ins><a href=\\"https://aws.amazon.com/blogs/mt/example-scenarios-for-aws-config-continuous-monitoring-of-amazon-s3-bucket-access-controls/\\" target=\\"_blank\\">more detail</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/aws/new-amazon-s3-encryption-security-features/\\" target=\\"_blank\\">Blog post</a></ins> on the use of constraint-based reasoning about policies in the Amazon Web Services S3 console</li>\n<li>Blogs <ins><a href=\\"https://galois.com/blog/2016/09/verifying-s2n-hmac-with-saw/\\" target=\\"_blank\\">1</a></ins>, <ins><a href=\\"https://galois.com/blog/2016/09/specifying-hmac-in-cryptol/\\" target=\\"_blank\\">2</a></ins>, and <ins><a href=\\"https://galois.com/blog/2016/09/proving-program-equivalence-with-saw/\\" target=\\"_blank\\">3</a></ins> about work with <ins><a href=\\"https://galois.com/\\" target=\\"_blank\\">Galois</a></ins> to prove the correctness of Amazon’s crypto infrastructure component <ins><a href=\\"https://aws.amazon.com/blogs/security/introducing-s2n-a-new-open-source-tls-implementation/\\" target=\\"_blank\\">s2n</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/aws-security-profiles-chad-woolf-vp-of-aws-security/\\" target=\\"_blank\\">Chad Wolff (VP of compliance at Amazon Web Services) discusses his interest in using automated reasoning to simplify and raise the bar on compliance certification</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/automated-reasoning-provable-security-of-boot-code/\\" target=\\"_blank\\">Daniel Schwartz-Narbonne shares how automated reasoning is helping achieve the provable security of Amazon Web Services boot code</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/storage/how-automated-reasoning-helps-us-innovate-at-s3-scale/\\" target=\\"_blank\\">How automated reasoning helps us innovate at S3 scale</a></ins></li>\n<li><ins><a href=\\"https://www.amazon.science/blog/how-automated-reasoning-improves-the-prime-video-experience\\" target=\\"_blank\\">How automated reasoning improves Prime Vdeo experience</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/how-aws-sidetrail-verifies-key-aws-cryptography-code/\\" target=\\"_blank\\">How Amazon Web Services SideTrail verifies key Amazon Web Services cryptography code</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/\\" target=\\"_blank\\">How Amazon Web Services uses automated reasoning to help you achieve security at scale</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/aws/aws-iot-device-defender-now-available-keep-your-connected-devices-safe/\\" target=\\"_blank\\">Jeff Barr about tools for IoT configuration verification</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/aws/new-vpc-insights-analyzes-reachability-and-visibility-in-vpcs/\\" target=\\"_blank\\">On VPC Reachablity Analyzer</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/about-aws/whats-new/2018/09/aws-config-announces-new-managed-rules/\\" target=\\"_blank\\">New (Zelkova-based) Amazon Web Services Config rules s3-blacklisted-actions-prohibited and bucket-policy-not-more-permissive are released</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/podcast-automated-reasoning-aws-next-gen-security-ai/\\" target=\\"_blank\\">Podcast: AI tech named automated reasoning provides next-gen cloud security</a></ins></li>\n<li>Some detail about constraint-based IAM policy analysis used in <ins><a href=\\"https://aws.amazon.com/macie/\\" target=\\"_blank\\">Amazon Macie</a></ins> can be found <ins><a href=\\"http://docs.aws.amazon.com/macie/latest/userguide/macie-research.html#s3bucketsdata\\" target=\\"_blank\\">here</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/devops/tightening-application-security-with-amazon-codeguru/\\" target=\\"_blank\\">Tightening application security with Amazon CodeGuru</a></ins></li>\n<li><ins><a href=\\"https://freertos.org/2020/12/using-formal-methods-to-validate-ota-protocol.html\\" target=\\"_blank\\">Using Formal Methods to validate OTA Protocol</a></ins></li>\n<li><ins><a href=\\"https://aws.amazon.com/blogs/security/tag/automated-reasoning/\\" target=\\"_blank\\">… more Amazon Web Services blogs</a></ins></li>\n</ul>\\n<h4><a id=\\"Some_course_notes_by_Amazon_Scholars_who_are_also_university_professors_326\\"></a><strong>Some course notes by Amazon Scholars who are also university professors:</strong></h4>\\n<ul>\\n<li><ins><a href=\\"https://courses.cs.washington.edu/courses/cse507/21au/\\" target=\\"_blank\\">https://courses.cs.washington.edu/courses/cse507/21au/</a></ins></li>\n<li><ins><a href=\\"http://www.cs.cmu.edu/~mheule/15816-f21/\\" target=\\"_blank\\">http://www.cs.cmu.edu/~mheule/15816-f21/</a></ins></li>\n<li><ins><a href=\\"https://www.cs.cmu.edu/~mheule/15217-f21/\\" target=\\"_blank\\">https://www.cs.cmu.edu/~mheule/15217-f21/</a></ins></li>\n</ul>\\n<h4><a id=\\"A_fun_deep_track_332\\"></a><strong>A fun deep track:</strong></h4>\\n<p>Some algorithms found in the automated theorem provers we use today date as far back as 1959, <ins><a href=\\"https://dl.acm.org/doi/abs/10.1147/rd.41.0002\\" target=\\"_blank\\">when Hao Wang used automated reasoning to prove the theorems from</a></ins> <ins><a href=\\"https://dl.acm.org/doi/abs/10.1147/rd.41.0002\\" target=\\"_blank\\">Principia Mathematica.</a></ins></p>\n<p>ABOUT THE AUTHOR</p>\n<h4><a id=\\"Byron_Cookhttpswwwamazonscienceauthorbyroncook_338\\"></a><strong><a href=\\"https://www.amazon.science/author/byron-cook\\" target=\\"_blank\\">Byron Cook</a></strong></h4>\n<p>Byron Cook is a leader in the field of formal verification, known for his contributions to SAT, SMT, and symbolic model checking, with applications to biological systems, computer operating systems, programming languages, and security. Byron’s work on automated reasoning at Amazon has led to higher levels of assurance in the cloud as well as new customer features.</p>\n"}