why is there not a lisp pc?
in [Lisp]
|
From: Scott Burson on 20 Jan 2010 03:04 On Jan 19, 4:16 am, Tamas K Papp <tkp...(a)gmail.com> wrote: > Imagine having desktop Lisp machines > today, with x86-like speed but the same security model. Would you browse > the web on that? HELL no. Clearly a lot of work would have had to be done on security. -- Scott
From: Scott Burson on 20 Jan 2010 03:11 On Jan 19, 12:24 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > > There is no way to call g so that it modify v1: there is isolation in lisp! But not on the LispM, which had subprimitives (with names like SI:%P- CONTENTS-OFFSET if memory serves) to read and write arbitrary locations within any object, and which were not bounds-checked either. On the other hand, ordinary arrays were bounds-checked, and were not stack-allocated either, removing one familiar attack style that works on many C programs. Still I am sure there were other vulnerabilities -- and once you're in at all, you have the whole machine. -- Scott
From: Frode V. Fjeld on 20 Jan 2010 04:13 Helmut Eller <eller.helmut(a)gmail.com> writes: > Tell me your implementation and I'll show how to modify v1. Tell me your flavor of unix and I'll show you how to modify another process. Here's an example form the machine I'm sitting at now: frode(a)shevek:~$ sleep 1000 & [1] 21184 frode(a)shevek:~$ ll /proc/21184/mem -rw------- 1 frode frode 0 2010-01-20 09:47 /proc/21184/mem My point is, in all security problems you have to be explicit about what the threat you're protecting against is. Typical linux desktops today have two security domains: "root" and some user. Root privileges are if I'm not mistaken required only to do permanent damage to the system as such (i.e. ruin the file-system other than /home). Note that in at least one sense this is the least protection-worthy part of the system because you can always download a new OS CD and reinstall it. (Of course I know there are other issues involved, but I'm making a one-sided argument here..) Most MS-windows desktops don't even bother with this protection, and provide the user with administrator privileges. If you have user privileges you can still read and write *everything* you (qua user) have on disk and in memory, so privacy is out, and safety is out. I'm not saying there aren't advantages to the inter-process safety that e.g. linux provides, but it's not absolute safety, and these things do crash, and I suspect there is a heavy, heavy cost in terms of usability (for sure) and performance (perhaps) incurred by this safety model. -- Frode V. Fjeld
From: Nick Keighley on 20 Jan 2010 05:41 On 20 Jan, 09:13, "Frode V. Fjeld" <fr...(a)netfonds.no> wrote: > Helmut Eller <eller.hel...(a)gmail.com> writes: <snip> > My point is, in all security problems you have to be explicit about what > the threat you're protecting against is. > > Typical linux desktops today have two security domains: "root" and some > user. Root privileges are if I'm not mistaken required only to do > permanent damage to the system as such (i.e. ruin the file-system other > than /home). Note that in at least one sense this is the least > protection-worthy part of the system because you can always download a > new OS CD and reinstall it. (Of course I know there are other issues > involved, but I'm making a one-sided argument here..) Most MS-windows > desktops don't even bother with this protection, and provide the user > with administrator privileges. this is less true than it used to be. I don't have admin privilege on the windows machine I'm currently using. I suspct many office machines are set up so the user doesn't have admin privs. Later version of XP had better security and Vista came with them out- of-the-box. Which caused much whining amongst those people used to the older Windows "security model" (ie. none to speak of). Vista now has the reputaion of prompting you every 30s for the admin password. It doesn't, of course. And if you really want to you can turn off the security. > If you have user privileges you can still read and write *everything* > you (qua user) have on disk and in memory, so privacy is out, and safety > is out. > > I'm not saying there aren't advantages to the inter-process safety that > e.g. linux provides, but it's not absolute safety, and these things do > crash, and I suspect there is a heavy, heavy cost in terms of usability > (for sure) and performance (perhaps) incurred by this safety model. -- Nick Keighley
From: Nick Keighley on 20 Jan 2010 05:44
On 19 Jan, 20:24, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Helmut Eller <eller.hel...(a)gmail.com> writes: > > * Frode V. Fjeld [2010-01-19 13:54+0100] writes: > > >> I don't know that there's anything with Firefox that would be impossible > >> or even more difficult to do on a lispm than e.g. linux. Other than the > >> sheer amount of work required to implement a browser, that is. > > > Isolation? Unix uses the MMU to isolate process from each other. That > > makes it fairly safe to execute programs written in low level languages > > like C or assembler. The accessible memory is protected by the MMU and > > everything else must be done via syscalls. > > > On the Lisp Machine every program had (intentionally) access to the > > whole machine. That simplified debugging. On the downside, a bug in > > one program could bring down the entire machine. In Unix terms, there > > was no distinction between user space and kernel space. > > > Isolation also forced the Unix people to invent shared libraries so that > > at read-only data/code could be shared safely. Nothing like that existed > > on Lisp Machines, or does it? > > > I would not want to use an OS that doesn't provide isolation. > > So you can happily use an OS written in lisp, without a hardware MMU. > > (let ((v1 (vector 1 2 3))) > (defun f (x) > (if (<= 0 x 2) (aref v1 x)))) > > (defun g (v i) > (setf (aref v i) 0)) > > There is no way to call g so that it modify v1: there is isolation in lisp! I recall reading some stuff anout PLT Scheme that, if I recall correctly, was saying that the virtual machine used by PLT scheme did much of the protection that OSs typically do. The perticular machine prevents you from doing whatever the VM provider wishes to prevent you from doing. |