Re: z80 *ix...
Hey, recently a friend of mine mentioned something called UZI to me, which supposedly was/is a *ix for the z80, and ported to the z280. Anyone else more familiar on it? oak.oakland.edu:/pub/cpm/uzi
Re: SV: Capabilities
Thor Harald Johansen wrote: The Psion 3a have a simple memory protection of a range of address that the program may write to, if a write outside these is attempted then an interrupt is trigger - I will probably attempt to use this once I have code. However it is possible for a malicious program (i.e. the stuff I have done so far) to defeat this. Well, can memory be protected at all on an 8086? -- Thor Harald Johansen [EMAIL PROTECTED] Not as such; the Psion hardware includes a rudimentary MMU. The processor is an NEC V30H. -- Matt J. Gumbley
File Systems
With the new 2.2 kernel out, what is the latest level of support for the NT file system 'NTFS' and the OS/2 file system HPFS?
RE: Capabilities
It seems like the answer to the protection problem is to write a virtual cpu to run under the kernal that would trap memory code, check it, then execute it it's self. Chris
Re: Capabilities
In message [EMAIL PROTECTED], Chris Hansen wrote: It seems like the answer to the protection problem is to write a virtual cpu to run under the kernal that would trap memory code, check it, then execute it it's self. If it is really for embeded systems, than it is no problems - usually embedded systems (with microcontrollers or DSPs) have no MMU or users or protected memory. These systems are supposed to be installed and thats it. bernd -- Bernd Petrovitsch Institute of Computer Technology Gußhausstraße 25-29, A-1040 Vienna Email: [EMAIL PROTECTED] "Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt." A. Einstein PGP signature
RE: SV: Capabilities
On Monday, June 07, 1999 8:43 AM, Thor Harald Johansen [SMTP:[EMAIL PROTECTED]] wrote: : No without a special added hardware. The I8086, 8088, 80188, 80186 : have no memory protection implemented. First chip from Intel which : has memory protection is 80286 as I know. : : If this is correct, the users in ELKS are just symbolic. Any program can do : what it wants, and every user with a program can get root access. BIG : problem. : -- : Thor Harald Johansen : [EMAIL PROTECTED] : That's why 286's and 386's were invented
RE: SV: Capabilities
Surely the point of ELKS is that it's an *embedded* Linux system (routers, settop boxen, etc), so even if multi-user is a possibility, it's not a major design feature, eh? And if we're sticking the netstack in userspace, this re-enforces the principle that "C2 compliant" multi-user environment is a secondary point. Let alone the programming nightmare a netstack in userspace presents to a coder fx:unfond memories of coding network daemons for BeOS, who's netstack is also in userspace I have to agree that in the interest of speed and code size that security isn't that important, and especially on an embedded system. My suggestion would be to use a 386 or other system is if that's really an issue, or maybe find a way to add memory protection to a special version of ELKs destened for the 286 (the 186 doesn't have memory protection as well, does it?). Dan
RE: Capabilities
On Mon, 7 Jun 1999, Chris Hansen wrote: It seems like the answer to the protection problem is to write a virtual cpu to run under the kernal that would trap memory code, check it, then execute it it's self. Chris That would be a very bad idea anyway. The performace hit would be at least 50% and people using embedded chips or 8086/8088 chips would suffer greatly for a unimportant cause. If security is an issue, then it is much more cost effective/wise to run Linux on a 386 or better processor. Th 8088 was never designed to provide memory protection, and the effect of trying to add it would result in much buggy annoying code that is unmaintainable, unworkable and unportable. My 5cents (we don't have 2c coins over in Australia) Beau Kuiper [EMAIL PROTECTED]
