home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!jb7m+
- From: jb7m+@andrew.cmu.edu (Jon C. R. Bennett)
- Newsgroups: comp.software-eng
- Subject: Re: Code Coverage tools for the kernel
- Message-ID: <weyJd=200WAjIVN756@andrew.cmu.edu>
- Date: 5 Nov 92 07:30:51 GMT
- Article-I.D.: andrew.weyJd=200WAjIVN756
- References: <1992Oct30.165835.21814@m.cs.uiuc.edu> <1992Nov02.202736.18702@Veritas.COM> <Bx5BtH.EHr@cs.uiuc.edu>
- <1992Nov04.201837.14950@Veritas.COM>
- Distribution: usa
- Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA
- Lines: 19
- In-Reply-To: <1992Nov04.201837.14950@Veritas.COM>
-
- joshua@Veritas.COM (Joshua Levy) writes:
- > >So, by "decent C coverage tool", I was assuming one that used an
- > >in-core table written out at the end of program execution. Since the
- > >I/O is done in one place, it should be easy to tailor. For example,
- > >when using GCT on the kernel, you just reach in through /dev/kmem and
- > >read the table.
- >
- > This is fine from a coverage point of view, but it is a major security
- > problem. If the person running the tests (which hopefully includes
- > lots of development and QA engineers, not to mention some pseudo-real
- > users) can read /dev/kmem, then those people can steal passwords,
- > including the root password.
-
- in the context described, the person is testing the KERNAL, if you could
- compile the kernal, and install the kernal, and run the kernal, then it
- dont realy mater that you might be able to get the root password, beacuse
- you already have the root password.
-
- jon
-