undefined | Better HN

0 pointssaagarjha5y ago0 comments

No, these are reasonable questions, they just miss the fact that Apple ships JavaScriptCore with a JIT. By not allowing JITs in third party apps Apple claims they are the only ones who can write a secure JIT (obviously false) and that their platform sandbox is too weak to stand up to arbitrary code execution. Plus, it’s not like normal code doesn’t have buffer overflows or other security issues. As for the tuning on the VM: perhaps in isolation. But again, the high performance JIT exists; it’s just not available to anyone else.

0 comments

2 comments · 1 top-level

dev_tty015y ago· 1 in thread

Yes, you are right that they allow their own JIT. Their position would be that they spend a great deal of time hardening that JIT and don't trust others to take that time. Their JIT isn't perfect of course, but they control it and can fix it fast if needed. (In their opinion.) They are really saying that they aren't willing to take the time to exhaustively test other JITs. That is a frustrating choice, but I do understand the thinking.

You raise the bigger point. Is there no way for their platform sandbox to handle the concerns? That is a great question.

>Plus, it’s not like normal code doesn’t have buffer overflows or other security issues.

I think normal code on an M1 only runs in rx memory blocks [0,1], so no buffer overflow attacks. At least not without another attack to remap the blocks. This might go back to A12 processors. M1 strengthened the model.

Perhaps with these newer processors, the hardware support can harden the sandbox enough to allow more flexibility. One can hope...

[0] https://blog.svenpeter.dev/posts/m1_sprr_gxf/ [1] https://siguza.github.io/APRR/

saagarjhaOP5y ago

You’re exactly right about this being their position. The problem is that their position is not necessary grounded in fact: WebKit certainly isn’t a perfect browser engine, and arguably it might not even be the most secure one. However, it is not Apple’s job to test anything: it’s not like they are currently responsible for finding security issues in apps right now. Basically their position is:

“We work hard to make our engine secure. We don’t think anyone else should try.”

“But here’s a security issue in your engine. Can I use this other one which I think does a better job? Can I even try?

“No.”

FWIW, W^X is generally implemented by all good JITs these days because it’s a good idea. I’m sure the if given the opportunity browsers would adopt this, just like they’ve adopted sandboxing on macOS despite there being zero documentation or support for that interface. It’s just that Apple does not even allow them to do so on iOS. (Also, W^X does mot protect against all buffer overflow attacks.)

j / k navigate · click thread line to collapse