| ▲ | roschdal 5 hours ago |
| JIT compilation is unsecure. |
|
| ▲ | stevefan1999 2 hours ago | parent | next [-] |
| So what, are you willing to go away from von-neumann architecture where instructions are data and data are instructions, i.e. the instruction-data hominocity that underpins JIT compilation? Are you willing to go to a pseudo-Harvard architecture where the ability of JIT compiling is soft locked by other means like VM or strong code authentication or policy protection, which is what Apple is doing. Fun fact: even Apple themselves have JIT. JavaScriptCore on iOS has JIT, it's just that the App Store policies forbid any application submissions with JIT or trying to mmap/mprotect an executable region. There used to be apps on TrollStore that runs JIT |
|
| ▲ | asdfsa32 4 hours ago | parent | prev | next [-] |
| You're entirely correct because JIT requires violating Write xor Execute security policy. This is the reason on iOS, it is limited to Apple shipped software. https://en.wikipedia.org/wiki/W%5EX |
| |
| ▲ | codethief 2 hours ago | parent | next [-] | | GrapheneOS heavily restricts JIT usage, too: > - Android Runtime Just-In-Time (JIT) compilation/profiling is fully disabled and replaced with full ahead-of-time (AOT) compilation. The only JIT compilation in the base OS is the V8 JavaScript JIT which is disabled by default for the Vanadium browser with per-site exception support. > - Dynamic code loading for both native code or Java/Kotlin classes is blocked for nearly the entire base OS. […] > - Dynamic code loading for both native code or Java/Kotlin classes can be disabled for user installed apps via 3 exploit protection toggles: […] https://grapheneos.org/features | |
| ▲ | shakna 4 hours ago | parent | prev [-] | | The wiki page mentions this is only a minor problem. Because everyone just writes, then switches and executes. | | |
|
|
| ▲ | sebzim4500 4 hours ago | parent | prev | next [-] |
| Maybe, but surely there are users who are willing to trust all users of their db instance. |
| |
| ▲ | asdfsa32 4 hours ago | parent [-] | | The issue is that it restricts from locking-down and securing the system with Write xor Execute memory. So it has system wide implication. https://en.wikipedia.org/wiki/W%5EX | | |
| ▲ | PhilipRoman 4 hours ago | parent [-] | | W^X is typically per mapping, not per memory page and does not interfere with JIT compilation. | | |
| ▲ | asdfsa32 3 hours ago | parent [-] | | Sure, but it still means that the OS has to decide who is allowed to do it and to what extent. Sophisticated worms like Stuxnet would be much harder with strict W^X for example, since CVE-2010-2568 and the like would be much harder to execute. | | |
| ▲ | orf 3 hours ago | parent | next [-] | | > Sure, but it still means that the OS has to decide who is allowed to do it and to what extent It has to do that anyway? | | |
| ▲ | asdfsa32 2 hours ago | parent [-] | | Only if it wants to allow Writable Memory to become Executable, or basically, allow JIT. |
| |
| ▲ | pjmlp 3 hours ago | parent | prev [-] | | Signed binaries with the proper assigned OS capabilities. | | |
| ▲ | asdfsa32 2 hours ago | parent [-] | | Yes, but with JIT, you can't really verify what the application does upfront. That is the entire point. | | |
| ▲ | pjmlp 2 hours ago | parent | next [-] | | Capabilities are a way to control that, and the point being that only responsible proven applications get the certificate, hence how it all goes on iOS. | | |
| ▲ | asdfsa32 2 hours ago | parent [-] | | You're making the assumption that "responsible" is something provable, but that is not the case, it is specially not easy to prove software is secure from tampering its behaviour. | | |
| ▲ | pjmlp 26 minutes ago | parent [-] | | For that there is bytecode verification as intermediate step, and if you want to go crazy with security, hardware memory tagging with capabilities. Which at this point most companies would rather save money and forbid JIT altogether. Note that mainframes and micros have JIT environments that aren't at the same safety level as regular desktop PCs. For example, https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an... |
|
| |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
|
|
|
|
|
|
| ▲ | dennis16384 5 hours ago | parent | prev | next [-] |
| It is the core of ClickHouse for example, for many years. Is it secure enough in your opinion? |
|
| ▲ | JackSlateur 3 hours ago | parent | prev | next [-] |
| In rust, is jit equivalent to an "unsafe" block ? |
| |
| ▲ | brabel an hour ago | parent [-] | | Read the code in the post. Everything is written in unsafe Rust. The assembly itself knows no memory safety at all and is completely up to the programmer skill whether it can be trusted to not mess up. |
|
|
| ▲ | pjmlp 3 hours ago | parent | prev [-] |
| Machine code is insecure, we should all run interpreted code in a formally verified interpreter. Alternatively, only allow for the execution of cryptographly signed static linked binaries, this naturally includes the interpreter above. |
