Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw From: walker@aedc-vax.af.mil (William Walker C60223 x4570) Newsgroups: comp.virus Subject: Re: MS-DOS in ROM; Re: NVMs (PC) Message-ID: <0010.9105301427.AA10625@ubu.cert.sei.cmu.edu> Date: 29 May 91 21:10:00 GMT Sender: Virus Discussion List Lines: 56 Approved: krvw@sei.cmu.edu A. Padgett Peterson ( padgett%tccslr.dnet@mmc.com ) writes: > ... > The answer is that while all of MS-DOS is used, part of it is only > necessary for start-up. Once these segments are complete, the memory > occupied by structures like SYSINIT is released back into the free space > for re-use just like when an application is complete, the space occupied > is reuseable by the next program. With ROM this is more difficult. > ... and I wrote > ... > If the [ MS-DOS in ] ROM upgrade is on a cartridge (similar to HP > fonts), upgrading would involve swapping cartridges, which could also > contain the other DOS-related files (CHKDSK, EDLIN, etc.). > ... > It would provide SOME protection from viri, in that the DOS files > themselves, being in ROM, would be immune from infection. > ... 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 running MS-DOS from ROM, as Padgett states, is currently used by some laptops, and also by some diskless LAN- stations and third-party boot cards. 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. Mr. Peterson and I are not arguing the point ( at least I hope not; sorry if it seemed that way, Padgett ), but we're presenting two different answers to the same question. Each method has its advantages and disadvantages, and each may be applicable in different situations. Since this may indeed be an ongoing discussion, I thought it necessary to point out the differences in our solutions. Oh, BTW, Michael A. Maxim ( mmaxim@sc9.intel.com ) writes: > If some board maker actually > wanted to enable software modification to the BIOS EEPROM, there is no > reason that he couldn't do it; but that is a problem with the board > and manufacturer, not the chips. I had originally questioned the security of using EEPROMs and a software- upgradable BIOS, not the EEPROMs themselves. I had merely used Intel's announcement as a starting point for my discussion, and I apologize if I seemed like I was being critical of the chips or the technology. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | "Non sequitur -- your facts are Arnold Engineering Development Center | un-coordinated." M.S. 120 | -- NOMAD Arnold Air Force Base, TN 37389-9998 |