[gclist] Java manchines and when to collect.
Fri, 12 Dec 1997 14:13:30 GMT
Jeremy Fitzhardinge <email@example.com> wrote:
| Java's sandbox approach to security is one of the less interesting
| things about it, and certainly not essential to the language. Any Java
| implementation must allow access outside the sandbox to be at all
| useful; even code within the sandbox must get access to software on the
I can't let that go unchallenged - the motivating constraint behind the
design of Java was to allow the bytecode format to be automatically
verified cheaply at class-load time, and to prevent dangerously
inconsistent class files from interacting to break the security model.
You may think it's not an interesting property of the language, but it
is the property that strongly shaped its design after the Oak team
gave up on C++ as fundamentally unfixable for their purposes. You
can ignore this aspect and treat Java _with native methods_ as just
another general-purpose programming language.
Although a lot of the sandboxing technology influenced the JVM and
bytecodes directly, the knock-on effects on the language are clearly
1) absolute type-safety - no program has arbitrary undefined results
exceptions rather than crashes.
2) Completely determined and simple consistent semantics (although not
necessarily well documented!), so that load-time verification is
tractable, efficient and secure. This is why the type system is
very simple, for instance.
3) garbage collection an absolute requirement, memory can only be
allocated as an object via the initialization protocol.
4) extra-linguistic features (native methods) treated as privileged
and rejected by the verifier. They happen to be there to support the
"system" aspects of the JVM, ie "kernel mode", and implement
low-level hardware specific code. They are not part of the
language per se.
| The type safety aspects of Java are distinct from the sandbox,
Without type-safety the sandbox is useless, without sandbox the
type-safety is broken (just load some native methods to do an
To me this feels like type-safety and sandbox are intimately bound up
Parts of the sandbox are implemented in Java, parts in the VM, and
parts in native code. The point about Java is that pure Java alone
could not implement its own sandbox other than by complete emulation -
there is a hard restriction on the reflection it provides. For the
same reason you can't implement Java's GC in pure Java. Both of these
require level shifting (of data<=>code in one case, object<=>memory in
In fact aren't there some interesting theoretical research issues in
designing type-systems that can be secure, and yet give a language
the power to write its own storage-manager/GC ?? (Getting back to
| Of course, merely having a typesafe language and a sandbox with
| constrained accesses doesn't give you security. Java implementation
| have so far completely ignored the problem of denial of service attacks
| which are much harder to deal with.
Tackling denial of service, a less serious problem, doesn't require
any key technology, merely the ability to monitor for suspicious
over-use of resources, and to apply quotas for those resources.
Frankly I suspect it hasn't been addressed much because it's rather
dull to implement! People would only bother using denial of service
if they can't break a system any other way, so searching for flaws in
the sandbox has been of greater important initially.
[ firstname.lastname@example.org | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]