corsix

There's good evidence for mask registers and x87 registers sharing the same hardware on recent Intel chips: https://travisdowns.github.io/blog/2020/05/26/kreg2.html

An Intel Haswell chip, when doing floating point vector operations, can dispatch one addition per cycle, or two fused-multiply-add. The latency is worse for the FMA (5 cycles versus 3 cycles), but if you've got enough parallel accumulations to hide that latency, then using FMAs for addition will be faster than addition.

This is a consequence of Intel optimising for FLOPs (or - equivalently - for matrix multiplication), as an FMA counts as two FLOPs, versus addition counting as just one.

Concretely, https://twitter.com/corsix/status/948670437432659970 can be used to get both `movzx rax, byte [somekerneladdress]` and `movzx rax, byte [rax+someusermodeaddress]` executed speculatively (the idea behind this is the same as a retpoline - exploit the fact that `ret` is predicted to return to just after the "matching" `call` instruction). If the first load is executed speculatively, it won't cause a page fault.

Implementations of meltdown do not need to trigger a page fault (because the instruction which would fault can be made to execute speculatively - in addition to the instruction which leaks information into the cache executing speculatively). Accordingly, there would be nothing for the kernel to observe or respond to.

Only if __STDC_IEC_559__ is defined, which implementations are not required to do (in C++, the equivalent is std::numeric_limits<float>::is_iec559).

The end of the post alludes to part 2 ("how to adapt nd_print into something which can behave like the %e, %f, and %g formats of sprintf"), which alas I've yet to get around to writing. There'll also be at least one more part after that detailing the bag of performance tricks which can be used to turn the described algorithm into something very competitive. Alternatively, you can jump to the conclusion by just reading the implementation I wrote for LuaJIT [1], though obviously that won't give you the narrative of _why_ things are the way they are.

[1] https://github.com/LuaJIT/LuaJIT/blob/cf2dfaf3b4eef9b2de32d3...

The solution is included in 2.1.0-beta3: "LuaJIT for x64 can optionally be built for LJ_GC64 mode by enabling the -DLUAJIT_ENABLE_GC64 line in src/Makefile or via 'msvcbuild.bat gc64'." "This mode removes the 32 bit limitation for garbage collected memory on 64 bit systems." [0]

[0] https://www.freelists.org/post/luajit/LuaJIT210beta3

The commit author doesn't tell the whole story: the long description on most of the recent commits mention somebody else.

IDA certainly complains a lot when it sees this.

Thanks for the hug of death - I've turned on more aggressive CloudFlare caching.

They've explored that route - and at least in my case, I so almost very nearly accepted their offer.

Try building (the `v2.1` branch of) LuaJIT with `CFLAGS=-DLUAJIT_ENABLE_GC64`. This flag is a relatively recent addition [1], and didn't have JIT support on x64 until really very recently [2], but it should free you from the 4gb limitation.

[1] https://github.com/LuaJIT/LuaJIT/commit/a92e73023353e59405eb... [2] https://github.com/LuaJIT/LuaJIT/commit/2868715d80b6ac497a7f...

Finding someone who is competent, willing, and available is remarkably difficult.

Or patch the export table of the exporting DLL in addition to the import table of every current importing DLL (as future importing DLLs will look in the export table).

For reference, this has been fixed in LuaJIT master (with an instruction length decoder).

I am very pleased to see people building upon my Lua bytecode research, and I wouldn't be surprised to see more applications with embedded Lua which are exploitable like this.