faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @09:37
|
"The other problem with JITing runtimes tends to be memory pressure, which
impacts desktop performance far more than CPU overhead these days."
These problems can easily eliminated by caching the results. The advantage is
that you can do best-case optimizations that a static compiler can't afford, - if the worst-case happens a dynamic compiler can still recompile at runtime. But that doesnt mean that it needs to happen frequently.
"I think most of the advantages of JIT compiled code are bogus. Security is not to me a convincing argument as the only security you gain is via type-checking, which is not fine grained enough for real world security. "
There are two things that you need for Java-like sandboxing:
1. you need to integrate security checks in all libraries that communicate with the world outside of the process/VM and should be used by the sandbox'd code
2. you need to make sure that the only way to access any part of the system is using the public APIs
With native code, number 2 becomes very hard.
"For instance you can prove the code does not use the File object, but you cannot restrict which files it can access and when (at least, not without seriously hacking the class library sources itself)."
Java allows this:
http://java.sun.com/j2se/1.4.2/docs/api/java/io/FilePermission.html
"A worse-is-better approach seems to be an SELinux style one, where security is applied at the process level rather than the type level, but policy is easier to specify and more flexible."
This allows only very low-level security. For example Java allows that applets in a sandbox can create windows, but only if the window has a large warning sign. Try enforcing that with SELinux.
"CPU independence - please. The CPU is already abstracted by the compiler, no
need to do it twice given the dominance of x86 (on the desktop, it may be
more useful on the server)."
Even if there would be only x86, there are already more than enough variants through extensions. 32-bit and 64-bit, MMX, 3DNow, SSE, SSE2...
Managed code also has the advantage that it will give x86 CPU vendors more room for improvement. Right now they have the problem that even if they come up with a good (low-level) extension, there will hardly any software that makes use of it.
"Easier to examine the code: well, there is no rule that says you cannot have reflective native code, and indeed gcj/java does exactly this."
That's examining at runtime and not what I meant. I was talking about analysing and modifying programs that are stored on the disk in their distribution format. |
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
