Error sinks are a way of accumulating errors from API calls related or unrelated into 1 unified error handling pattern. The implementation of a sink requires 2 fundamental design constraints on the APIs supporting this pattern.
Pipelining of errors
Errors emitted over the course of several API calls are accumulated into a sink which save the error code and message of the first error encountered
| Complete stuff: | |
| https://xmonader.github.io/letsbuildacompiler-pretty/ | |
| Lexers + DFAs: | |
| https://gist.github.com/pervognsen/218ea17743e1442e59bb60d29b1aa725 | |
| Parsing: | |
| https://eli.thegreenplace.net/2012/08/02/parsing-expressions-by-precedence-climbing | |
| Backend: |
Official patch: https://chromium-review.googlesource.com/c/v8/v8/+/4584248
Patch come from KeyedStoreIC::StoreElementHandler(), it returns fast path code(Turbofan builtin) for keyed store depends on "receiver_map" and "store_mode". Based on the content of this function is all about element STORE, I personally believe that this is an OOB writes vulnerability.
If we divide the PoC exploration into two parts based on this func, they are:
| #include <stdio.h> | |
| #include <vector> | |
| #include <span> | |
| #include <algorithm> | |
| // Based on | |
| // "An O(NP) Sequence Comparison Algorithm" by Sun Wu, Udi Manber and Gene Myers | |
| // - https://publications.mpi-cbg.de/Wu_1990_6334.pdf | |
| // - Good article visualizing Myer's older algorithm: https://epxx.co/artigos/diff_en.html | |
| // |
| # Reverse-mode automatic differentiation | |
| import math | |
| # d(-x) = -dx | |
| def func_neg(x): | |
| return -x, [-1] | |
| # d(x + y) = dx + dy | |
| def func_add(x, y): |
When you have GC pointers (pointers to JS objects, strings, etc.; anything stored directly in the GC heap), you need to handle them specially if they could ever be stored during a collection. I'll first describe what you need to do, then how to do it, and finally why and what happens if you get it wrong.
tracing - strong GC references must be traced so that the GC knows what to keep alive.
pre-write barriers aka delete barrier - if you overwrite a GC pointer, you'll need to let the GC know.
post-write barriers - after storing a GC pointer somewhere, you need to inform the GC of the new value (or more specifically, the address of the new value.)
