-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
Related:
https://news.ycombinator.com/item?id=27334855
https://www.google.com/search?q=%22christopher+domas%22+x86+...
https://en.wikipedia.org/wiki/Alternate_Instruction_Set
>"In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.[5] Domas had partially reverse engineered the AIS instruction set using automated fuzzing against a cluster of seven thin clients.[12] Domas used the terms "deeply embedded core" (DEC) plus "deeply embedded instruction set" (DEIS) for the RISC instruction set, "launch instruction" for JMPAI, "bridge instruction" for the x86 prefix wrapper, "global configuration register" for the Feature Control Register (FCR), and documented the privilege escalation with the name "Rosenbridge".[5]"
Also -- I should point out that the debate of if x86 (CISC) CPU's contain RISC cores -- is largely academic.
Both RISC and CISC CPU's contain ALU's -- so our only debate, really, if we have one, is how exactly data that the ALU is going to process -- is going to wind up at the ALU...
It is well known in the x86 community that the x86 instructions are an abstraction, a level of abstraction which runs on top of lower-level of abstraction, the x86 microcode layer...
Historically, intentionally or unintentionally, most x86 vendors have done everything they can to hide, obfuscate, and obscure this layer... There (to the best of my knowledge, at this point in time) is no official documentation of this layer, how it works (etc., etc.) from any any major x86 vendor.
x86 microcode update blobs -- are binary "black boxes" and encrypted.
Most of our (limited) knowledge in this area comes from various others who have attempted to understand the internal workings of x86 microcode:
https://www.google.com/search?q=%22reverse+engineering+x86+p...
https://github.com/RUB-SysSec/Microcode
https://twitter.com/_markel___/status/1262697756805795841
https://www.youtube.com/watch?v=lY5kucyhKFc
It should be pointed out that even if a complete understanding of x86 microcode were to be had for one generation of CPU -- there would always be successive generations where that implementation might change -- leaving anyone who would wish to fully understand it, back at square one...
Got interested in amd29k for about a week before finding something else to mess with. Quick attempt at ghidra support, but never really RE'd with it, so no clue how does on larger projects.
https://github.com/mumbel/ghidra_a29k
I tried searching the spec [1] for "overflow" and here is what it says at page 17:
> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.
> For general signed addition, three additional instructions after the addition are required
Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is the most often used instruction and they suggest that we should replace each one with four?
Their "rationale" is not rational at all. It doesn't make sense.
Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. As a result, there will be errors and vulnerabilities. A vicious circle.
[1] https://github.com/riscv/riscv-isa-manual/releases/download/...
Python has abritrary integer size. However, it runs on machines with a fixed word size. This means internally it has to perform overflow checking, explicitly propagate carries, take great care with magnitudes of inputs etc all over the dang place. Like, seriously, everywhere. Take a look: https://github.com/python/cpython/blob/main/Objects/longobje...
Javascript stores its integers in the mantissa of a floating point NaN and bloody hell that leads to an incredible amount of pain and misery.