221–230 of 528 posts
Earlier quoted context omitted.
How much money is lost by consumers/businesses for every hour the vulnerability is exploited in the wild with no patch?
The value of the report is dependent on the scarcity of the knowledge. If anybody can report it, the bid goes down.
Earlier quoted context omitted.
Yeah
It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
Earlier quoted context omitted.
I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.
In fairness, in the early 2000s they were probably right. Early browser security model was a bit of a mess. The fact that this article is even talked about is a sign of how much better things are.
Earlier quoted context omitted.
It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.
It's damn near impossible to verify that the JIT is correct.
But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law.
(V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)
I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
They just released a CVE for a garbage truck vulnerability where an attacker could brick the vehicle by exploiting the telemetry system these things now have preinstalled in factory.
[flagged]
Sounds wild. (Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
Earlier quoted context omitted.
Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT. I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's e…
I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
Earlier quoted context omitted.
Firefox with uBlock Origin. It’s astonishing how many exploits uBO stops before they ever reach your browser engine. It’s the antivirus of the 2020s.
[flagged]
Sounds wild. (Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
Is that just the MiniBrowser?! I have to say I can't imagine daily driving that if so. Why WebKit over a Chromium-based (and more featureful) browser?
WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object.
On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap.
Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.