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]
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 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: 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: 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: File Systems
The kernel docs say that hpfs is read only, and NTFS is read only, with experimental write. (Use at your own risk). Those are the 2.2.0 docs however. I saw a telly program the other day that said Saic made UFO's. Do they? :) Luke(Boo) Farrar. On Mon, 7 Jun 1999, Jeff Parker wrote: > 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: SV: Capabilities
> -Original Message- >> 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. If my understanding is correct, yes. BICBW. 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 -Darran -- Darran D. Rimron [EMAIL PROTECTED] Mobile: +44 17808 49 25 49 Pager: +44 76543 07647 Rimron Design & Consultancy http://www.rimron.co.uk/ Phone: +44 1708 766 959 Fax: +44 1708 766 959
SV: SV: Capabilities
> 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]
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: 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
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