From owner-freebsd-multimedia Fri Mar 21 16:34:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA26824 for multimedia-outgoing; Fri, 21 Mar 1997 16:34:49 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA26819 for ; Fri, 21 Mar 1997 16:34:46 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id QAA03483; Fri, 21 Mar 1997 16:34:43 -0800 (PST) Message-Id: <199703220034.QAA03483@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Anthony.Kimball@East.Sun.COM cc: smp@csn.net, multimedia@freebsd.org Subject: Re: Continquous Memory vs Virtual Memory In-reply-to: Your message of "Fri, 21 Mar 1997 18:14:29 CST." <199703220014.SAA28132@compound.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 16:34:43 -0800 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My rebuttal: User X downloads pre-compiled binary with the "virus". Is this far-fetched not really. The kind of individuals that our current technology will attract are not rocket-science unix hackers. Meaning that they will probably not want to download the sources, inspect them and compile the programs. To answer your concern, yes it is a waste of efforts to tighten security however we are trying to look ahead and minimize our exposure to malicious attacks on the system. When in doubt chose a secured avenue. Last but not least I left implementations such as dtv wide-open because the device can be protected as well as the program. A program which sort of does the same thing as dtv well from a security risk stand point of view is X. Now there you have a real risk , a user level device driver . As far as I know there has been no incidents of a virus being introduced by way of an X server nevertheless the possibility is there. Regards, Amancio >From The Desk Of Tony Kimball : > Quoth Amancio Hasty on Fri, 21 March: > : From The Desk Of Tony Kimball : > : > Quoth Steve Passe on Fri, 21 March: > : > : [kernel memory protection violation of RISC engine programs > : > : implies need for kernel-level compiler] > : > > : > Are there any applications which care? If there are none, your > : > concerns are excessively zealous. > : > > : > > : Hi Tony, > : > : The answer is yes. We have applications which can load up into the > : driver any old memory address which they want. For instance, > : dtv passes to the driver the physical address of the frame buffer. > : Programs like dtv do PCI to PCI data transfer or in a case of > : a hacker exploit it can do PCI to kernel address space. > : > > When I say "applications" I mean applications in the sense of "problem > solutions" or "operational installations". Yes, there are > applications in the sense of executable programs which operate upon > the device, but that is not really germane to the issue, I think: If > there were *no* such executable programs, they would simply be written. > > To clarify: My question is whether there are any installations of the > device (physical machines in which the kernel device is compiled) in > which it is necessary to protect kernel memory from executable > programs which may be run by malicious parties using mechanisms in > excess of ordinary file system permissions. If you agree with me, you > will admit that if there are no such installations, a kernel compiler > with safety checking is wasted effort. If there are such > installations, it may hypothetically be the case that there are other > applications for which the resulting soft architecture is > unacceptable. This would tend to result in two divergent drivers. > That might be okay too. > > I am a long-time lurker on multimedia@, and I apologize for a lengthy > post of a non-strictly-contributory nature. But developmental > politics is a fascination of mine. > >