Maybe what we have here is another translation problem? involving "user mode"?
My understanding of How Things Work is that most architectures provide for two modes of end, "user mode" and "supervisor mode" (a.k.a. "kernel mode"), with some instructions only allowed to be done by programs running in supervisor mode. So when you said "loaded as a user mode program", I buttumed you meant "in user mode" in this sense. That *would* limit to some extent the damage, although .... Under Unix-Linux, a program running in user mode but as user "root" could still do a lot of damage. I'm guessing something similar applies to other systems. I'm also remembering that some systems have a notion of more than two levels of privileges ("rings"?) ....
Yes. This is a problem. I would *think* that reasonable solutions might involve only accepting applets from "trusted" IP addresses, with some sort of verification that the code really does come from the trusted address .... I'm way out of my depth here, though, with regard to knowing how feasible it is to set up something reasonably bullet-resistant along these lines. Network-related security seems to be full of potential pitfalls.
See below for what little I have to say about the advisability of letting the o-s vendor have free access to one's system.
The trick was RSX11M and the big boy M+ were real-time OS's that did...
What I was imagining was a situation in which Driver 10-ABCDE-etc. is downloaded from, oh, whatever pops up first on a Google search; i.e., from some random source that one knows nothing about. Even more unsettling, no?
Very likely :-). I've been trying to use Unix terms but I think I'm getting the subsbreastutions all f***ed up. Yes...
the original (release 1) cp-67 scheduler (what i initially saw when they brought it out to the univ. in jan. 1968) was effectively a multi-level round-robin...
Hm. Okay, clear enough. It seems to me that this would be reasonable if there were some bullet-resistant way to be sure the updates came from a trusted source. Of course, if you don't trust your o-s vendor in the first place .... :-)? Or maybe :-(.
Ever talk to any non-o-s people who write mulbreasthreaded code -- and do it well? I can't imagine how one could do a good job of writing parallel-mulbreasthreaded applications code without understanding concurrency, the potential for race conditions, etc. I'm willing to believe that doing a good job of writing o-s code requires additional skills, but this seems to me like a start ....
Well, the restriction is enforced by the Java runtime system on the computer where the code executes. I suppose if *that* is supplied by Microsoft .... Right.
I guess it might be somewhat relevant to ask .... At some point there was a dispute between Sun and Microsoft about what Java-related code MS could and could not distribute. I remember that there was a dispute, but not the outcome.
This is the "automatically run uudecode if the first word is 'begin'" thing? something like that? Yeah.
Good point. But -- "tough but not impossible", no? so a security model that makes dangerous-but-sometimes-useful things impossible might need revision.
-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.