Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uwm.edu!src.honeywell.com!klemmer!vestal From: vestal@SRC.Honeywell.COM (Steve Vestal) Newsgroups: comp.realtime Subject: Re: VxWorks "security"? Message-ID: <1991Jun4.133608.24773@src.honeywell.com> Date: 4 Jun 91 13:36:08 GMT References: <1991Jun3.183523.8212@unhd.unh.edu> Sender: news@src.honeywell.com (News interface) Organization: Honeywell Systems & Research Center Lines: 27 In-Reply-To: paulus@arcturus.anu.oz.au's message of 3 Jun 91 23:10:07 GMT Nntp-Posting-Host: klemmer.src.honeywell.com paulus@arcturus.anu.oz.au (Paul Mackerras) writes: Paul> rg@msel.unh.edu (Roger Gonzalez) writes: > Somehow I can just picture a hacker telnetting > to our robot and accidentally turning thrusters on... Paul> University) and we had the same concerns. The solution which I came up Paul> with is a real hack, but it was sufficient for our environment: I patched Paul> the rlogin code in VxWorks so that it compared the username supplied This raises another issue that, for lack of a better term, I'll call timing security. I did some careful timing measurement & analysis on a VxWorks system and discovered that there were sporadic bursts of activity that couldn't be accounted for by any of the application tasks or application-required VxWorks services. I speculated that some of these bursts were due to VxWorks occasionally handling ethernet messages. Although the overall load was small -- maybe 1% utilization in our environment -- the actual duration of a sporadic burst wasn't negligible, especially as the frequency of application tasks increased. The time spent rejecting an rlogin attempt might possibly, in some applications, cause an application timing fault (missed deadline). Steve Vestal Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 Phone: (612) 782-7049 Internet: vestal@src.honeywell.com