Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vitalink.COM!widener!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw From: padgett%tccslr.dnet@mmc.com (Padgett Peterson) Newsgroups: comp.virus Subject: Re: MS-DOS in ROM (PC) Message-ID: <0006.9105311330.AA00359@ubu.cert.sei.cmu.edu> Date: 30 May 91 15:47:13 GMT Sender: Virus Discussion List Lines: 29 Approved: krvw@sei.cmu.edu "William Walker C60223 x4570" writes: >We're writing from two different premises. Padgett is writing about >MS- DOS actually running from ROM, while I'm writing about the DOS >files, and the boot disk itself, being in ROM ( a ROM-disk, as opposed >to a RAM-disk ). ... The method of booting from >a ROM- disk ( with an infection-proof boot sector and system files ), >which I wrote about, is not implemented at this time, to the best of >my knowledge. While I follow the premise better now, what you are talking about is what I referred to in the third option - somehow swapping ROM addresses for RAM addresses or possibly a "page frame" approach such as used for expanded memory. It will take a special BIOS driver to accomodate just like a RAM-disk requires a special driver and the data areas will have to stay resident somewhere. The point is that there are a finite number of addresses available and if some are used for ROM then there are that many less for RAM unless some extra memory management scheme is used such as that used for "shadow RAM" on 386s - not difficult but requires a few extras. The point I was trying to make was that even with this type of mechanism, the same holes exist in MS-DOS as did before. Some have been moved (e.g. the first attackable point) so that specific malicious software will be thwarted, but the hole still exists and will just be exploited in the next crop. There is still NO integrity management in MS-DOS. Warmly, Padgett