* kernel stack challenge @ 2004-04-04 6:48 Sergiy Lozovsky 2004-04-05 9:39 ` Helge Hafting 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-04 6:48 UTC (permalink / raw) To: linux-kernel Hi, I have a stack hungry code in the kernel. It hits the end of stack from time to time. I wrote function to which I pass pointers to function and memory area which should be used as stack for function execution. (I just load pointer to new stack area into esp register). This function works just fine in user space and memory area provided by me is used as stack. This function doesn't work in the kernel (system hungs instantly when my function is called). Does antbody have any idea what the reason can be? Some special alignment? Special memory segment? In what direction should I look? (sure I tried some magic with alignment like - __attribute__ ((aligned (8192))) - no any effect) (there was some patch to increase stack size kernelwide, but I don't want to affect all the system). Thanks, Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-04 6:48 kernel stack challenge Sergiy Lozovsky @ 2004-04-05 9:39 ` Helge Hafting 2004-04-05 17:05 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: Helge Hafting @ 2004-04-05 9:39 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: linux-kernel Sergiy Lozovsky wrote: > Hi, > > I have a stack hungry code in the kernel. It hits the > end of stack from time to time. I wrote function to > which I pass pointers to function and memory area > which should be used as stack for function execution. > (I just load pointer to new stack area into esp > register). This function works just fine in user space > and memory area provided by me is used as stack. > > This function doesn't work in the kernel (system hungs > instantly when my function is called). Does antbody > have any idea what the reason can be? Some special > alignment? Special memory segment? In what direction > should I look? > > (sure I tried some magic with alignment like - > __attribute__ ((aligned (8192))) - no any effect) > > (there was some patch to increase stack size > kernelwide, but I don't want to affect all the > system). You aren't supposed to need much stack for anything in the kernel. Consider rewriting your function to use allocated memory instead of stack, this isn't all that hard. Helge Hafting ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 9:39 ` Helge Hafting @ 2004-04-05 17:05 ` Sergiy Lozovsky 2004-04-05 18:06 ` Timothy Miller 2004-04-06 13:32 ` Helge Hafting 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 17:05 UTC (permalink / raw) To: Helge Hafting; +Cc: linux-kernel > Consider rewriting your function to use allocated > memory instead of stack, this isn't all that hard. I put LISP interpreter inside the Kernel - http://vxe.quercitron.com It works, but it use a lot of stack memory. It's impossible to rewrite it easily, though I'll investigate why exactly it uses so much of stack memory (though it's nature of LISP). There are no serious kernel memory allocation (as of my interpreter code review, only function calls; recursions in LISP application itself are eliminated for sure), but I'll trace stack usage more thouroughly. Serge. --- Helge Hafting <helgehaf@aitel.hist.no> wrote: > Sergiy Lozovsky wrote: > > Hi, > > > > I have a stack hungry code in the kernel. It hits > the > > end of stack from time to time. I wrote function > to > > which I pass pointers to function and memory area > > which should be used as stack for function > execution. > > (I just load pointer to new stack area into esp > > register). This function works just fine in user > space > > and memory area provided by me is used as stack. > > > > This function doesn't work in the kernel (system > hungs > > instantly when my function is called). Does > antbody > > have any idea what the reason can be? Some special > > alignment? Special memory segment? In what > direction > > should I look? > > > > (sure I tried some magic with alignment like - > > __attribute__ ((aligned (8192))) - no any effect) > > > > (there was some patch to increase stack size > > kernelwide, but I don't want to affect all the > > system). > > > You aren't supposed to need much stack for anything > in the kernel. > Consider rewriting your function to use allocated > memory instead of stack, this isn't all that hard. > > Helge Hafting > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 17:05 ` Sergiy Lozovsky @ 2004-04-05 18:06 ` Timothy Miller 2004-04-05 17:59 ` Sergiy Lozovsky 2004-04-06 13:32 ` Helge Hafting 1 sibling, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-05 18:06 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Helge Hafting, linux-kernel Sergiy Lozovsky wrote: > > I put LISP interpreter inside the Kernel - I'm dying to know why you need a LISP interpreter inside the kernel. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 18:06 ` Timothy Miller @ 2004-04-05 17:59 ` Sergiy Lozovsky 2004-04-05 19:27 ` Valdis.Kletnieks ` (2 more replies) 0 siblings, 3 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 17:59 UTC (permalink / raw) To: Timothy Miller; +Cc: Helge Hafting, linux-kernel --- Timothy Miller <miller@techsource.com> wrote: > > > Sergiy Lozovsky wrote: > > > > > I put LISP interpreter inside the Kernel - > > > > I'm dying to know why you need a LISP interpreter > inside the kernel. It is explained at my project home page - http://vxe.quercitron.com Basically there are two reasons. 1. Give system administrator possibility to change security policy easy enough without C programminig inside the kernel (we should not expect system administartor to be a kernel guru). Language of higher lavel make code more compact (C - is too low level, that's why people use PERL for example or LISP). Lisp was chosen because of very compact VM - around 100K. 2. Protect system from bugs in security policy created by system administrator (user). LISP interpreter is a LISP Virtual Machine (as Java VM). So all bugs are incapsulated and don't affect kernel. Even severe bugs in this LISP kernel module can cause termination of user space application only (except of stack overflow - which I can address). LISP error message will be printed in the kernel log. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 17:59 ` Sergiy Lozovsky @ 2004-04-05 19:27 ` Valdis.Kletnieks 2004-04-05 21:14 ` Timothy Miller 2004-04-05 20:09 ` John Stoffel 2004-04-05 21:12 ` Timothy Miller 2 siblings, 1 reply; 84+ messages in thread From: Valdis.Kletnieks @ 2004-04-05 19:27 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, Helge Hafting, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1933 bytes --] On Mon, 05 Apr 2004 10:59:40 PDT, Sergiy Lozovsky said: > 1. Give system administrator possibility to change > security policy easy enough without C programminig > inside the kernel (we should not expect system > administartor to be a kernel guru). Language of higher > lavel make code more compact (C - is too low level, > that's why people use PERL for example or LISP). Lisp > was chosen because of very compact VM - around 100K. Didn't seem to slow the SELinux crowd down any... You may not need the exact SELinux config language, but it does address the issue of making something fairly easy for the sysadmin to write while not requiring a large interpreter in the kernel (the kernel side of the selinuxfs pseudo-filesystem is all of 14K, the loadpolicy is about a 4K binary and a 60K shared library, and the policy compiler is about 100K and the shared lib). So you're including a much bigger interface for little gain. The total footprint of the two solutions is about the same, but SELinux the vast majority of it is in userspace, and only costs you when you're actually compiling/ loading a new policy, whereas yours takes up 100K of kernel space all the time.... > 2. Protect system from bugs in security policy created > by system administrator (user). LISP interpreter is a > LISP Virtual Machine (as Java VM). So all bugs are > incapsulated and don't affect kernel. Even severe bugs > in this LISP kernel module can cause termination of > user space application only (except of stack overflow > - which I can address). LISP error message will be > printed in the kernel log. If you think that "all bugs are encapsulated" actually means anything in the context of the Linux kernel, you're in for a very big surprise. For example - your Lisp error messages go through the kernel log, so you're using printk() and friends. Note that it *is* possible for a buggy call to printk() to cause problems for the kernel. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 19:27 ` Valdis.Kletnieks @ 2004-04-05 21:14 ` Timothy Miller 0 siblings, 0 replies; 84+ messages in thread From: Timothy Miller @ 2004-04-05 21:14 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Sergiy Lozovsky, Helge Hafting, linux-kernel Valdis.Kletnieks@vt.edu wrote: > > So you're including a much bigger interface for little gain. The total > footprint of the two solutions is about the same, but SELinux the vast majority > of it is in userspace, and only costs you when you're actually compiling/ > loading a new policy, whereas yours takes up 100K of kernel space all the > time.... > The key concept here is "in userspace". ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 17:59 ` Sergiy Lozovsky 2004-04-05 19:27 ` Valdis.Kletnieks @ 2004-04-05 20:09 ` John Stoffel 2004-04-05 20:54 ` Sergiy Lozovsky 2004-04-05 21:12 ` Timothy Miller 2 siblings, 1 reply; 84+ messages in thread From: John Stoffel @ 2004-04-05 20:09 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, Helge Hafting, linux-kernel >>>>> "Sergiy" == Sergiy Lozovsky <serge_lozovsky@yahoo.com> writes: Sergiy> Basically there are two reasons. Sergiy> 1. Give system administrator possibility to change security Sergiy> policy easy enough without C programminig inside the kernel Sergiy> (we should not expect system administartor to be a kernel Sergiy> guru). Language of higher lavel make code more compact (C - is Sergiy> too low level, that's why people use PERL for example or Sergiy> LISP). Lisp was chosen because of very compact VM - around Sergiy> 100K. Why in god's name does this need to be in the kernel? This is purely a userspace issue, and the tool for managing the security policy should be completely in userspace. Under this design, /bin/ls would be a kernel module, and not a userspace tool! If you ever want to even think about getting this project into the kernel, you'll have to re-design what you're doing here, since there's absolutely no need for anything like this in the kernel. Sergiy> 2. Protect system from bugs in security policy created by Sergiy> system administrator (user). C'mon, GIGO will kill you from user space or from kernel space. What makes you think LISP will protect you? Sergiy> LISP interpreter is a LISP Virtual Machine (as Java VM). So Sergiy> all bugs are incapsulated and don't affect kernel. Then *WHY* does the LISP interpreter need to be in the kernel in the first place? Hint, you just said you wanted to protect the kernel... Sergiy> Even severe bugs in this LISP kernel module can cause Sergiy> termination of user space application only (except of stack Sergiy> overflow - which I can address). LISP error message will be Sergiy> printed in the kernel log. Hah! You just gave the number one reason why you don't want or need a LISP interpreter in the kernel yourself. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 20:09 ` John Stoffel @ 2004-04-05 20:54 ` Sergiy Lozovsky 2004-04-05 21:08 ` Chris Wright 2004-04-05 21:28 ` Timothy Miller 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 20:54 UTC (permalink / raw) To: John Stoffel; +Cc: Timothy Miller, Helge Hafting, linux-kernel --- John Stoffel <stoffel@lucent.com> wrote: > >>>>> "Sergiy" == Sergiy Lozovsky > <serge_lozovsky@yahoo.com> writes: > > Sergiy> Basically there are two reasons. > > Sergiy> 1. Give system administrator possibility to > change security > Sergiy> policy easy enough without C programminig > inside the kernel > Sergiy> (we should not expect system administartor > to be a kernel > Sergiy> guru). Language of higher lavel make code > more compact (C - is > Sergiy> too low level, that's why people use PERL > for example or > Sergiy> LISP). Lisp was chosen because of very > compact VM - around > Sergiy> 100K. > > Why in god's name does this need to be in the > kernel? This is purely > a userspace issue, and the tool for managing the > security policy > should be completely in userspace. UNIX security policy is already implemented in the Kernel, or should we move checking of root priveleges and file permissions to the userspace? I just extended existing security features. > Under this design, /bin/ls would be a kernel module, > and not a > userspace tool! No :-) What you suggest is kernel should receive system call from user space. Instead of handling it - kernel should forward it back to userspace, than it should be forwarded back to the kernel. Looks not very nice to me. Why not to handle security policy inside the kernel as it is done for the file permissions and root priveleges? > Sergiy> 2. Protect system from bugs in security > policy created by > Sergiy> system administrator (user). > > C'mon, GIGO will kill you from user space or from > kernel space. What > makes you think LISP will protect you? > > Sergiy> LISP interpreter is a LISP Virtual Machine > (as Java VM). So > Sergiy> all bugs are incapsulated and don't affect > kernel. > > Then *WHY* does the LISP interpreter need to be in > the kernel in the > first place? Hint, you just said you wanted to > protect the kernel... All LISP errors are incapsulated within LISP VM. > Sergiy> Even severe bugs in this LISP kernel module > can cause > Sergiy> termination of user space application only > (except of stack > Sergiy> overflow - which I can address). LISP error > message will be > Sergiy> printed in the kernel log. > > Hah! You just gave the number one reason why you > don't want or need a > LISP interpreter in the kernel yourself. What reason you have in mind? All available security models have predefined stack usage, so it is completely safe to use them. For those who want to define their security model (not security policy!) - they shoud respect stack limitations for now. Which sounds reasonable. Using existing security models it is impossible to cause stack overflow. (depth of subroutine calls is constant). Serge. > John > John Stoffel - Senior Unix Systems Administrator > - Lucent Technologies > stoffel@lucent.com - http://www.lucent.com - 978-952-7548 __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 20:54 ` Sergiy Lozovsky @ 2004-04-05 21:08 ` Chris Wright 2004-04-05 21:40 ` Sergiy Lozovsky 2004-04-05 21:28 ` Timothy Miller 1 sibling, 1 reply; 84+ messages in thread From: Chris Wright @ 2004-04-05 21:08 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: John Stoffel, Timothy Miller, Helge Hafting, linux-kernel * Sergiy Lozovsky (serge_lozovsky@yahoo.com) wrote: > No :-) What you suggest is kernel should receive > system call from user space. Instead of handling it - > kernel should forward it back to userspace, than it > should be forwarded back to the kernel. Looks not very > nice to me. Why not to handle security policy inside > the kernel as it is done for the file permissions and > root priveleges? All this can be done w/out having a LISP interpretter coming along for the ride, that's the point of the other posters. With LSM you have a framework for implementing your own security model and enforcing your own policies. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:08 ` Chris Wright @ 2004-04-05 21:40 ` Sergiy Lozovsky 2004-04-05 21:53 ` Chris Wright 2004-04-05 22:22 ` Timothy Miller 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 21:40 UTC (permalink / raw) To: Chris Wright; +Cc: John Stoffel, Timothy Miller, Helge Hafting, linux-kernel --- Chris Wright <chrisw@osdl.org> wrote: > * Sergiy Lozovsky (serge_lozovsky@yahoo.com) wrote: > > No :-) What you suggest is kernel should receive > > system call from user space. Instead of handling > it - > > kernel should forward it back to userspace, than > it > > should be forwarded back to the kernel. Looks not > very > > nice to me. Why not to handle security policy > inside > > the kernel as it is done for the file permissions > and > > root priveleges? > > All this can be done w/out having a LISP > interpretter coming along for the > ride, that's the point of the other posters. With > LSM you have a > framework for implementing your own security model > and enforcing your own > policies. LSM use another way of doing similar things :-) I'm not sure that it is nice to forward system calls back to userspace where they came from in the first place :-) VXE use high level language to create security models. And what are the problems with technology used by VXE? File permissions are checked in the kernel and everybody are happy with that. VXE just extends security features already available in the kernel. There is a historic part to all that, too - VXE was created (1999) before SELinux was available. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:40 ` Sergiy Lozovsky @ 2004-04-05 21:53 ` Chris Wright 2004-04-05 22:22 ` Timothy Miller 1 sibling, 0 replies; 84+ messages in thread From: Chris Wright @ 2004-04-05 21:53 UTC (permalink / raw) To: Sergiy Lozovsky Cc: Chris Wright, John Stoffel, Timothy Miller, Helge Hafting, linux-kernel * Sergiy Lozovsky (serge_lozovsky@yahoo.com) wrote: > LSM use another way of doing similar things :-) I'm > not sure that it is nice to forward system calls back > to userspace where they came from in the first place > :-) VXE use high level language to create security > models. There's no requirement in LSM to forward syscalls back to userspace for access control check. At any rate, seems you like your solution, just wanted to make sure you were aware of alternatives. > And what are the problems with technology used by VXE? It's the LISP interpreter that's problematic. As you've already seen with the kernel stack limitations. > File permissions are checked in the kernel and > everybody are happy with that. VXE just extends > security features already available in the kernel. And LSM checks are done in kernel. > There is a historic part to all that, too - VXE was > created (1999) before SELinux was available. Ah, the real truth ;-) thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:40 ` Sergiy Lozovsky 2004-04-05 21:53 ` Chris Wright @ 2004-04-05 22:22 ` Timothy Miller 2004-04-05 23:49 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-05 22:22 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Chris Wright, John Stoffel, Helge Hafting, linux-kernel Sergiy Lozovsky wrote: > > > LSM use another way of doing similar things :-) I'm > not sure that it is nice to forward system calls back > to userspace where they came from in the first place > :-) VXE use high level language to create security > models. > "Kernel space -> user space -> kernel space" is nothing compared to the overhead of a LISP interpreter. Doing interpretation of LISP is a monster compared to some piddly context switches. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 22:22 ` Timothy Miller @ 2004-04-05 23:49 ` Sergiy Lozovsky 2004-04-06 13:25 ` Jesse Pollard [not found] ` <20040406132750$3d4e@grapevine.lcs.mit.edu> 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 23:49 UTC (permalink / raw) To: Timothy Miller; +Cc: Chris Wright, John Stoffel, Helge Hafting, linux-kernel --- Timothy Miller <miller@techsource.com> wrote: > > > Sergiy Lozovsky wrote: > > > > > > > LSM use another way of doing similar things :-) > I'm > > not sure that it is nice to forward system calls > back > > to userspace where they came from in the first > place > > :-) VXE use high level language to create security > > models. > > > > "Kernel space -> user space -> kernel space" is To be more precise "user space -> kernel space -> user space -> kernel space -> user space" against ordinary "user space -> kernel space -> user space" So, what happens - task makes system calls and blocks; request goes to a user space security server. Will it process request right away? No, it will wait for scheduler to chose it for execution. Ok server got CPU and returns results to the kernel. Will initial task continue? No, it will wait for be chosen by scheduler. This is what I call overhead (though i understand, that can be wrong). My system (VXE) doesn't involve scheduler at all. So we should not just look into length of this chain at the picture. - "user space -> kernel space -> user space -> kernel space -> user space" - we should remember that it involves to mandatory task switches to accomplish jus one system call. > nothing compared to the > overhead of a LISP interpreter. LISP code, is very small actually. And nobody can just kill it. I know it's not a real protection, but intent was to place a security system in such place where it will be more protected by itself. I placed additional security mechanisms in the place where designers of UNIX placed theirs (file permissions an so on) - in the kernel. > Doing interpretation of LISP is a monster compared > to some piddly > context switches. When people say LISP they mean Common LISP, which is a monster and I agree with you. VXE uses stripped down version of LISP and syntax of LISP is far simpler than C for example. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 23:49 ` Sergiy Lozovsky @ 2004-04-06 13:25 ` Jesse Pollard [not found] ` <20040406132750$3d4e@grapevine.lcs.mit.edu> 1 sibling, 0 replies; 84+ messages in thread From: Jesse Pollard @ 2004-04-06 13:25 UTC (permalink / raw) To: Sergiy Lozovsky, Timothy Miller Cc: Chris Wright, John Stoffel, Helge Hafting, linux-kernel On Monday 05 April 2004 18:49, Sergiy Lozovsky wrote: > --- Timothy Miller <miller@techsource.com> wrote: > > Sergiy Lozovsky wrote: > > > LSM use another way of doing similar things :-) > > > > I'm > > > > > not sure that it is nice to forward system calls > > > > back > > > > > to userspace where they came from in the first > > > > place > > > > > :-) VXE use high level language to create security > > > > > > models. > > > > "Kernel space -> user space -> kernel space" is > > To be more precise "user space -> kernel space -> user > space -> kernel space -> user space" > > against ordinary "user space -> kernel space -> user > space" > > So, what happens - task makes system calls and blocks; > request goes to a user space security server. Will it > process request right away? No, it will wait for > scheduler to chose it for execution. Ok server got CPU > and returns results to the kernel. Will initial task > continue? No, it will wait for be chosen by scheduler. > This is what I call overhead (though i understand, > that can be wrong). My system (VXE) doesn't involve > scheduler at all. Depends on what the requirement is. In some cases you MUST do this - otherwise the tables required for making the decision would be WAY too large for the kernel. Some models even require reference to remote hosts for validation. The current Kerberos authentication requires this. So do AFS requests. Other requests can be satisfied by a cached table entry without waiting. > So we should not just look into length of this chain > at the picture. - "user space -> kernel space -> user > space -> kernel space -> user space" - we should > remember that it involves to mandatory task switches > to accomplish jus one system call. It only depends on the request. If the entire security context is local, then this is not required. > > nothing compared to the > > overhead of a LISP interpreter. > > LISP code, is very small actually. And nobody can just > kill it. I know it's not a real protection, but intent > was to place a security system in such place where it > will be more protected by itself. I placed additional > security mechanisms in the place where designers of > UNIX placed theirs (file permissions an so on) - in > the kernel. LISP code (if compiled machine code) IS small. LISP VM is not - when you combine it with the lisp code, the heap management, and garbage collector. And you can STILL have memory leaks out the wazoo. To prevent the memory leaks you have to have a mark and sweep GC. Which still doesn't prevent circular loop leaks. Then you need a memory pool allocator to relocate all valid references. The combination is NOT small. BTW, the JVM suffers from circular loop leaks too, since all it uses is reference counting (for speed). > > Doing interpretation of LISP is a monster compared > > to some piddly > > context switches. > > When people say LISP they mean Common LISP, which is a > monster and I agree with you. VXE uses stripped down > version of LISP and syntax of LISP is far simpler than > C for example. No - they mean the VM + garbage collector + error handler + the lisp pcode. ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <20040406132750$3d4e@grapevine.lcs.mit.edu>]
[parent not found: <mit.lcs.mail.linux-kernel/20040406132750$3d4e@grapevine.lcs.mit.edu>]
* Re: kernel stack challenge [not found] ` <mit.lcs.mail.linux-kernel/20040406132750$3d4e@grapevine.lcs.mit.edu> @ 2004-04-06 16:40 ` Patrick J. LoPresti 2004-04-06 19:10 ` Timothy Miller 2004-04-07 14:36 ` Jesse Pollard 0 siblings, 2 replies; 84+ messages in thread From: Patrick J. LoPresti @ 2004-04-06 16:40 UTC (permalink / raw) To: Jesse Pollard; +Cc: linux-kernel Jesse Pollard <jesse@cats-chateau.net> writes: > To prevent the memory leaks you have to have a mark and sweep GC. > Which still doesn't prevent circular loop leaks. What are you talking about? A mark/sweep GC certainly DOES collect circular data structures. Perhaps you are thinking of reference counting GCs? > Then you need a memory pool allocator to relocate all valid > references. Now you seem to talking about stop and copy, which is something else again. And it is not required to avoid memory leaks, although it does fix fragmentation. > The combination is NOT small. BTW, the JVM suffers from circular > loop leaks too, since all it uses is reference counting (for speed). Which JVM are you talking about? Every JVM I know of uses a real garbage collector, not some reference counting hack. Perhaps you are thinking of Perl? Sergiy is right: A Lisp interpreter and runtime can be quite small and efficient. And it can provide a secure "sandbox" for running questionable code safely. Whether it is a good idea in this context is another question. My concern is that it is hard (impossible?) to bound the memory consumption, both stack AND heap, of a Lisp program statically. I would expect such bounds to be important for an implementation of a security model. With a Lisp program, you cannot be sure under what conditions it will exceed whatever space you have alloted for it. Which means that, although it cannot crash the kernel, it cannot be used to build a reliable system, either... - Pat ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 16:40 ` Patrick J. LoPresti @ 2004-04-06 19:10 ` Timothy Miller 2004-04-06 20:53 ` Patrick J. LoPresti 2004-04-07 14:36 ` Jesse Pollard 1 sibling, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-06 19:10 UTC (permalink / raw) To: Patrick J. LoPresti; +Cc: Jesse Pollard, linux-kernel Patrick J. LoPresti wrote: > Whether it is a good idea in this context is another question. My > concern is that it is hard (impossible?) to bound the memory > consumption, both stack AND heap, of a Lisp program statically. I > would expect such bounds to be important for an implementation of a > security model. With a Lisp program, you cannot be sure under what > conditions it will exceed whatever space you have alloted for it. > Which means that, although it cannot crash the kernel, it cannot be > used to build a reliable system, either... > I think 100K is rather large for an interpretor to be included in the kernel, but putting that aside... It's a limited number of people who would actually write these policies. If those people follow certain coding rules, then we CAN have such bounds, by convention. Yes, those bounds could be violated, but if the programmer (not sysadmin -- they would never write these things in LISP) breaks something, it's just a bug. Mostly it would be kernel programmers who write the policies, and those would appear in some /etc directory, put there by Red Hat, and selectable by admins using some GUI. Someone writing a policy which caused the VM to explode would be no different from nVidia writing a kernel driver which did it more directly. The advantage of scripting the policy (which is essentially what this is) is that they could be switchable more dynamically, and they could refer to kernel structures more abstractly. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 19:10 ` Timothy Miller @ 2004-04-06 20:53 ` Patrick J. LoPresti 2004-04-06 21:24 ` Timothy Miller 0 siblings, 1 reply; 84+ messages in thread From: Patrick J. LoPresti @ 2004-04-06 20:53 UTC (permalink / raw) To: Timothy Miller; +Cc: Jesse Pollard, linux-kernel Timothy Miller <miller@techsource.com> writes: > I think 100K is rather large for an interpretor to be included in the > kernel, but putting that aside... I think we are all putting that aside for the moment. :-) > It's a limited number of people who would actually write these > policies. If those people follow certain coding rules, then we CAN > have such bounds, by convention. Yes, those bounds could be violated, > but if the programmer (not sysadmin -- they would never write these > things in LISP) breaks something, it's just a bug. Fair enough. But then I wonder how many of Lisp's advantages you would lose. I am having trouble imagining "statically bounded Lisp" without being so stylized as to hardly be Lisp at all. - Pat ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 20:53 ` Patrick J. LoPresti @ 2004-04-06 21:24 ` Timothy Miller 0 siblings, 0 replies; 84+ messages in thread From: Timothy Miller @ 2004-04-06 21:24 UTC (permalink / raw) To: Patrick J. LoPresti; +Cc: Jesse Pollard, linux-kernel Patrick J. LoPresti wrote: >>It's a limited number of people who would actually write these >>policies. If those people follow certain coding rules, then we CAN >>have such bounds, by convention. Yes, those bounds could be violated, >>but if the programmer (not sysadmin -- they would never write these >>things in LISP) breaks something, it's just a bug. > > > Fair enough. But then I wonder how many of Lisp's advantages you > would lose. I am having trouble imagining "statically bounded Lisp" > without being so stylized as to hardly be Lisp at all. > Given that the original author admits that the sysadmins using this would never actually write any LISP code, I too fail to see why LISP would be of any help here. If you want to be compact and efficient, some really simple pseudo-language would do the job well enough. Optimize for speed of execution and compactness of both interpreter and policy code, not for easy of writing in the language. I mean, by choosing LISP, "ease of writing in the language" was thrown out the window to begin with! :) I think this points us in the direction of something like Forth. Take OpenBoot for example. I wrote Forth-like interpreters in Pascal when I was in highschool. But if you DO want sysadmins to be able to write this, then something resembling shell script would be better. It wouldn't be quite like shell scripting, but it would LOOK like it, and it would have to be compiled (by the program that you run to load the policy) into something compact and easy to interpret before being fed to the kernel. Another possibility is to develop a set of tools that compile policies written in C into modules that are loaded/unloaded into the kernel dynamically. :) The compile process would be transparent to the user, because the "insert this policy" tool would run it through GCC (unless the cached .ko was already up to date, etc.). ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 16:40 ` Patrick J. LoPresti 2004-04-06 19:10 ` Timothy Miller @ 2004-04-07 14:36 ` Jesse Pollard 1 sibling, 0 replies; 84+ messages in thread From: Jesse Pollard @ 2004-04-07 14:36 UTC (permalink / raw) To: Patrick J. LoPresti; +Cc: linux-kernel On Tuesday 06 April 2004 11:40, Patrick J. LoPresti wrote: > Jesse Pollard <jesse@cats-chateau.net> writes: > > To prevent the memory leaks you have to have a mark and sweep GC. > > Which still doesn't prevent circular loop leaks. > > What are you talking about? A mark/sweep GC certainly DOES collect > circular data structures. > > Perhaps you are thinking of reference counting GCs? Ummm. I wasn't precise, sorry. some of the structures I was thinking of must be imported from outside the LISP vm. Think inode data, skb structures, parts of the security context. These are not allocated by the LISP vm, and are not supported by it. And these may be lost by it. I say may, since some security aspects of these structures must be allocated by it (the VM), and then passed externally to provid tracking capabilities. Deallocation via mark/sweep would cause dangling pointers in these external structures. And if you don't pass allocated structures to these kernel objects then you must search for the corresponding structures to the objects when a security decision must be made (more overhead - which was why the LSM added security blob pointers to the various structures). The pure LISP structures are recovered - I was actually thinking about the overhead of the mark/sweep causing significant amounts of fragmentation until the mark/sweep is completed, which can still leave a LOT of fragmentation behind. > > Then you need a memory pool allocator to relocate all valid > > references. > > Now you seem to talking about stop and copy, which is something else > again. And it is not required to avoid memory leaks, although it does > fix fragmentation. Yup. And it is hard. But even mark/sweep algorithms require that the LISP interpreter stop. This was one of the problems with early LISP machines - they would stop for 3-10 seconds during the mark/sweep - their solution: two processors, and memory pools. > > The combination is NOT small. BTW, the JVM suffers from circular > > loop leaks too, since all it uses is reference counting (for speed). > > Which JVM are you talking about? Every JVM I know of uses a real > garbage collector, not some reference counting hack. Most JVM used (at least the ones I've run across) are not designed for server use. These are very small JVMs, and they use reference counting. Once the applet terminates, so does the JVM, and when restarted, it resets memory allocations (aka memory pool). > Perhaps you are thinking of Perl? Nope. I have seen some small LISP interpreters use reference counting - even wrote one of my own. > Sergiy is right: A Lisp interpreter and runtime can be quite small and > efficient. And it can provide a secure "sandbox" for running > questionable code safely. Provided you don't depend on a GC, and have a way to prevent failure (aborts) from causing system wide failure - which is a problem with security reference monitors. > Whether it is a good idea in this context is another question. My > concern is that it is hard (impossible?) to bound the memory > consumption, both stack AND heap, of a Lisp program statically. I > would expect such bounds to be important for an implementation of a > security model. With a Lisp program, you cannot be sure under what > conditions it will exceed whatever space you have alloted for it. > Which means that, although it cannot crash the kernel, it cannot be > used to build a reliable system, either... It is impossible to guarantee memory bounds without eliminating most of the capability of LISP (specific applications + data can be proven bounded, but the general case cannot). The inherent recursive structure forces the memory to be unbound (especially the stack) in presence of multiple function interactions. Sometimes (many times?) the recursive structure can be eliminated by a very good optimizer, but this takes both time and overhead - and is aimed at generating "just in time" machine code, not LISP pcode. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 20:54 ` Sergiy Lozovsky 2004-04-05 21:08 ` Chris Wright @ 2004-04-05 21:28 ` Timothy Miller 2004-04-05 21:21 ` Stephen Smoogen 2004-04-05 21:30 ` Sergiy Lozovsky 1 sibling, 2 replies; 84+ messages in thread From: Timothy Miller @ 2004-04-05 21:28 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: John Stoffel, Helge Hafting, linux-kernel Sergiy Lozovsky wrote: > > > All LISP errors are incapsulated within LISP VM. > A LISP VM is a big, giant, bloated.... *CHOKE* *COUGH* *SPUTTER* *SUFFOCATE* ... thing which SHOULD NEVER be in the kernel. If you want to use a more abstract language for describing kernel security policies, fine. Just don't use LISP. The right way to do it is this: - A user space interpreter reads text-based config files and converts them into a compact, easy-to-interpret code used by the kernel. - A VERY TINY kernel component is fed the security policy and executes it. Move as much of the processing as reasonable into user space. It's absolutely unnecessary to have the parser into the kernel, because parsing of the config files is done only when the ASCII text version changes. It's absolutely unnecessary to have something as complex as LISP to interpret it, when something simple and compact could do just as well. Why do you choose LISP? Don't you want to use a language that sysadmins will actually KNOW? ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:28 ` Timothy Miller @ 2004-04-05 21:21 ` Stephen Smoogen 2004-04-05 22:25 ` Timothy Miller 2004-04-05 21:30 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Stephen Smoogen @ 2004-04-05 21:21 UTC (permalink / raw) To: linux-kernel On Mon, 5 Apr 2004, Timothy Miller wrote: >Sergiy Lozovsky wrote: > >> >> >> All LISP errors are incapsulated within LISP VM. >> > > >A LISP VM is a big, giant, bloated.... *CHOKE* *COUGH* *SPUTTER* >*SUFFOCATE* ... thing which SHOULD NEVER be in the kernel. Ah your thinking of the days when 1 meg of memory was a lot and LISP was considered huge.. With 4 gigs of memory today, it shouldnt be a problem :). Actually a LISP vm can fit into a small amount of memory depending on what you want it to do... I think in the end, this is a 'When all you know is to hammer, everything is a nail.' They know LISP. >Why do you choose LISP? Don't you want to use a language that sysadmins >will actually KNOW? Because how else can you get emacs to the only thing to run? -- Stephen John Smoogen smoogen@lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:21 ` Stephen Smoogen @ 2004-04-05 22:25 ` Timothy Miller 0 siblings, 0 replies; 84+ messages in thread From: Timothy Miller @ 2004-04-05 22:25 UTC (permalink / raw) To: Stephen Smoogen; +Cc: linux-kernel Stephen Smoogen wrote: > On Mon, 5 Apr 2004, Timothy Miller wrote: > > >>Sergiy Lozovsky wrote: >> >> >>> >>>All LISP errors are incapsulated within LISP VM. >>> >> >> >>A LISP VM is a big, giant, bloated.... *CHOKE* *COUGH* *SPUTTER* >>*SUFFOCATE* ... thing which SHOULD NEVER be in the kernel. > > > Ah your thinking of the days when 1 meg of memory was a lot and LISP was > considered huge.. With 4 gigs of memory today, it shouldnt be a problem > :). Actually a LISP vm can fit into a small amount of memory depending > on what you want it to do... People complained about having Athlon-specific fixes in all x86 kernels because of the extra few hundred bytes it would waste for a Pentium kernel. What makes you think people would accept a LISP interpreter? ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:28 ` Timothy Miller 2004-04-05 21:21 ` Stephen Smoogen @ 2004-04-05 21:30 ` Sergiy Lozovsky 2004-04-05 21:45 ` Kevin Fox ` (3 more replies) 1 sibling, 4 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 21:30 UTC (permalink / raw) To: Timothy Miller; +Cc: John Stoffel, Helge Hafting, linux-kernel --- Timothy Miller <miller@techsource.com> wrote: > > > Sergiy Lozovsky wrote: > > > > > > > All LISP errors are incapsulated within LISP VM. > > > > > A LISP VM is a big, giant, bloated.... *CHOKE* > *COUGH* *SPUTTER* > *SUFFOCATE* ... thing which SHOULD NEVER be in the > kernel. It is a smallest interpreter (of all purpose language) I was able to find. My guess is that you refer to the Common Lisp. it is huge and I don't use it. > > If you want to use a more abstract language for > describing kernel > security policies, fine. Just don't use LISP. Point me to ANy langage with VM around 100K. > The right way to do it is this: > > - A user space interpreter reads text-based config > files and converts > them into a compact, easy-to-interpret code used by > the kernel. > > - A VERY TINY kernel component is fed the security > policy and executes it. it is exactly the way it is implemented. Not everyone need to create their own security model (that VERY TINY kernel component you refer to). But even for those who want to modify or create their own VERY TINY kernel component - they don't need to do that in C and debug it in th kernel crashing it. > > Move as much of the processing as reasonable into > user space. It's > absolutely unnecessary to have the parser into the > kernel, because > parsing of the config files is done only when the > ASCII text version > changes. > > It's absolutely unnecessary to have something as > complex as LISP to > interpret it, when something simple and compact > could do just as well. > > Why do you choose LISP? Don't you want to use a > language that sysadmins > will actually KNOW? It was is) the smallest VM I know of. 99% of sysadmins don't need to create their own security models. Security polices are created with web interface very close to the way you described. So sysadmin don't need to know anything about LISP (to use predefined security models). Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:30 ` Sergiy Lozovsky @ 2004-04-05 21:45 ` Kevin Fox 2004-04-05 21:59 ` Robin Rosenberg ` (2 subsequent siblings) 3 siblings, 0 replies; 84+ messages in thread From: Kevin Fox @ 2004-04-05 21:45 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, John Stoffel, Helge Hafting, linux-kernel On Mon, 2004-04-05 at 14:30, Sergiy Lozovsky wrote: > --- Timothy Miller <miller@techsource.com> wrote: > > > > > > Sergiy Lozovsky wrote: > > > > > > > > > > > All LISP errors are incapsulated within LISP VM. > > > > > > > > > A LISP VM is a big, giant, bloated.... *CHOKE* > > *COUGH* *SPUTTER* > > *SUFFOCATE* ... thing which SHOULD NEVER be in the > > kernel. > > It is a smallest interpreter (of all purpose language) > I was able to find. My guess is that you refer to the > Common Lisp. it is huge and I don't use it. > How about BF? ;) I would think something like forth might be a better fit then lisp. > > > > If you want to use a more abstract language for > > describing kernel > > security policies, fine. Just don't use LISP. > > Point me to ANy langage with VM around 100K. > > > The right way to do it is this: > > > > - A user space interpreter reads text-based config > > files and converts > > them into a compact, easy-to-interpret code used by > > the kernel. > > > > - A VERY TINY kernel component is fed the security > > policy and executes it. > > it is exactly the way it is implemented. Not everyone > need to create their own security model (that VERY > TINY kernel component you refer to). But even for > those who want to modify or create their own VERY TINY > kernel component - they don't need to do that in C and > debug it in th kernel crashing it. > > > > > Move as much of the processing as reasonable into > > user space. It's > > absolutely unnecessary to have the parser into the > > kernel, because > > parsing of the config files is done only when the > > ASCII text version > > changes. > > > > It's absolutely unnecessary to have something as > > complex as LISP to > > interpret it, when something simple and compact > > could do just as well. > > > > Why do you choose LISP? Don't you want to use a > > language that sysadmins > > will actually KNOW? > > It was is) the smallest VM I know of. > > 99% of sysadmins don't need to create their own > security models. Security polices are created with web > interface very close to the way you described. So > sysadmin don't need to know anything about LISP (to > use predefined security models). > > Serge. > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > http://promotions.yahoo.com/design_giveaway/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:30 ` Sergiy Lozovsky 2004-04-05 21:45 ` Kevin Fox @ 2004-04-05 21:59 ` Robin Rosenberg 2004-04-05 22:52 ` Sergiy Lozovsky 2004-04-05 22:20 ` Timothy Miller 2004-04-06 20:16 ` Horst von Brand 3 siblings, 1 reply; 84+ messages in thread From: Robin Rosenberg @ 2004-04-05 21:59 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, John Stoffel, Helge Hafting, linux-kernel On Monday 05 April 2004 23:30, Sergiy Lozovsky wrote: > Point me to ANy langage with VM around 100K. There is a Java VM (lejos) för the Lego Mindstorms robot. The hardware has 32K memory. -- robin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:59 ` Robin Rosenberg @ 2004-04-05 22:52 ` Sergiy Lozovsky 2004-04-06 0:46 ` Robin Rosenberg 2004-04-06 0:55 ` Robin Rosenberg 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 22:52 UTC (permalink / raw) To: Robin Rosenberg; +Cc: Timothy Miller, John Stoffel, Helge Hafting, linux-kernel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 594 bytes --] --- Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote: > On Monday 05 April 2004 23:30, Sergiy Lozovsky > wrote: > > Point me to ANy langage with VM around 100K. > > There is a Java VM (lejos) för the Lego Mindstorms > robot. The hardware > has 32K memory. Is it Free and Open Source? Where can I get it if it is? (I don't want to start Holly War :-) but I think, that Java is lower lavel than C, I recognize, that I can be wrong) Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 22:52 ` Sergiy Lozovsky @ 2004-04-06 0:46 ` Robin Rosenberg 2004-04-06 0:55 ` Robin Rosenberg 1 sibling, 0 replies; 84+ messages in thread From: Robin Rosenberg @ 2004-04-06 0:46 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, John Stoffel, Helge Hafting, linux-kernel On Tuesday 06 April 2004 00:52, you wrote: > --- Robin Rosenberg <robin.rosenberg.lists@dewire.com> > > wrote: > > On Monday 05 April 2004 23:30, Sergiy Lozovsky > > > > wrote: > > > Point me to ANy langage with VM around 100K. > > > > There is a Java VM (lejos) för the Lego Mindstorms > > robot. The hardware > > has 32K memory. > > Is it Free and Open Source? Where can I get it if it > is? www.lejos.org. Mozilla License 1.0 (Not sure about GPL compatibility if you were to have wierd plans). But, it has no GC- I doubt adding GC would add many K's. On the other hand you might want to be careful with GC inside the kernel :-) -- robin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 22:52 ` Sergiy Lozovsky 2004-04-06 0:46 ` Robin Rosenberg @ 2004-04-06 0:55 ` Robin Rosenberg 2004-04-06 3:02 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Robin Rosenberg @ 2004-04-06 0:55 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, John Stoffel, Helge Hafting, linux-kernel On Tuesday 06 April 2004 00:52, Sergiy Lozovsky wrote: > (I don't want to start Holly War :-) but I think, that > Java is lower lavel than C, I recognize, that I can be > wrong) Yes, you could..., but that's OT. Isn't LISP lower level. Just the names of it's instructions (Content of Address part of Register and Content of Decrement part of Register) imply that. Shudddrdrrddrr. :-) I like Lisp, it's a hacker language, or was at least. -- robin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 0:55 ` Robin Rosenberg @ 2004-04-06 3:02 ` Sergiy Lozovsky 2004-04-06 3:04 ` Randy.Dunlap 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 3:02 UTC (permalink / raw) To: Robin Rosenberg; +Cc: Timothy Miller, John Stoffel, Helge Hafting, linux-kernel --- Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote: > On Tuesday 06 April 2004 00:52, Sergiy Lozovsky > wrote: > > (I don't want to start Holly War :-) but I think, > that > > Java is lower lavel than C, I recognize, that I > can be > > wrong) > Yes, you could..., but that's OT. Isn't LISP lower > level. Just > the names of it's instructions (Content of Address > part of Register and > Content of Decrement part of Register) imply that. > Shudddrdrrddrr. :-) > > I like Lisp, it's a hacker language, or was at > least. > > -- robin Sounds like music to me :-) If I would not be (very) familiar with LISP prior to that project, I would not chose it probably. It's syntax is so simple (it is a marvel :-) I would think twice to put in the kernel something with more complex syntax. After all Emacs uses LISP, too :-) Though it is this big one - Common Lisp :-) Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 3:02 ` Sergiy Lozovsky @ 2004-04-06 3:04 ` Randy.Dunlap 0 siblings, 0 replies; 84+ messages in thread From: Randy.Dunlap @ 2004-04-06 3:04 UTC (permalink / raw) To: Sergiy Lozovsky Cc: robin.rosenberg.lists, miller, stoffel, helgehaf, linux-kernel On Mon, 5 Apr 2004 20:02:00 -0700 (PDT) Sergiy Lozovsky <serge_lozovsky@yahoo.com> wrote: | | --- Robin Rosenberg <robin.rosenberg.lists@dewire.com> | wrote: | > On Tuesday 06 April 2004 00:52, Sergiy Lozovsky | > wrote: | > > (I don't want to start Holly War :-) but I think, | > that | > > Java is lower lavel than C, I recognize, that I | > can be | > > wrong) | > Yes, you could..., but that's OT. Isn't LISP lower | > level. Just | > the names of it's instructions (Content of Address | > part of Register and | > Content of Decrement part of Register) imply that. | > Shudddrdrrddrr. :-) | > | > I like Lisp, it's a hacker language, or was at | > least. | > | > -- robin | | | Sounds like music to me :-) If I would not be (very) | familiar with LISP prior to that project, I would not | chose it probably. It's syntax is so simple (it is a | marvel :-) I would think twice to put in the kernel | something with more complex syntax. | | After all Emacs uses LISP, too :-) Though it is this | big one - Common Lisp :-) I always knew that emacs was just another OS. 8;} -- ~Randy ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:30 ` Sergiy Lozovsky 2004-04-05 21:45 ` Kevin Fox 2004-04-05 21:59 ` Robin Rosenberg @ 2004-04-05 22:20 ` Timothy Miller 2004-04-05 23:27 ` Sergiy Lozovsky 2004-04-06 20:16 ` Horst von Brand 3 siblings, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-05 22:20 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: John Stoffel, Helge Hafting, linux-kernel Sergiy Lozovsky wrote: > --- Timothy Miller <miller@techsource.com> wrote: > >> >>Sergiy Lozovsky wrote: >> >> >>> >>>All LISP errors are incapsulated within LISP VM. >>> >> >> >>A LISP VM is a big, giant, bloated.... *CHOKE* >>*COUGH* *SPUTTER* >>*SUFFOCATE* ... thing which SHOULD NEVER be in the >>kernel. > > > It is a smallest interpreter (of all purpose language) > I was able to find. My guess is that you refer to the > Common Lisp. it is huge and I don't use it. Did you separate out the parser out into a user-space daemon? Also, if you want a regular programming language with an extremely small interpreter, try Forth. Learning Forth should be at LEAST as much fun as learning LISP. > > >>If you want to use a more abstract language for >>describing kernel >>security policies, fine. Just don't use LISP. > > > Point me to ANy langage with VM around 100K. I bet a Forth interpreter would be smaller. And for something specialized like security policy, you could probably develop your own language and interpreter for it, and it would be smaller (and faster) still. > > >>The right way to do it is this: >> >>- A user space interpreter reads text-based config >>files and converts >>them into a compact, easy-to-interpret code used by >>the kernel. >> >>- A VERY TINY kernel component is fed the security >>policy and executes it. > > > it is exactly the way it is implemented. Not everyone > need to create their own security model (that VERY > TINY kernel component you refer to). But even for > those who want to modify or create their own VERY TINY > kernel component - they don't need to do that in C and > debug it in th kernel crashing it. You misunderstand. When I say "VERY TINY kernel component", I'm referring to the interpreter. Done properly, the pcode for the policy itself would be microscopic. > > >>Move as much of the processing as reasonable into >>user space. It's >>absolutely unnecessary to have the parser into the >>kernel, because >>parsing of the config files is done only when the >>ASCII text version >>changes. >> >>It's absolutely unnecessary to have something as >>complex as LISP to >>interpret it, when something simple and compact >>could do just as well. >> >>Why do you choose LISP? Don't you want to use a >>language that sysadmins >>will actually KNOW? > > > It was is) the smallest VM I know of. Forth. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 22:20 ` Timothy Miller @ 2004-04-05 23:27 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 23:27 UTC (permalink / raw) To: Timothy Miller; +Cc: John Stoffel, Helge Hafting, linux-kernel I wanted something higher level than C. Forth looks like C to me. I wanted something with build in support of complex structures and automatic memory management. I see no reason to replace one C with another. > Did you separate out the parser out into a > user-space daemon? I didn't. It's possible optimization, but it will not give any good. The syntax of LISP is much simpler than Forth (this another reason I chose LISP :-), so parser is very small. > >>Why do you choose LISP? Don't you want to use a > >>language that sysadmins > >>will actually KNOW? At the start of the project I tried to design my own small language (just for security system). At this point I understood that I didn't want to settle with anything less than universal language. The idea to invent some language and write VM for it didn't appeal to me. I wanted to make a security system, not a new language. I wanted language to be as simple as possible. LISP had the simpliest syntax from all languages. So I found small lisp interpreter (kind of real time - without garbage collector which stops execution) added string and bit operations, modified it to be placed in the kernel. Ok, it was my marketing claim about sysadmins :-) Sysadmins use web interface to configure polices and don't deal with LISP at all. LISP is for those who want to change security Models only. Serge. --- Timothy Miller <miller@techsource.com> wrote: > > > Sergiy Lozovsky wrote: > > --- Timothy Miller <miller@techsource.com> wrote: > > > >> > >>Sergiy Lozovsky wrote: > >> > >> > >>> > >>>All LISP errors are incapsulated within LISP VM. > >>> > >> > >> > >>A LISP VM is a big, giant, bloated.... *CHOKE* > >>*COUGH* *SPUTTER* > >>*SUFFOCATE* ... thing which SHOULD NEVER be in the > >>kernel. > > > > > > It is a smallest interpreter (of all purpose > language) > > I was able to find. My guess is that you refer to > the > > Common Lisp. it is huge and I don't use it. > > Did you separate out the parser out into a > user-space daemon? > > Also, if you want a regular programming language > with an extremely small > interpreter, try Forth. > > Learning Forth should be at LEAST as much fun as > learning LISP. > > > > > > >>If you want to use a more abstract language for > >>describing kernel > >>security policies, fine. Just don't use LISP. > > > > > > Point me to ANy langage with VM around 100K. > > I bet a Forth interpreter would be smaller. > > And for something specialized like security policy, > you could probably > develop your own language and interpreter for it, > and it would be > smaller (and faster) still. > > > > > > >>The right way to do it is this: > >> > >>- A user space interpreter reads text-based config > >>files and converts > >>them into a compact, easy-to-interpret code used > by > >>the kernel. > >> > >>- A VERY TINY kernel component is fed the security > >>policy and executes it. > > > > > > it is exactly the way it is implemented. Not > everyone > > need to create their own security model (that VERY > > TINY kernel component you refer to). But even for > > those who want to modify or create their own VERY > TINY > > kernel component - they don't need to do that in C > and > > debug it in th kernel crashing it. > > You misunderstand. When I say "VERY TINY kernel > component", I'm > referring to the interpreter. Done properly, the > pcode for the policy > itself would be microscopic. > > > > > > >>Move as much of the processing as reasonable into > >>user space. It's > >>absolutely unnecessary to have the parser into the > >>kernel, because > >>parsing of the config files is done only when the > >>ASCII text version > >>changes. > >> > >>It's absolutely unnecessary to have something as > >>complex as LISP to > >>interpret it, when something simple and compact > >>could do just as well. > >> > >>Why do you choose LISP? Don't you want to use a > >>language that sysadmins > >>will actually KNOW? > > > > > > It was is) the smallest VM I know of. > > Forth. > > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:30 ` Sergiy Lozovsky ` (2 preceding siblings ...) 2004-04-05 22:20 ` Timothy Miller @ 2004-04-06 20:16 ` Horst von Brand 2004-04-06 20:58 ` Timothy Miller 3 siblings, 1 reply; 84+ messages in thread From: Horst von Brand @ 2004-04-06 20:16 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > --- Timothy Miller <miller@techsource.com> wrote: > > > > > > Sergiy Lozovsky wrote: > > > > > > > > > > > All LISP errors are incapsulated within LISP VM. > > > > > > > > > A LISP VM is a big, giant, bloated.... *CHOKE* > > *COUGH* *SPUTTER* > > *SUFFOCATE* ... thing which SHOULD NEVER be in the > > kernel. > > It is a smallest interpreter (of all purpose language) > I was able to find. My guess is that you refer to the > Common Lisp. it is huge and I don't use it. Nope. Timothy was talking exactly of the same one as you. And I agree with him. > > If you want to use a more abstract language for > > describing kernel > > security policies, fine. Just don't use LISP. > > Point me to ANy langage with VM around 100K. Assembler. VM is exactly _zero_ overhead. Or C, for a tiny bit more. That one was already paid for, so you essentially get it for free. Might also hack FORTH, for a few KiB (dunno how much this days, but should be less than 10 for a stripped to the bone package). > > The right way to do it is this: > > > > - A user space interpreter reads text-based config > > files and converts > > them into a compact, easy-to-interpret code used by > > the kernel. > > > > - A VERY TINY kernel component is fed the security > > policy and executes it. Nodz! > it is exactly the way it is implemented. And how does an _in kernel_ LISP interpreter fit into this picture? Lost me there... > Not everyone > need to create their own security model (that VERY > TINY kernel component you refer to). Now we have common ground... > But even for > those who want to modify or create their own VERY TINY > kernel component - they don't need to do that in C and > debug it in th kernel crashing it. ... of sorts. Right, I don't want the security kernel inside the kernel crashing. But then again, I don't want the driver for the hard disk, or the mouse, or even the graphic card, scribbling over memory either. Guess you'd (re)write the whole kernel in some LISP dialect then? Good luck! But this is _certainly_ the worst list to discuss such a design. [...] > > Why do you choose LISP? Don't you want to use a > > language that sysadmins > > will actually KNOW? > > It was is) the smallest VM I know of. You know little... > 99% of sysadmins don't need to create their own > security models. Security polices are created with web > interface very close to the way you described. So > sysadmin don't need to know anything about LISP (to > use predefined security models). OK, so you need the policy to be interpreted in-kernel (dunno why a largeish high-level general purpose language is needed for that, when a tiny interpreter for a specialized language will do very well, and has been shown to work fine), and written in a "high level language" so that your garden variety sysadmin _can_ write her own policy, but it really doesn't matter because she'll never have to do so... Completely lost me. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 20:16 ` Horst von Brand @ 2004-04-06 20:58 ` Timothy Miller 2004-04-06 22:05 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-06 20:58 UTC (permalink / raw) To: Horst von Brand; +Cc: Sergiy Lozovsky, Linux Kernel Mailing List Horst von Brand wrote: > OK, so you need the policy to be interpreted in-kernel (dunno why a > largeish high-level general purpose language is needed for that, when a > tiny interpreter for a specialized language will do very well, and has been > shown to work fine), and written in a "high level language" so that your > garden variety sysadmin _can_ write her own policy, but it really doesn't > matter because she'll never have to do so... > > Completely lost me. I was getting hung up on that one too, but I didn't know how to say it. You did a nice job. :) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 20:58 ` Timothy Miller @ 2004-04-06 22:05 ` Sergiy Lozovsky 2004-04-06 22:56 ` Timothy Miller 2004-04-07 2:44 ` Horst von Brand 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 22:05 UTC (permalink / raw) To: Timothy Miller, Horst von Brand; +Cc: linux-kernel --- Timothy Miller <miller@techsource.com> wrote: > > > Horst von Brand wrote: > > > OK, so you need the policy to be interpreted > in-kernel (dunno why a > > largeish high-level general purpose language is > needed for that, when a > > tiny interpreter for a specialized language will > do very well, and has been > > shown to work fine), and written in a "high level > language" so that your > > garden variety sysadmin _can_ write her own > policy, but it really doesn't > > matter because she'll never have to do so... > > > > Completely lost me. > > I was getting hung up on that one too, but I didn't > know how to say it. > You did a nice job. :) Can you guys be more specific? I don't see any technical objections. The only one is that performance would suffer because of use of higher level language than C or Assembler. There is a reason people use languages like PERL, Java and so on. I would prefer to spend less time writing actual code - this is what these high level languages for. If performance would be most important - people would do everything in Assembler, but they don't. I'd better write a small Assembler subroutine which will handle stack problems for me and benefit from using the high level language after that. There were times when userland projects were written in Assembler. Now people are using other languages, too. May be it's time to try something new in the kernel, too :-) Or we will not consider that because nobody did that before? Someone should be the first :-) Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 22:05 ` Sergiy Lozovsky @ 2004-04-06 22:56 ` Timothy Miller 2004-04-06 23:17 ` Sergiy Lozovsky 2004-04-07 2:44 ` Horst von Brand 1 sibling, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-06 22:56 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Horst von Brand, linux-kernel Sergiy Lozovsky wrote: > --- Timothy Miller <miller@techsource.com> wrote: > >> >>Horst von Brand wrote: >>>OK, so you need the policy to be interpreted >>in-kernel (dunno why a >>>largeish high-level general purpose language is >>needed for that, when a >>>tiny interpreter for a specialized language will >>do very well, and has been >>>shown to work fine), and written in a "high level >>language" so that your >>>garden variety sysadmin _can_ write her own >>policy, but it really doesn't >>>matter because she'll never have to do so... >>>Completely lost me. >> >>I was getting hung up on that one too, but I didn't >>know how to say it. >> You did a nice job. :) > > > Can you guys be more specific? I don't see any > technical objections. The only one is that performance > would suffer because of use of higher level language > than C or Assembler. That IS one of the objections, but it's not the objection HERE. The objection here is that we see an inconsistency: A) You support the idea of using LISP because it's a high-level language that sysadmins can use to develop policies. B) But then you say that sysadmins won't be developing policies. Therefore, you invalidate your reason for wanting to use LISP. > > There is a reason people use languages like PERL, Java > and so on. I would prefer to spend less time writing > actual code - this is what these high level languages > for. If performance would be most important - people > would do everything in Assembler, but they don't. I'd > better write a small Assembler subroutine which will > handle stack problems for me and benefit from using > the high level language after that. As a matter of fact, the only reason people object to using LISP is because you want to do it IN THE KERNEL. If you want the interpreter to live in the kernel, then you have to use something MUCH SIMPLER and something which doesn't eat stack like LISP does. On the other hand, if you were to put hooks into the kernel so that people could use ANY LANGUAGE THEY WANTED, IN USER SPACE, then people would be very happy with you. This way, you can waste all the memory you want on the interpreter, but it's okay because it's: (1) extremely optional (2) extremely replacable (interpretor can be any language) (3) swappable (4) can't clobber the kernel (5) can use as much stack space as it wants (6) minimally impacts what IS in the kernel, etc. You down-play the performance impact of using LISP above, but you contradict that by saying you want to put the interpreter in the kernel for performance reasons. You can't have it both ways. Either you're concerned about performance (and you use something efficient and compact), or you're not concenred about performance (and you use whatever high-level language you want IN USERSPACE). > > There were times when userland projects were written > in Assembler. Now people are using other languages, > too. May be it's time to try something new in the > kernel, too :-) Or we will not consider that because > nobody did that before? Someone should be the first > :-) The kernel is not the appropriate place for this. An OS kernel exists to provide a minimal set of services necessary for applications to make efficient use of resources. (Microkernels take this to the extreme with their layering.) Only when something CANNOT be accomplished in userspace (or performance in userspace is terrible) should something be put into the kernel. As I've said before, the overhead of actually interpreting a high-level language is probably great enough that the context-switch overhead you don't want would diminish. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 22:56 ` Timothy Miller @ 2004-04-06 23:17 ` Sergiy Lozovsky 2004-04-08 13:11 ` Martin Waitz 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 23:17 UTC (permalink / raw) To: Timothy Miller; +Cc: Horst von Brand, linux-kernel --- Timothy Miller <miller@techsource.com> wrote: > > > Sergiy Lozovsky wrote: > > --- Timothy Miller <miller@techsource.com> wrote: > > > >> > >>Horst von Brand wrote: > > >>>OK, so you need the policy to be interpreted > >>in-kernel (dunno why a > >>>largeish high-level general purpose language is > >>needed for that, when a > >>>tiny interpreter for a specialized language will > >>do very well, and has been > >>>shown to work fine), and written in a "high level > >>language" so that your > >>>garden variety sysadmin _can_ write her own > >>policy, but it really doesn't > >>>matter because she'll never have to do so... > >>>Completely lost me. > >> > >>I was getting hung up on that one too, but I > didn't > >>know how to say it. > >> You did a nice job. :) > > > > > > Can you guys be more specific? I don't see any > > technical objections. The only one is that > performance > > would suffer because of use of higher level > language > > than C or Assembler. > > That IS one of the objections, but it's not the > objection HERE. > > The objection here is that we see an inconsistency: > > A) You support the idea of using LISP because it's a > high-level language > that sysadmins can use to develop policies. > > B) But then you say that sysadmins won't be > developing policies. > > Therefore, you invalidate your reason for wanting to > use LISP If I would say, that policy administrator change security policy (not system administrator :-). Would it be an answer to your question? I don't want this person to be a kernel guru and make him write a C code for Kernel. I don't want errors of this person to affect all the system - which is a case with precompiled loadable C module. > > > > There is a reason people use languages like PERL, > Java > > and so on. I would prefer to spend less time > writing > > actual code - this is what these high level > languages > > for. If performance would be most important - > people > > would do everything in Assembler, but they don't. > I'd > > better write a small Assembler subroutine which > will > > handle stack problems for me and benefit from > using > > the high level language after that. > > As a matter of fact, the only reason people object > to using LISP is > because you want to do it IN THE KERNEL. > > If you want the interpreter to live in the kernel, > then you have to use > something MUCH SIMPLER and something which doesn't > eat stack like LISP does. What? Give an example. I want something high level, so Forth will not do. Sure, encapsulation is needed, to protect kernel from pointer errors and so on. > On the other hand, if you were to put hooks into the > kernel so that > people could use ANY LANGUAGE THEY WANTED, IN USER > SPACE, then people > would be very happy with you. This way, you can > waste all the memory > you want on the interpreter, but it's okay because > it's: > > (1) extremely optional > (2) extremely replacable (interpretor can be any > language) > (3) swappable > (4) can't clobber the kernel > (5) can use as much stack space as it wants > (6) minimally impacts what IS in the kernel, etc. > > You down-play the performance impact of using LISP > above, but you > contradict that by saying you want to put the > interpreter in the kernel > for performance reasons. You can't have it both > ways. Either you're > concerned about performance (and you use something > efficient and > compact), or you're not concenred about performance > (and you use > whatever high-level language you want IN USERSPACE). I'm looking for balance. I want to benefit from high level language and have reasonable performance. > > > > > > There were times when userland projects were > written > > in Assembler. Now people are using other > languages, > > too. May be it's time to try something new in the > > kernel, too :-) Or we will not consider that > because > > nobody did that before? Someone should be the > first > > :-) > > The kernel is not the appropriate place for this. > An OS kernel exists > to provide a minimal set of services necessary for > applications to make > efficient use of resources. (Microkernels take this > to the extreme with > their layering.) This is a good explanation, why I use kernel. You admitted that microkernels are extreme. I didn't want to change such basic architectural model of Linux. What you suggest to do is to make microkernel. Sys call goes to kernel, instead of serving this request you suggest to forward this call to the userspace, than get it back and continue to serv it in the kernel. Worse of two worlds - kernels serv syscalls inside, microkernels - outside; you suggest to serv it both - outside and inside. It was hard for me to predict performance and architectural penalties of such solution. For each syscall perform - task switch (can we predict when scheduler decided to give control to the userspace security server and than back to initial appliaction?), context switch (kernelspace/userspace and back), priority switch - process which issued sys call is with one priority, security server - with another. System behaviour become very complex and forwarding syscalls to userspace affects basic architecture of Linux. > Only when something CANNOT be > accomplished in > userspace (or performance in userspace is terrible) > should something be > put into the kernel. > > As I've said before, the overhead of actually > interpreting a high-level > language is probably great enough that the > context-switch overhead you > don't want would diminish. This overhead is very predictable (having the size of particular security policy and defined security model). So it close to real-time, which is good for kernel. Switching between tasks, environments and priorites during the service of just one system call is not predicatble at all and more complex. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 23:17 ` Sergiy Lozovsky @ 2004-04-08 13:11 ` Martin Waitz 2004-04-08 22:33 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: Martin Waitz @ 2004-04-08 13:11 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Timothy Miller, Horst von Brand, linux-kernel [-- Attachment #1: Type: text/plain, Size: 821 bytes --] hi :) On Tue, Apr 06, 2004 at 04:17:34PM -0700, Sergiy Lozovsky wrote: > What? Give an example. I want something high level, so > Forth will not do. Sure, encapsulation is needed, to > protect kernel from pointer errors and so on. who says that the language that's used by your policy administrator is the same as the language interpreted by the kernel? let your administrator write his policy in java/lisp or whatever, but compile this policy into an easy to interpret and safe bytecode. -- CU, / Friedrich-Alexander University Erlangen, Germany Martin Waitz // Department of Computer Science 12 _________ ______________/// - - - - - - - - - - - - - - - - - - - - /// dies ist eine manuell generierte mail, sie beinhaltet // tippfehler und ist auch ohne grossbuchstaben gueltig. / [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 13:11 ` Martin Waitz @ 2004-04-08 22:33 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-08 22:33 UTC (permalink / raw) To: Martin Waitz; +Cc: Timothy Miller, Horst von Brand, linux-kernel Hi, :-) --- Martin Waitz <tali@admingilde.org> wrote: > hi :) > > On Tue, Apr 06, 2004 at 04:17:34PM -0700, Sergiy > Lozovsky wrote: > > What? Give an example. I want something high > level, so > > Forth will not do. Sure, encapsulation is needed, > to > > protect kernel from pointer errors and so on. > > who says that the language that's used by your > policy administrator > is the same as the language interpreted by the > kernel? > > let your administrator write his policy in java/lisp > or whatever, > but compile this policy into an easy to interpret > and safe > bytecode. That will not give any benefits. LISP has internal representation of program and data for sure ('bytecode'), but it is lists. How to unload it to something one can move around? One of the ways - unload it in a text form. But it exactly what initial source code is. Parser of LISP is very small (because syntax is simple), so producing some non standard bytecode make no sense - source code of LISP is very close to it's 'bytecode'. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 22:05 ` Sergiy Lozovsky 2004-04-06 22:56 ` Timothy Miller @ 2004-04-07 2:44 ` Horst von Brand 2004-04-07 17:54 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Horst von Brand @ 2004-04-07 2:44 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > --- Timothy Miller <miller@techsource.com> wrote: > > Horst von Brand wrote: > > > OK, so you need the policy to be interpreted in-kernel (dunno why > > > a largeish high-level general purpose language is needed for that, > > > when a tiny interpreter for a specialized language will do very well, > > > and has been shown to work fine), and written in a "high level > > > language" so that your garden variety sysadmin _can_ write her own > > > policy, but it really doesn't matter because she'll never have to do > > > so... > > > Completely lost me. > > I was getting hung up on that one too, but I didn't > > know how to say it. > > You did a nice job. :) > Can you guys be more specific? I don't see any > technical objections. As they say around here "No hay peor ciego que el que no quiere ver" (roughly, "There is no worse blindness than not wanting to see")... > The only one is that performance > would suffer because of use of higher level language > than C or Assembler. Because the performance and size of kernel code is _critical_, maybe? Because much of the kernel code has been carefully tuned for maximum performance perhaps? > There is a reason people use languages like PERL, Java > and so on. And there are solid reasons for _not_ writing operating system kernels in them too... > I would prefer to spend less time writing > actual code - this is what these high level languages > for. If performance would be most important - people > would do everything in Assembler, but they don't. I'd > better write a small Assembler subroutine which will > handle stack problems for me and benefit from using > the high level language after that. And then there is the technology of _inventing_ a language tailored to the task at hand... even better than your list of high-level languages. > There were times when userland projects were written > in Assembler. Now people are using other languages, > too. In part because a mediocre compiler these days gives better code than an assembly language coder by hand... and you can compile it for next year's machine too. > May be it's time to try something new in the > kernel, too :-) Or we will not consider that because > nobody did that before? Someone should be the first > :-) It's your time you are wasting... have my blessing. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 2:44 ` Horst von Brand @ 2004-04-07 17:54 ` Sergiy Lozovsky 2004-04-08 2:43 ` Horst von Brand 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-07 17:54 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > --- Timothy Miller <miller@techsource.com> wrote: > > > Horst von Brand wrote: > > I would prefer to spend less time > writing > > actual code - this is what these high level > languages > > for. If performance would be most important - > people > > would do everything in Assembler, but they don't. > I'd > > better write a small Assembler subroutine which > will > > handle stack problems for me and benefit from > using > > the high level language after that. > > And then there is the technology of _inventing_ a > language tailored to the > task at hand... even better than your list of > high-level languages. I started exactly with that. I found out shortly that have no idea of functionality needed for such kind of system. It was clear that requirments for this sytem can change rapidly. Only general purpose language can address this problem (if we want to save time of development and introduction of new security models). Example. Current security policies are 'static'. It seems, that it would be nice to have 'dynamic' policies (with support from security model). Now, policy describes resources available for subsystem. It may be useful to limit the sequence of access to resources - 'behaviour' of subsystem. I'm not sure if I want to implement that right away, but there is commercial system which does exactly that already (it was created later than VXE). Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 17:54 ` Sergiy Lozovsky @ 2004-04-08 2:43 ` Horst von Brand 2004-04-08 4:07 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: Horst von Brand @ 2004-04-08 2:43 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: [...] > > And then there is the technology of _inventing_ a > > language tailored to the > > task at hand... even better than your list of > > high-level languages. > I started exactly with that. I found out shortly that > have no idea of functionality needed for such kind of > system. Come back when you have found out. > It was clear that requirments for this sytem > can change rapidly. I would not trust anything with "rapidly changing requirements" as security infrastructure. > Only general purpose language can > address this problem (if we want to save time of > development and introduction of new security models). A security model has to be exhaustively scrutinized, proved correct and complete, and well-tested. The implementation language is completely irrelevant, the hard work is _not_ programming. > Example. Current security policies are 'static'. In what sense? > It > seems, that it would be nice to have 'dynamic' > policies (with support from security model). Again, what does this mean? > Now, > policy describes resources available for subsystem. No... > It > may be useful to limit the sequence of access to > resources - 'behaviour' of subsystem. I'm not sure if > I want to implement that right away, but there is > commercial system which does exactly that already (it > was created later than VXE). What is the use of restricting access sequences? If sequence A, B, C is forbidden, chances are that C, B, A (or any of the other 4 permutations) will give an attacker exactly what he wants. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 2:43 ` Horst von Brand @ 2004-04-08 4:07 ` Sergiy Lozovsky 2004-04-08 4:29 ` Horst von Brand 2004-04-08 15:44 ` Valdis.Kletnieks 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-08 4:07 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > [...] > > > > And then there is the technology of _inventing_ > a > > > language tailored to the > > > task at hand... even better than your list of > > > high-level languages. > > > I started exactly with that. I found out shortly > that > > have no idea of functionality needed for such kind > of > > system. > > Come back when you have found out. Sorry. I live in the real world. In 1999 I had servers to protect. One of them was hacked and I started to look for tools which could protect servers. I found NOTHING. (there were some Intrusion Detection Systems, which would alert you when your server was ALREADY hacked - it was completely unacceptable for me). So I created VXE. Problem was solved. I could not sit and think about some perfect design while my servers were in the net unprotected, it's too expensive. Speed is not most important for me. If I have fast but unprotected server - it is of no use for me. > > > It was clear that requirments for this > sytem > > can change rapidly. > > I would not trust anything with "rapidly changing > requirements" as security > infrastructure. VXE worked for me. It was much better than nothing. > > Only general purpose language > can > > address this problem (if we want to save time of > > development and introduction of new security > models). > > A security model has to be exhaustively scrutinized, > proved correct and > complete, and well-tested. The implementation > language is completely > irrelevant, the hard work is _not_ programming. > > > Example. Current security policies are 'static'. > > In what sense? Actually one 'dynamic' feature is implemented in VXE. In ordinary system resource has permissions which allows access or not. For higher security VXE can count number of allowed accesses. For example, we are securing POP server. We allow it to open /etc/passwd, /etc/shadow for reading only once (counter is 1). So, if hacker breaks to POP server after it opened /etc/passwd - there is no way hacker can open this file. Another 'dynamic' feature is changing policy on the fly. For now POP server can access all mailboxes in /var/spool/mail - it's easy to add ability to modify policy. After POP server authorized user it changes it's UID - at that point we can set access to /var/spool/mail/user_1 only. So POPD couldn't access other files in all mailbox directories. > > > It > > seems, that it would be nice to have 'dynamic' > > policies (with support from security model). > > Again, what does this mean? > > > Now, > > policy describes resources available for > subsystem. > > No... > > > > It > > may be useful to limit the sequence of access to > > resources - 'behaviour' of subsystem. I'm not sure > if > > I want to implement that right away, but there is > > commercial system which does exactly that already > (it > > was created later than VXE). > > What is the use of restricting access sequences? If > sequence A, B, C is > forbidden, chances are that C, B, A (or any of the > other 4 permutations) > will give an attacker exactly what he wants. VXE can have counters assigned to syscall parameters. More sophisticated way is to have determined sequence of syscalls. So, if hackers broke in the system (sendmail for example) he can just follow logic of the system - do the work of sendmail for you :-) I can't say how easy to use this, but the company (my competitors :-) which created this is entercept.com - it seems, that they were very successful - I went to their site right now and was redirected to Network Associates - they were bought out, my guess. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 4:07 ` Sergiy Lozovsky @ 2004-04-08 4:29 ` Horst von Brand 2004-04-08 22:51 ` Sergiy Lozovsky 2004-04-08 15:44 ` Valdis.Kletnieks 1 sibling, 1 reply; 84+ messages in thread From: Horst von Brand @ 2004-04-08 4:29 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: [...] > > > I started exactly with that. I found out shortly that > > > have no idea of functionality needed for such kind of > > > system. > > Come back when you have found out. > Sorry. I live in the real world. In 1999 I had servers > to protect. One of them was hacked and I started to > look for tools which could protect servers. I found > NOTHING. (there were some Intrusion Detection Systems, > which would alert you when your server was ALREADY > hacked - it was completely unacceptable for me). We had an unwellcome visitor in 2001... scrapped SomeOtherUnix shortly thereafter (a "security fix" installed a "remote administration facility" (complete with an extremely nice, well-known hole), which the cracker then used to "remotely administer" our machine...), no further trouble since it is all Linux now. Just be careful in what you install, how you configure, and keep patches up to date. I.e., a bit of common sense and care goes a _long_ way. Security is mostly a _people_ affair, and has much to do with being careful and attention to detail, it is not at all technical. Trying to solve such a people problem with (misguided) technical measures gets you nowhere. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 4:29 ` Horst von Brand @ 2004-04-08 22:51 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-08 22:51 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > [...] > > > > > I started exactly with that. I found out > shortly that > > > > have no idea of functionality needed for such > kind of > > > > system. > > > > Come back when you have found out. > > > Sorry. I live in the real world. In 1999 I had > servers > > to protect. One of them was hacked and I started > to > > look for tools which could protect servers. I > found > > NOTHING. (there were some Intrusion Detection > Systems, > > which would alert you when your server was ALREADY > > hacked - it was completely unacceptable for me). > > We had an unwellcome visitor in 2001... scrapped > SomeOtherUnix shortly > thereafter (a "security fix" installed a "remote > administration facility" > (complete with an extremely nice, well-known hole), > which the cracker then > used to "remotely administer" our machine...), no > further trouble since it > is all Linux now. Just be careful in what you > install, how you configure, > and keep patches up to date. > > I.e., a bit of common sense and care goes a _long_ > way. Security is mostly > a _people_ affair, and has much to do with being > careful and attention to > detail, it is not at all technical. Trying to solve > such a people problem > with (misguided) technical measures gets you > nowhere. I completely agree with you on that. Security is not only technical issues. I was an owner of the company when our server was hacked, so I did all explanations for down time with our customers. (Downtime was significant - server was collocated in another country and it took quite a while for reinstall Linux - different time zone, nobody on 24x7 duty...). Advice to apply all new patches is good, one should do that. But there are problems: 1. One should monitor patch development constantly and be paid for that job (additional expenses). 2. Will be patch available in time and would it be possible to find it - there are questions. 3. Some patches are created after security hole was exploited. I don't want to be among these first sites :-) So, even if you patched everything - there are security holes anyway (patches will be developed in the future). If it is not production server - not a big deal. If it is production - downtimes should be minimal and stealing of sensitive information is unacceptable. If kernel is slow - I'll buy faster hardware with SMP if needed - it's not an issue at all. Not enough - I'll install cluster, but I can't allow system to be compromised. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 4:07 ` Sergiy Lozovsky 2004-04-08 4:29 ` Horst von Brand @ 2004-04-08 15:44 ` Valdis.Kletnieks 2004-04-08 22:22 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Valdis.Kletnieks @ 2004-04-08 15:44 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1378 bytes --] On Wed, 07 Apr 2004 21:07:56 PDT, Sergiy Lozovsky said: > Actually one 'dynamic' feature is implemented in VXE. > In ordinary system resource has permissions which > allows access or not. For higher security VXE can > count number of allowed accesses. For example, we are > securing POP server. We allow it to open /etc/passwd, > /etc/shadow for reading only once (counter is 1). So, > if hacker breaks to POP server after it opened > /etc/passwd - there is no way hacker can open this > file. Unless he finds an already open file descriptor for it and uses read()/write()/mmap()/etc - did you audit your POP server to make *really* sure that endpwent() is called at all the right times, and that said function actually is guaranteed to close() the file descriptor, and can't be forced into failing? (Note that this can be caused by either close() syscall failing, or the attacker managing to hijack the function entry point for either endpwent() or close()....) Unless he finds a copy of the file on the process heap (more than one information leakage issue has come from THAT sort of problem) Unless he opens a new file on the system, and writes a binary into it, chmod's it to executable, and does a pipe/fork/exec and use that program's quota of opens to read it... And that's just the *obvious* end runs. As somebody else noted, writing the code is the easy part.... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 15:44 ` Valdis.Kletnieks @ 2004-04-08 22:22 ` Sergiy Lozovsky 2004-04-09 15:27 ` Jesse Pollard 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-08 22:22 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Linux Kernel Mailing List --- Valdis.Kletnieks@vt.edu wrote: > On Wed, 07 Apr 2004 21:07:56 PDT, Sergiy Lozovsky > said: > > > Actually one 'dynamic' feature is implemented in > VXE. > > In ordinary system resource has permissions which > > allows access or not. For higher security VXE can > > count number of allowed accesses. For example, we > are > > securing POP server. We allow it to open > /etc/passwd, > > /etc/shadow for reading only once (counter is 1). > So, > > if hacker breaks to POP server after it opened > > /etc/passwd - there is no way hacker can open this > > file. > > Unless he finds an already open file descriptor for > it and uses > read()/write()/mmap()/etc - did you audit your POP > server > to make *really* sure that endpwent() is called at > all the right > times, and that said function actually is guaranteed > to close() > the file descriptor, and can't be forced into > failing? (Note that > this can be caused by either close() syscall > failing, or the attacker > managing to hijack the function entry point for > either endpwent() > or close()....) Most common way of hacking a box looks much easier. Usual way of stack problems was - to run shell using security hole. Change root password or create new account with root UID. All these usually done with tools available at the system. VXE use word Environment (description of available resources), some systems use word Domain. There is no shell, ls, vi and so on in POPD Environment. So, most of attackers will just go away. One should be really motivated to master unique binary code to hack VXE protected system. Let's see what is possible even in that case. Let's assume there is a security hole in POPD. One should create custom binary code to inspect RAM. How to communicate information back to hacker? There should be enough code to do that. This code should not destroy POPD to such extent that it will end (or core dumped), because hacker's code will end too. (POPD doesn't need exec or fork for its work, so hacker can't call these syscalls). So, in theory it is possible to do some damage to particular subsystem, but it's nearly impossible to compromise all system. > Unless he finds a copy of the file on the process > heap (more than > one information leakage issue has come from THAT > sort of problem) If you have limited number syscalls (with limited parameters you can call allowed syscalls) - it's VERY hard to do. Purpose of VXE is to protect subsystems, which can have security holes. In real life nobody can gurantee, that there are no security holes in a given system. Some time ago they constantly were finding bugs in sendmail. Nevertheless people were using it. > Unless he opens a new file on the system, and writes > a binary into > it, chmod's it to executable, and does a > pipe/fork/exec and use > that program's quota of opens to read it... POPD doesn't use chmod/fork/exec, so that wouldn't work - there are no these syscalls in POPD Environment. Let's assume some file was created by hacker in /var/spool/mailbox, so what? How that can damage the system. (it's the only directory where POPD can create/modify files). > And that's just the *obvious* end runs. As somebody > else noted, > writing the code is the easy part.... So, in theory it is possible to make some damage to hacked subsystem (POPD for example and damaged can be only mailboxes), but the rest of the system will be intact (and there is a lot of stuff in the system except POPD). But in practice with such striped environment - without shell, editors, limited set of syscalls - generic hackers tools will not work. Only if someone will dedicate efforts to create custom tools for your particular site - he can damage mailboxes at most (in case of POPD). I think, that it is a pretty good result. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-08 22:22 ` Sergiy Lozovsky @ 2004-04-09 15:27 ` Jesse Pollard 0 siblings, 0 replies; 84+ messages in thread From: Jesse Pollard @ 2004-04-09 15:27 UTC (permalink / raw) To: Sergiy Lozovsky, Valdis.Kletnieks; +Cc: Linux Kernel Mailing List On Thursday 08 April 2004 17:22, Sergiy Lozovsky wrote: > > Usual way of stack problems was - to run shell using > security hole. Change root password or create new > account with root UID. All these usually done with > tools available at the system. > > VXE use word Environment (description of available > resources), some systems use word Domain. There is no > shell, ls, vi and so on in POPD Environment. So, most > of attackers will just go away. One should be really > motivated to master unique binary code to hack VXE > protected system. Let's see what is possible even in > that case. > > Let's assume there is a security hole in POPD. One > should create custom binary code to inspect RAM. How > to communicate information back to hacker? There > should be enough code to do that. This code should not > destroy POPD to such extent that it will end (or core > dumped), because hacker's code will end too. (POPD > doesn't need exec or fork for its work, so hacker > can't call these syscalls). So, in theory it is > possible to do some damage to particular subsystem, > but it's nearly impossible to compromise all system. Why shouldn't it? It can just replace the entire code with itself. and since you cannot prevent the use of mmap (which is used to load the runtime libraries AND the executable) it can still do that. > > Unless he finds a copy of the file on the process > > heap (more than > > one information leakage issue has come from THAT > > sort of problem) > > If you have limited number syscalls (with limited > parameters you can call allowed syscalls) - it's VERY > hard to do. Purpose of VXE is to protect subsystems, > which can have security holes. In real life nobody can > gurantee, that there are no security holes in a given > system. Some time ago they constantly were finding > bugs in sendmail. Nevertheless people were using it. And they were fixing it. Not trying to make VERY kluged work arounds in the kernel. > > Unless he opens a new file on the system, and writes > > a binary into > > it, chmod's it to executable, and does a > > pipe/fork/exec and use > > that program's quota of opens to read it... > > POPD doesn't use chmod/fork/exec, so that wouldn't > work - there are no these syscalls in POPD > Environment. Let's assume some file was created by > hacker in /var/spool/mailbox, so what? How that can > damage the system. (it's the only directory where POPD > can create/modify files). You don't need to use chmod/fork/exec. It is entire possible to replace the executable just by using mmap. I've already written programs that deliberately do that (though I did use dlopen). I've written a single binary that do anything. Including running previously build applications. After all - ld.so does just that during the initial load an execed binary. All exec does is start ld.so with different parameters... and nothing says that can't be done again. And just not having a shell program on disk is silly - It can be created rather easily. After all, that is what root kits do routinely. > > And that's just the *obvious* end runs. As somebody > > else noted, > > writing the code is the easy part.... > > So, in theory it is possible to make some damage to > hacked subsystem (POPD for example and damaged can be > only mailboxes), but the rest of the system will be > intact (and there is a lot of stuff in the system > except POPD). But in practice with such striped > environment - without shell, editors, limited set of > syscalls - generic hackers tools will not work. Only > if someone will dedicate efforts to create custom > tools for your particular site - he can damage > mailboxes at most (in case of POPD). I think, that it > is a pretty good result. It would be better to use a chroot environment. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 17:59 ` Sergiy Lozovsky 2004-04-05 19:27 ` Valdis.Kletnieks 2004-04-05 20:09 ` John Stoffel @ 2004-04-05 21:12 ` Timothy Miller 2 siblings, 0 replies; 84+ messages in thread From: Timothy Miller @ 2004-04-05 21:12 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Helge Hafting, linux-kernel Sergiy Lozovsky wrote: > > 1. Give system administrator possibility to change > security policy easy enough without C programminig > inside the kernel (we should not expect system > administartor to be a kernel guru). Language of higher > lavel make code more compact (C - is too low level, > that's why people use PERL for example or LISP). Lisp > was chosen because of very compact VM - around 100K. And you expect your sysadmins to know LISP? I would hardly think of LISP as any kind of simplification to anything. I mean, I like the language and all, but it is in no way "simpler" than C and it's definately not appropriate for in-kernel stuff. > > 2. Protect system from bugs in security policy created > by system administrator (user). LISP interpreter is a > LISP Virtual Machine (as Java VM). So all bugs are > incapsulated and don't affect kernel. Even severe bugs > in this LISP kernel module can cause termination of > user space application only (except of stack overflow > - which I can address). LISP error message will be > printed in the kernel log. In theory, we could develop the kernel in a language that does all sorts of protection, garbage collection, run-time checking, etc. Kernel developers choose not to because the performance hit would be HORRIBLE. Now... that doesn't mean you can't do kernel-level stuff in LISP. You just don't do it _in_ the kernel. Given the absolutely MASSIVE overhead you're already incurring by using a LISP interpreter, having to context-switch into user space won't hurt in the least. So, what you do is have a C-based stub in the kernel which passes stuff off to the user-space LISP daemon which calls back into the kernel for accessing devices, etc. THAT would be a much better way of doing this. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 17:05 ` Sergiy Lozovsky 2004-04-05 18:06 ` Timothy Miller @ 2004-04-06 13:32 ` Helge Hafting 2004-04-06 17:44 ` Sergiy Lozovsky 2004-04-06 18:33 ` Jamie Lokier 1 sibling, 2 replies; 84+ messages in thread From: Helge Hafting @ 2004-04-06 13:32 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Helge Hafting, linux-kernel On Mon, Apr 05, 2004 at 10:05:37AM -0700, Sergiy Lozovsky wrote: > > Consider rewriting your function to use allocated > > memory instead of stack, this isn't all that hard. > > I put LISP interpreter inside the Kernel - > http://vxe.quercitron.com > > It works, but it use a lot of stack memory. It's > impossible to rewrite it easily, though I'll > investigate why exactly it uses so much of stack > memory (though it's nature of LISP). There are no > serious kernel memory allocation (as of my interpreter > code review, only function calls; recursions in LISP > application itself are eliminated for sure), but I'll > trace stack usage more thouroughly. > Consider this. We're currently experimenting with a transition from 8k to 4k stacks on x86, and that is considered a very good thing. Allocating a single- page stack is easy, two (contigous) pages might fail. So a bigger kernel stack is out. As for rewriting code so it doesn't use stack - it _is_ easy, but it might be a lot of _work_. The simple approach is to replace all (big) stack allocations with an explicit stack structure that you manages on the heap. There'll be more code, but it won't be slower because all the extra code is stuff that happen automatically with the hw stack. (I.e. stuff the compiler normally take care of.) There is some more work if your interpreter also does deep recursion. It involves making one big function of those that do the recursion and manage the "calls" yourself with an array and a switch statement. Again, not particularly hard, but it could take some time to implement. Helge Hafting ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 13:32 ` Helge Hafting @ 2004-04-06 17:44 ` Sergiy Lozovsky 2004-04-07 1:02 ` Horst von Brand 2004-04-06 18:33 ` Jamie Lokier 1 sibling, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 17:44 UTC (permalink / raw) To: Helge Hafting; +Cc: linux-kernel If stack will shrink - i'll come up with something. Rearchitecture of LISP interpreter - is too much work. (and I'm lazy - I prefer computer to do a work, not me :-) I checked what is going on with the stack - it is used to pass parameters, some functions have one or two local variables (4 bytes each) and that's it. I like to develop tools and general solutions :-) To solve the stack problem in a way which will not cause big changes in any existing code - I can make stack virtualization. API can be different, but idea is the same. Task has some memory allocated by malloc (vstack) which is used for saving data from real stack. One of the APIs - scall function: scall(pointer_to_vstack, number_of_arguments, pointer_to_function_to_call, arg1, arg2,...) scall checks if real stack is full enough - it stores it's content in the vstack and moves %esp to the bottom of the real stack. When user function returns - information from vstack moves to the real one (one movl instruction at Intel x86). In case of LISP there is only one place where it will be enough to use scall - eval function. In other subsystems - it can be needed to call in a few places. But in such way a new 4K stack could be used without serious rewriting of existing code. vstack can grow dynamically if needed (within defined limit). Serge. --- Helge Hafting <helgehaf@aitel.hist.no> wrote: > On Mon, Apr 05, 2004 at 10:05:37AM -0700, Sergiy > Lozovsky wrote: > > > Consider rewriting your function to use > allocated > > > memory instead of stack, this isn't all that > hard. > > > > I put LISP interpreter inside the Kernel - > > http://vxe.quercitron.com > > > > It works, but it use a lot of stack memory. It's > > impossible to rewrite it easily, though I'll > > investigate why exactly it uses so much of stack > > memory (though it's nature of LISP). There are no > > serious kernel memory allocation (as of my > interpreter > > code review, only function calls; recursions in > LISP > > application itself are eliminated for sure), but > I'll > > trace stack usage more thouroughly. > > > Consider this. We're currently experimenting with a > transition from 8k to 4k stacks on x86, and that is > considered a very good thing. Allocating a single- > page stack is easy, two (contigous) pages might > fail. > > So a bigger kernel stack is out. > > As for rewriting code so it doesn't use stack - it > _is_ easy, but it might be a lot of _work_. > > The simple approach is to replace all (big) stack > allocations with an explicit stack structure that > you manages > on the heap. There'll be more code, but it won't be > slower > because all the extra code is stuff that happen > automatically > with the hw stack. (I.e. stuff the compiler normally > take > care of.) > > There is some more work if your interpreter also > does deep recursion. > It involves making one big function of those that do > the recursion > and manage the "calls" yourself with an array and a > switch statement. > Again, not particularly hard, but it could take some > time to implement. > > Helge Hafting __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 17:44 ` Sergiy Lozovsky @ 2004-04-07 1:02 ` Horst von Brand 2004-04-07 1:34 ` Sergiy Lozovsky 2004-04-07 2:30 ` viro 0 siblings, 2 replies; 84+ messages in thread From: Horst von Brand @ 2004-04-07 1:02 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > If stack will shrink - i'll come up with something. Good luck! When it is done shrinking, there won't be much (if any) left for you to play with. > Rearchitecture of LISP interpreter - is too much work. Implement a kernel-side LISP interpreter isn't... > (and I'm lazy - I prefer computer to do a work, not me > :-) Nodz. But even better is _not_ doing it at all ;-) > I checked what is going on with the stack - it is used > to pass parameters, some functions have one or two > local variables (4 bytes each) and that's it. Why do you think it has been 2 pages (8KiB) for as long as I remember (essentially forever in Linux), and it has taken a _lot_ of work to shrink it to 4KiB (- size of *current)? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 1:02 ` Horst von Brand @ 2004-04-07 1:34 ` Sergiy Lozovsky 2004-04-07 8:57 ` David Weinehall 2004-04-07 2:30 ` viro 1 sibling, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-07 1:34 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > Why do you think it has been 2 pages (8KiB) for as > long as I remember > (essentially forever in Linux), and it has taken a > _lot_ of work to shrink > it to 4KiB (- size of *current)? I described the possible solution (virtual stack) which can easily take care of this problem for some subsystems, or am I wrong. If code doesn't allocate big buffers in stack my solution can make conversion of existing code possible without _lot_ of work. (I'm lazy - remember :-) What do you think about my solution? Despite some additional overhead, but I don't think that it is significant. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 1:34 ` Sergiy Lozovsky @ 2004-04-07 8:57 ` David Weinehall 2004-04-07 13:38 ` Chris Friesen 2004-04-07 17:16 ` Sergiy Lozovsky 0 siblings, 2 replies; 84+ messages in thread From: David Weinehall @ 2004-04-07 8:57 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Horst von Brand, Linux Kernel Mailing List On Tue, Apr 06, 2004 at 06:34:50PM -0700, Sergiy Lozovsky wrote: > > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > > > Why do you think it has been 2 pages (8KiB) for as > > long as I remember > > (essentially forever in Linux), and it has taken a > > _lot_ of work to shrink > > it to 4KiB (- size of *current)? > > I described the possible solution (virtual stack) > which can easily take care of this problem for some > subsystems, or am I wrong. If code doesn't allocate > big buffers in stack my solution can make conversion > of existing code possible without _lot_ of work. (I'm > lazy - remember :-) You know, to me the combination of lazy programmer rhymes poorly with well-written code and security audits. > What do you think about my solution? Despite some > additional overhead, but I don't think that it is > significant. Personally, I think this proposal would be worthy for the patch-of-the-month award. Regards: David Weinehall -- /) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 8:57 ` David Weinehall @ 2004-04-07 13:38 ` Chris Friesen 2004-04-07 17:12 ` Sergiy Lozovsky 2004-04-07 17:16 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Chris Friesen @ 2004-04-07 13:38 UTC (permalink / raw) To: David Weinehall Cc: Sergiy Lozovsky, Horst von Brand, Linux Kernel Mailing List David Weinehall wrote: > Personally, I think this proposal would be worthy for the > patch-of-the-month award. I dunno...the proposal to rewrite the kernel and libc in assembly is pretty high up there.... Chris ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 13:38 ` Chris Friesen @ 2004-04-07 17:12 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-07 17:12 UTC (permalink / raw) To: Chris Friesen, David Weinehall Cc: Sergiy Lozovsky, Horst von Brand, Linux Kernel Mailing List --- Chris Friesen <cfriesen@nortelnetworks.com> wrote: > David Weinehall wrote: > > > Personally, I think this proposal would be worthy > for the > > patch-of-the-month award. > > I dunno...the proposal to rewrite the kernel and > libc in assembly is > pretty high up there.... My proposal gives ability to avoid rewriting of code and saves time. If there is a time to rewrite code - it can be rewritten. For parts we don't have time to rewrite - virtual stack can be used without serious code modifications. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 8:57 ` David Weinehall 2004-04-07 13:38 ` Chris Friesen @ 2004-04-07 17:16 ` Sergiy Lozovsky 1 sibling, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-07 17:16 UTC (permalink / raw) To: David Weinehall; +Cc: Horst von Brand, Linux Kernel Mailing List --- David Weinehall <tao@acc.umu.se> wrote: > On Tue, Apr 06, 2004 at 06:34:50PM -0700, Sergiy > Lozovsky wrote: > > > > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > > > > > Why do you think it has been 2 pages (8KiB) for > as > > > long as I remember > > > (essentially forever in Linux), and it has taken > a > > > _lot_ of work to shrink > > > it to 4KiB (- size of *current)? > > > > I described the possible solution (virtual stack) > > which can easily take care of this problem for > some > > subsystems, or am I wrong. If code doesn't > allocate > > big buffers in stack my solution can make > conversion > > of existing code possible without _lot_ of work. > (I'm > > lazy - remember :-) > > You know, to me the combination of lazy programmer > rhymes poorly with > well-written code and security audits. Don't take my non technical comments too seriously. Life is too short to be serious all the time. If I was not successful in making a joke - sorry. (there was an old joke that programmers are very lazy people - they don't like to work, so they write programs and computers work for them; I just quoted this joke). Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-07 1:02 ` Horst von Brand 2004-04-07 1:34 ` Sergiy Lozovsky @ 2004-04-07 2:30 ` viro 1 sibling, 0 replies; 84+ messages in thread From: viro @ 2004-04-07 2:30 UTC (permalink / raw) To: Horst von Brand; +Cc: Sergiy Lozovsky, Linux Kernel Mailing List On Tue, Apr 06, 2004 at 09:02:49PM -0400, Horst von Brand wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > If stack will shrink - i'll come up with something. > > Good luck! When it is done shrinking, there won't be much (if any) left for > you to play with. > > > Rearchitecture of LISP interpreter - is too much work. > > Implement a kernel-side LISP interpreter isn't... It's a userland (and leaky, at that) LISP interpreter plus some glue and duct tape to make it kinda-sorta work in kernel mode - enough for a demo, in any case. BTW, the LISP dialect implemented by that interpreter is unimpressive, to put it mildly. Even aside of atrocious "GC" and lexer (BTW, have the author of RefLISP ever heard of arcane technics known as "checking the return value of malloc"?), semantics of his EVAL would be a shame even in 70s (at any point after Landin's papers, actually). Sigh... ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 13:32 ` Helge Hafting 2004-04-06 17:44 ` Sergiy Lozovsky @ 2004-04-06 18:33 ` Jamie Lokier 2004-04-06 18:51 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Jamie Lokier @ 2004-04-06 18:33 UTC (permalink / raw) To: Helge Hafting; +Cc: Sergiy Lozovsky, linux-kernel Helge Hafting wrote: > The simple approach is to replace all (big) stack > allocations with an explicit stack structure that you manages > on the heap. Maybe Stackless Python is a better fit for this kernel project? :) [1/2 serious] -- Jamie ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 18:33 ` Jamie Lokier @ 2004-04-06 18:51 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 18:51 UTC (permalink / raw) To: Jamie Lokier, Helge Hafting; +Cc: Sergiy Lozovsky, linux-kernel You want these guys to fry me? :-) Do you like it well done? :-) Serge. --- Jamie Lokier <jamie@shareable.org> wrote: > Helge Hafting wrote: > > The simple approach is to replace all (big) stack > > allocations with an explicit stack structure that > you manages > > on the heap. > > Maybe Stackless Python is a better fit for this > kernel project? > > :) [1/2 serious] > > -- Jamie __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <1H9LV-5Jb-1@gated-at.bofh.it>]
* Re: kernel stack challenge [not found] <1H9LV-5Jb-1@gated-at.bofh.it> @ 2004-04-04 11:27 ` Andi Kleen 2004-04-04 18:24 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: Andi Kleen @ 2004-04-04 11:27 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: linux-kernel Sergiy Lozovsky <serge_lozovsky@yahoo.com> writes: > This function doesn't work in the kernel (system hungs > instantly when my function is called). Does antbody > have any idea what the reason can be? Some special > alignment? Special memory segment? In what direction > should I look? The kernel puts some data about the current task at the bottom of the stack and accesses that by referencing the stack pointer in "current". This is even used by interrupts. -Andi ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-04 11:27 ` Andi Kleen @ 2004-04-04 18:24 ` Sergiy Lozovsky 2004-04-04 18:38 ` Muli Ben-Yehuda 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-04 18:24 UTC (permalink / raw) To: Andi Kleen; +Cc: linux-kernel Thanks, Andi. That can be the case. Bad thing is that stack size is hardcoded all over the kernel. I wonder how it is possible to access task struct having current stack pointer. %esp points at the middle of the stack (when we are in the kernel) when interrupt occures. Serge. --- Andi Kleen <ak@muc.de> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> writes: > > > This function doesn't work in the kernel (system > hungs > > instantly when my function is called). Does > antbody > > have any idea what the reason can be? Some special > > alignment? Special memory segment? In what > direction > > should I look? > > The kernel puts some data about the current task at > the bottom > of the stack and accesses that by referencing the > stack pointer > in "current". This is even used by interrupts. > > -Andi > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-04 18:24 ` Sergiy Lozovsky @ 2004-04-04 18:38 ` Muli Ben-Yehuda 0 siblings, 0 replies; 84+ messages in thread From: Muli Ben-Yehuda @ 2004-04-04 18:38 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Andi Kleen, linux-kernel [-- Attachment #1: Type: text/plain, Size: 588 bytes --] On Sun, Apr 04, 2004 at 11:24:38AM -0700, Sergiy Lozovsky wrote: > I wonder how it is possible to access task struct > having current stack pointer. %esp points at the > middle of the stack (when we are in the kernel) when > interrupt occures. Look at the curren()t and get_current() macros. Basically, the stack is page aligned, so with the proper masking of %esp you can get to the bottom of the stack. See http://www.kernelnewbies.org/faq/, "how does get_current work?". Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <200404052043.i35KhDvS020176@turing-police.cc.vt.edu>]
* Re: kernel stack challenge [not found] <200404052043.i35KhDvS020176@turing-police.cc.vt.edu> @ 2004-04-05 21:06 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 21:06 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: linux-kernel --- Valdis.Kletnieks@vt.edu wrote: > On Mon, 05 Apr 2004 13:33:10 PDT, you said: > > > I don't know how it is possible (if it is - it's > easy > > to fix). All LISP print functions print > information > > into the buffer of limited size. (LISP program has > no > > access to the format or buffer length arguments of > > snprintf). When buffer is full or string has an \n > at > > the end - VM calls printk. > > That's how it's *supposed* to work when everything > is working *correctly*. > > Now re-do your example, and assume there's a *BUG* > in the VM. For instance, Here is a main idea. I can put a lot of effort to debug VM once. I (and others) are not destined to do such kind of debugging (with C inside the kernel) after that. It's like with JAVA VM - it's hard to debug VM, but it should be done once - after that JAVA program can't use a pointer to a nonallocated memory. Those who continue to use C - should be careful with pointersin each program. > what happens if there's a fencepost error on "buffer > is full"? All that takes > is one line that says 'if (ptr > bufsize)' rather > than 'if (ptr >= bufsize)'. > > Yes, proper encapsulation *helps*. But it's Exactly. :-) i'm not claiming that I solve all problems. But this technology helps to make development of some kernel parts easier. Encapsulation helps and you can easily debug LISP program in the userspace before loading it into the kernel. No matter what particular LISP program does - it can't crash the kernel - C code can do that easily. Serge. > certainly *NOT* any sort of > guarantee that *all* bugs will be stopped. For > comparison, read up on the Java > VM - although it does a very good job of sandboxing > a Java program, there > *have* been bugs and exploits found over the > years.... > > > ATTACHMENT part 2 application/pgp-signature __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <200404052026.i35KQh5g004342@eeyore.valparaiso.cl>]
* Re: kernel stack challenge [not found] <200404052026.i35KQh5g004342@eeyore.valparaiso.cl> @ 2004-04-05 21:21 ` Sergiy Lozovsky 2004-04-06 20:01 ` Horst von Brand 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-05 21:21 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > [LISP inside the kernel?!] > > > Basically there are two reasons. > > > > 1. Give system administrator possibility to change > > security policy easy enough > > SELinux To create a new 'security model' one should write a C program within Selinux user space security server. People like to use higher level languages. > > without C programminig > > inside the kernel (we should not expect system > > administartor to be a kernel guru). > > As 97.572% of the job has to be done in userland > anyway, place your > checks/high-level language/GUI frobnitzer in there > at will. Compile to a > compact, easy-to-handle, digitally signed, binary > blob and stuff _that_ > into the kernel as needed. I'm not ready to put a binary compiled with Common Lisp or PERL (if it exists) compilers into the kernel. At the same time I want people to benefit from using high level langages (even kernel gurus don't use Assembler all the time, higher level languages is easier to use and less lines of code to write). ..... > > 2. Protect system from bugs in security policy > created > > by system administrator (user). > > Sounds like you are demanding a solution to Turing's > test here... and also > to the halting problem. I didn't claim that I solve all problems on earth :-) What I can claim: 1. Some kernel parts can be developed with language of higher level than C. 2. Problems with such parts can be to some extent be encapsulated within VM (no, it's not 100% fool prof for sure), but it helps. 3. Code can be easily debugged in the user space (running with user space VM) and used in the kernel after that. > > LISP interpreter > is a > > LISP Virtual Machine (as Java VM). > > So what? If the policy just leaves out everybody, or > lets anybody fool > around with the hardware, you are royally screwed in > any case. I didn't get the question. > > So all bugs are > > incapsulated and don't affect kernel. Even severe > bugs > > in this LISP kernel module can cause termination > of > > user space application only (except of stack > overflow > > - which I can address). LISP error message will be > > printed in the kernel log. > > If it is running in userspace, why do you place the > interpreter in the kernel? LISP code is located in the kernel. Application issues a system call LISP program checks arguments of this call. If LISP program fails (crashes) - VM will return default value which is EACCESS, so application will get 'access denied'. (and will fail, probably). Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-05 21:21 ` Sergiy Lozovsky @ 2004-04-06 20:01 ` Horst von Brand 0 siblings, 0 replies; 84+ messages in thread From: Horst von Brand @ 2004-04-06 20:01 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > > > [LISP inside the kernel?!] > > > > > Basically there are two reasons. > > > > > > 1. Give system administrator possibility to change > > > security policy easy enough > > > > SELinux > > To create a new 'security model' one should write a C > program within Selinux user space security server. > People like to use higher level languages. C is a high level language. If you don't like it, use C++, Perl, Ruby, TCL, Guile, Common LISP, PostScript, ... It's userspace, program in whatever you like most. > > > without C programminig > > > inside the kernel (we should not expect system > > > administartor to be a kernel guru). > > As 97.572% of the job has to be done in userland anyway, place your > > checks/high-level language/GUI frobnitzer in there at will. Compile to a > > compact, easy-to-handle, digitally signed, binary blob and stuff _that_ > > into the kernel as needed. > I'm not ready to put a binary compiled with Common > Lisp or PERL (if it exists) Yep. > compilers into the kernel. Again.... use something written in C, Perl, Common LISP, even COBOL to parse the description and generate a binary blob from it that you then stuff into the kernel. No in-kernel runtime for high-level general purpose languages needed at all. > At the same time I want people to benefit from using > high level langages (even kernel gurus don't use > Assembler all the time, higher level languages is > easier to use and less lines of code to write). Kernel gurus write C and think assembler. Wrong crowd selected ;-) > ..... > > > > 2. Protect system from bugs in security policy > > > created by system administrator (user). > > Sounds like you are demanding a solution to Turing's test here... and > > also to the halting problem. > I didn't claim that I solve all problems on earth :-) You certainly do. How do you protect the system from a mistaken policy that takes away all rights from the user supposed to manage it, and gives them to the local script kiddie instead? > What I can claim: > 1. Some kernel parts can be developed with language of > higher level than C. It efficiency doesn't matter, do it in userland. If efficiency matters, do it in hand-tuned C + assembly, inside the kernel only if there is no other way. > 2. Problems with such parts can be to some extent be > encapsulated within VM (no, it's not 100% fool prof > for sure), but it helps. Doing it in userland helps even more. > 3. Code can be easily debugged in the user space > (running with user space VM) and used in the kernel > after that. The environment isn't the same, so this doesn't help that much. Besides, if the job _can_ be done in userland, it has no business being done in the kernel. Stuff is being moved _out_ of the kernel (for example, finding partitions and filesystems) as we speak... [...] > LISP code is located in the kernel. Application issues a system call LISP > program checks arguments of this call. If LISP program fails (crashes) - > VM will return default value which is EACCESS, so application will get > 'access denied'. (and will fail, probably). So the idea is _userland_ code stuffed into the _kernel_ to be checked and executed there? And if it is broken, and denies all access, it is a nice DoS. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <200404061606.i36G6YLE003375@eeyore.valparaiso.cl>]
* Re: kernel stack challenge [not found] <200404061606.i36G6YLE003375@eeyore.valparaiso.cl> @ 2004-04-06 18:04 ` Sergiy Lozovsky 2004-04-06 18:28 ` John Stoffel 2004-04-06 18:57 ` Richard B. Johnson 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 18:04 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > --- John Stoffel <stoffel@lucent.com> wrote: > > > >>>>> "Sergiy" == Sergiy Lozovsky > > > <serge_lozovsky@yahoo.com> writes: > > [...] > > > UNIX security policy is already implemented in the > > Kernel, > > Basic mechanism, not policy. In case of VXE even mechanism is not stored inside the kernel! This was the main goal - not to store(encode) security model (mechanism) in the kernel. In VXE it is loadable as well as particular security policy. It loads on demand (during the start of subsystem) and unloads when subsystem ends it work. When susbsytem doesn't run - model and policy are stored as a file. VXE allow to preload model and policy if that is desired, but it's just one of the options. > > Policy has no place inside the kernel. Root privileges (ability to send a signal to any process, access any file and so on) are encoded in the kernel. > [...] > > > > Then *WHY* does the LISP interpreter need to be > in > > > the kernel in the > > > first place? Hint, you just said you wanted to > > > protect the kernel... > > > > All LISP errors are incapsulated within LISP VM. > > They aren't. A bad kprintf(), or a call to the wrong > function inside the > kernel, or fiddling with the wrong data structure, > and you are toast. No. LISP program can't call kprintf. Only VM can. LISP program prints information into string buffer of limited size and VM uses snprintf for that. When buffer is full or there is \n - VM calls kprintf. So all interaction with the kernel goes via VM. Investing some time into carefull parameter check in VM allows to avoid the same work for each new application. VM is not 100% foolproof - I don't claim that, but it reduces problems which a new application (within the kernel) can cause. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 18:04 ` Sergiy Lozovsky @ 2004-04-06 18:28 ` John Stoffel 2004-04-06 18:48 ` Sergiy Lozovsky 2004-04-06 18:57 ` Richard B. Johnson 1 sibling, 1 reply; 84+ messages in thread From: John Stoffel @ 2004-04-06 18:28 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Horst von Brand, Linux Kernel Mailing List >>>>> "Sergiy" == Sergiy Lozovsky <serge_lozovsky@yahoo.com> writes: >> Policy has no place inside the kernel. Sergiy> Root privileges (ability to send a signal to any process, Sergiy> access any file and so on) are encoded in the kernel. But that does not require a LISP interpreter in the kernel either. And you are also mistaking policy with a capability. Who has root is a policy, what root can do is a capability. They are seperate issues. Sergiy> So all interaction with the kernel goes via VM. Investing Sergiy> some time into carefull parameter check in VM allows to avoid Sergiy> the same work for each new application. You have not given us a simple example of how this VM would be used in the kernel and what it provides. I think that would help people understand why you think this is so needed. So just start with a process, explain how it wants to do some restricted action, and how your VM would be required to mediate that access. Some simple flow charting and explaining of what steps would happen and why would be a big help. Personally, I think you're completely confusing policy with capabilities. Since the setting of policy is completely a user-space issue, while the checking of capabilities is handled in the kernel. And if the capability check requires a VM to do some mediation, that capability check gets pushed out to userspace, instead of kept in the VM in the kernel like you seem to want. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 18:28 ` John Stoffel @ 2004-04-06 18:48 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 18:48 UTC (permalink / raw) To: John Stoffel; +Cc: Horst von Brand, Linux Kernel Mailing List --- John Stoffel <stoffel@lucent.com> wrote: > >>>>> "Sergiy" == Sergiy Lozovsky > <serge_lozovsky@yahoo.com> writes: > > >> Policy has no place inside the kernel. > > Sergiy> Root privileges (ability to send a signal to > any process, > Sergiy> access any file and so on) are encoded in > the kernel. > > But that does not require a LISP interpreter in the > kernel either. > And you are also mistaking policy with a capability. > Who has root is > a policy, what root can do is a capability. They > are seperate issues. UID is stored in a task structure in the kernel as well as what to do with it. With VXE both policy and capability are in a file (out of the kernel), though there is an option to preload it into the kernel before execution of particular system starts. > Sergiy> So all interaction with the kernel goes via > VM. Investing > Sergiy> some time into carefull parameter check in > VM allows to avoid > Sergiy> the same work for each new application. > > You have not given us a simple example of how this > VM would be used in > the kernel and what it provides. I think that would > help people > understand why you think this is so needed. I though I did. Here is a link to the site with detailed description of the system. It works since 1999. - http://vxe.quercitron.com It's not an example - it's working system. There was an article in LinuxFocus - it's less technical and more compact - http://jamesthornton.com/linux/LinuxFocus/English/January2000/article133.shtml Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 18:04 ` Sergiy Lozovsky 2004-04-06 18:28 ` John Stoffel @ 2004-04-06 18:57 ` Richard B. Johnson 2004-04-06 21:15 ` Sergiy Lozovsky 1 sibling, 1 reply; 84+ messages in thread From: Richard B. Johnson @ 2004-04-06 18:57 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Horst von Brand, Linux Kernel Mailing List On Tue, 6 Apr 2004, Sergiy Lozovsky wrote: > > --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > > --- John Stoffel <stoffel@lucent.com> wrote: > > > > >>>>> "Sergiy" == Sergiy Lozovsky > > > > <serge_lozovsky@yahoo.com> writes: > > > > [...] > > > > > UNIX security policy is already implemented in the > > > Kernel, > > > > Basic mechanism, not policy. > > In case of VXE even mechanism is not stored inside the > kernel! This was the main goal - not to store(encode) > security model (mechanism) in the kernel. In VXE it is > loadable as well as particular security policy. It > loads on demand (during the start of subsystem) and > unloads when subsystem ends it work. > > When susbsytem doesn't run - model and policy are > stored as a file. > > VXE allow to preload model and policy if that is > desired, but it's just one of the options. > > > > > Policy has no place inside the kernel. > > Root privileges (ability to send a signal to any > process, access any file and so on) are encoded in the > kernel. > That's not policy. That's mechanism (one of many). > > > > Then *WHY* does the LISP interpreter need to be > > in > > > > the kernel in the > > > > first place? Hint, you just said you wanted to > > > > protect the kernel... > > > > > > All LISP errors are incapsulated within LISP VM. > > > > They aren't. A bad kprintf(), or a call to the wrong > > function inside the > > kernel, or fiddling with the wrong data structure, > > and you are toast. > Let me get this right. You learned LISP right? Now you think it's the only way to go. There is a name for this, where one starts to identify with his captors... It's called the Stockholm Syndrome, named after four Swedes bound in bank- vault for six days became attached to their captors. LISP is just a TOOL and a poor one, at that. There are many tools available under Unix/Linux and, if you don't like what's available, you can readily make your own. Once you learn new tools, the Stockholm Syndrome will go away although you'll probably always like the first tool you learned to use. I like DDT, myself. Nobody who has a clue would suggest LISP inside a kernel. When I first read this, I was sure it was an April-fool joke, although somewhat cruel, kinda like; "what to do with a dead cat..." Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 18:57 ` Richard B. Johnson @ 2004-04-06 21:15 ` Sergiy Lozovsky 2004-04-06 22:44 ` Timothy Miller 2004-04-07 2:25 ` Horst von Brand 0 siblings, 2 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 21:15 UTC (permalink / raw) To: root; +Cc: Horst von Brand, Linux Kernel Mailing List --- "Richard B. Johnson" <root@chaos.analogic.com> wrote: > On Tue, 6 Apr 2004, Sergiy Lozovsky wrote: > > Let me get this right. You learned LISP right? 25 years ago. > Now you think it's the only way to go. There is > a name for this, where one starts to identify > with his captors... It's called the Stockholm > Syndrome, named after four Swedes bound in bank- > vault for six days became attached to their captors. Last time I used LISP (except of the project we discuss) was 18 years ago (on IBM mainframes). So your conclusion doesn't sound right :-) I never used any LISP on PC prior to VXE project. > LISP is just a TOOL and a poor one, at that. There > are many tools available under Unix/Linux and, if > you don't like what's available, you can readily > make your own. Once you learn new tools, the > Stockholm > Syndrome will go away although you'll probably > always > like the first tool you learned to use. I like DDT, > myself. > > Nobody who has a clue would suggest LISP inside a > kernel. > When I first read this, I was sure it was an > April-fool > joke, although somewhat cruel, kinda like; "what to > do > with a dead cat..." So, you still didn't say a word why it was a bad choice. Can you share your thought on that? I didn't just pick up LISP - I EXPLAINED my reasons. if you missed my explanation here is a short summary. 1. I needed solution to implement some procedural functionality within the kernel. This functionality should be expressed with some high level language (shorter development time and more compact source code). This functionality should be loadable/unloadable to the kernel. 2. Size of the interpreter should be minimal. 3. Kind of real time - no ordinary garbage collector. And automatic memory management at the same time. 4. Easiest syntax possible - so interpreter would be compact. Simpler - the better :-) I don't like complicated things :-) 5. Well known. So there would be people around who already know this language and expectations are clear. And there are books around about this language. 6. Ability to handle/represent complex data structures. 7. Errors/bugs in loadable functions should not cause trouble for other tasks and kernel itself. (To the extent possible for sure). 8. It should be universal (general purpose) language which gives ability to make any manipulations with numbers, strings, bits and data structures. So I would be sure that functionality I want to express is not limited by the language. That's why particular LISP interpreter was chosen. It's wrong to say that just language was chosen. I would never start work of fitting Common Lisp into the kernel. Particular general purpose language interpreter was chosen. Serge. > Cheers, > Dick Johnson > Penguin : Linux version 2.4.24 on an i686 machine > (797.90 BogoMips). > Note 96.31% of all statistics are > fiction. > > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 21:15 ` Sergiy Lozovsky @ 2004-04-06 22:44 ` Timothy Miller 2004-04-06 22:57 ` viro 2004-04-07 2:25 ` Horst von Brand 1 sibling, 1 reply; 84+ messages in thread From: Timothy Miller @ 2004-04-06 22:44 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: root, Horst von Brand, Linux Kernel Mailing List Sergiy Lozovsky wrote: > > So, you still didn't say a word why it was a bad > choice. Can you share your thought on that? I've seen (and produced) lots of words to that effect. > > I didn't just pick up LISP - I EXPLAINED my reasons. > if you missed my explanation here is a short summary. > > 1. I needed solution to implement some procedural > functionality within the kernel. This functionality > should be expressed with some high level language > (shorter development time and more compact source > code). This functionality should be > loadable/unloadable to the kernel. This isn't a problem. > > 2. Size of the interpreter should be minimal. You say your LISP interpreter is about 100K. This is hardly minimal. There are things which are much smaller which will do the job AND won't have the stack-exploding side-effects. > > 3. Kind of real time - no ordinary garbage collector. > And automatic memory management at the same time. How about one which doesn't NEED garbage collection? For instance, if you were to make it object-based, rather than object-oriented, then you'd pre-allocate all structures at compile time. Ada is(was?) like this. > > 4. Easiest syntax possible - so interpreter would be > compact. Simpler - the better :-) I don't like > complicated things :-) LISP completely violates this requirement. There are languages which have MUCH simpler syntax than LISP. And I'm talking simpler for the PROGRAMMER. It can be as complex as you like for the compiler, because THE COMPILER WOULD BE IN USERSPACE. > > 5. Well known. So there would be people around who > already know this language and expectations are clear. > And there are books around about this language. LISP completely violates this requirement. While I appreciate the power of LISP for abstraction, list processing, and how it lends itself towards many AI-related tasks, it's not a commonly-used language. Besides, you have already invalidated this point by stating that the people actually USING this policy engine would never look at the code, because they would select amongst a set of canned policies using a web browser. In this case, the form of the policy code is completely irrelevant. > 6. Ability to handle/represent complex data > structures. LISP is not superior to other languages in this regard. I handle/represent complex data structures in C, C++, Java, Javascript, PHP, SQL, BASIC, Pascal, Tcl... I guess FORTRAN is the only one I don't do complex structures in. > 7. Errors/bugs in loadable functions should not cause > trouble for other tasks and kernel itself. (To the > extent possible for sure). The only way to be sure of this is to do the processing in userspace. Putting that aside, any carefully-written interpreter would be able to provide this security. Furthermore, something simpler than a LISP interpreter would be easier to VERIFY that it was secure. > > 8. It should be universal (general purpose) language > which gives ability to make any manipulations with > numbers, strings, bits and data structures. So I would > be sure that functionality I want to express is not > limited by the language. Again, LISP is not superior to other languages in this regard. > That's why particular LISP interpreter was chosen. > It's wrong to say that just language was chosen. I > would never start work of fitting Common Lisp into the > kernel. Particular general purpose language > interpreter was chosen. You have to understand that you're speaking to a list full of zealots that understand zealotry VERY WELL. Even Linux scratches his head (or so I assume) every time some Linux zealot comes along wanting to run Linux on some two-bit (pun intended) processor that was never designed to run an OS. Thus, when someone comes along suggesting that they put a beast like a LISP interpreter into the Kernel, something that violates Linux philosophy on SOOO many levels, the "he must be a LISP zealot" red lights start flashing, because only a LISP/whatever zealot would choose to do something so ostensibly impractical. That is to say, someone who was NOT a LISP/whatever zealot would have chosen something more appropriate, while we have observed so many times Linux/LISP/MacOS/BeOS/Perl/Ruby/Python/whatever zealots who want to push their square peg into every round hole they can find. (so to speak) I personally like to write Nuclear Bomb simulators in BASH to run on 5mhz processors with 1K of RAM. *snort* ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 22:44 ` Timothy Miller @ 2004-04-06 22:57 ` viro 2004-04-06 23:32 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: viro @ 2004-04-06 22:57 UTC (permalink / raw) To: Timothy Miller Cc: Sergiy Lozovsky, root, Horst von Brand, Linux Kernel Mailing List On Tue, Apr 06, 2004 at 06:44:48PM -0400, Timothy Miller wrote: > >5. Well known. So there would be people around who > >already know this language and expectations are clear. > >And there are books around about this language. > > LISP completely violates this requirement. While I appreciate the power > of LISP for abstraction, list processing, and how it lends itself > towards many AI-related tasks, it's not a commonly-used language. Whether it's commonly-used or not, there's another killer problem with LISP - it's fragmented worse than even Pascal. And "which subset and extensions do we have in $IMPLEMENTATION" is worth "which language are we dealing with". Worse, actually. If you want a functional language - at least pick a well-defined one. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 22:57 ` viro @ 2004-04-06 23:32 ` Sergiy Lozovsky 2004-04-06 23:45 ` Robin Rosenberg 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 23:32 UTC (permalink / raw) To: viro, Timothy Miller Cc: Sergiy Lozovsky, root, Horst von Brand, Linux Kernel Mailing List --- viro@parcelfarce.linux.theplanet.co.uk wrote: > On Tue, Apr 06, 2004 at 06:44:48PM -0400, Timothy > Miller wrote: > > >5. Well known. So there would be people around > who > > >already know this language and expectations are > clear. > > >And there are books around about this language. > > > > LISP completely violates this requirement. While > I appreciate the power > > of LISP for abstraction, list processing, and how > it lends itself > > towards many AI-related tasks, it's not a > commonly-used language. > > Whether it's commonly-used or not, there's another > killer problem with LISP - > it's fragmented worse than even Pascal. Can I have more details? All LISPs I know manage memory by themselves as well as the one I use. They allocate memory pool, create a list of free cells in it and that's it. What is the problem? Yes, cells in the free list are not contiguous, it's a list. > And "which > subset and extensions > do we have in $IMPLEMENTATION" is worth "which > language are we dealing with". > Worse, actually. If you want a functional language > - at least pick a > well-defined one. I use a subset of big lisps (Common Lisp should I say?). All function are described in manual which goes with my system. And I'm not going to run some previously created LISP programs. So exact compatibility is not an issue. At the same time if a person wants to understand what is CAR or CDR - there are different sources of information available except manual I provide (which is reference, not a LISP textbook). Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 23:32 ` Sergiy Lozovsky @ 2004-04-06 23:45 ` Robin Rosenberg 0 siblings, 0 replies; 84+ messages in thread From: Robin Rosenberg @ 2004-04-06 23:45 UTC (permalink / raw) To: Sergiy Lozovsky Cc: viro, Timothy Miller, root, Horst von Brand, Linux Kernel Mailing List On Wednesday 07 April 2004 01:32, Sergiy Lozovsky wrote: > --- viro@parcelfarce.linux.theplanet.co.uk wrote: > > Whether it's commonly-used or not, there's another > > killer problem with LISP - > > it's fragmented worse than even Pascal. > > Can I have more details? All LISPs I know manage > memory by themselves as well as the one I use. They > allocate memory pool, create a list of free cells in > it and that's it. What is the problem? Yes, cells in > the free list are not contiguous, it's a list. Not memory fragmentation, language definition fragmentation. There is no language called "LISP" (except the original). There are several dozen strains with slighly or very different syntax, scope rules and other variations. LISP1.5, MacLisp, Emacs Lisp, AutoLisp, Common Lisp, Scheme to mention a very few of the more known species, and most of these come in different dialects. -- robin ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 21:15 ` Sergiy Lozovsky 2004-04-06 22:44 ` Timothy Miller @ 2004-04-07 2:25 ` Horst von Brand 1 sibling, 0 replies; 84+ messages in thread From: Horst von Brand @ 2004-04-07 2:25 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: [...] > I didn't just pick up LISP - I EXPLAINED my reasons. > if you missed my explanation here is a short summary. > > 1. I needed solution to implement some procedural > functionality within the kernel. Fair enough, if really needed. > This functionality > should be expressed with some high level language > (shorter development time and more compact source > code). That it is _expressed_ in a sky-high-level-language has nothing at all to do with _implementing_ said language (fully?) inside the kernel. Heck, the kernel has no built-in C compiler + development environment + runtime either! > This functionality should be > loadable/unloadable to the kernel. A compact, easy to interpret blob pushed into the kernel, a module hooking into the "right places", ... > 2. Size of the interpreter should be minimal. Zero is just about right for me. > 3. Kind of real time - no ordinary garbage collector. > And automatic memory management at the same time. Oxymoron. > 4. Easiest syntax possible - so interpreter would be > compact. Simpler - the better :-) I don't like > complicated things :-) Why do you need the interpreter in kernel? If you do need it, why does it have to be a general-purpose language, and not an "interpreter" for a stylized data structure, carefully designed for the task? > 5. Well known. So there would be people around who > already know this language and expectations are clear. > And there are books around about this language. C is fine in that sense. Even much better than LISP. Specially among the sysadmin/kernel hacker/general Unix geek crowd... > 6. Ability to handle/represent complex data > structures. C qualifies. > 7. Errors/bugs in loadable functions should not cause > trouble for other tasks and kernel itself. (To the > extent possible for sure). Hard to do in any case. Just be careful... > 8. It should be universal (general purpose) language > which gives ability to make any manipulations with > numbers, strings, bits and data structures. So I would > be sure that functionality I want to express is not > limited by the language. But _why_? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <200404061618.i36GIHgW003419@eeyore.valparaiso.cl>]
* Re: kernel stack challenge [not found] <200404061618.i36GIHgW003419@eeyore.valparaiso.cl> @ 2004-04-06 18:16 ` Sergiy Lozovsky 2004-04-06 20:01 ` Valdis.Kletnieks 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 18:16 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List --- Horst von Brand <vonbrand@inf.utfsm.cl> wrote: > Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > > [...] > > [...] > > > No matter what particular LISP program does - it > can't > > crash the kernel - C code can do that easily. > > If the policy check goes into an infinite loop, the > kernel proper isn't > technically crashed, but useless anyway. And if you > can prove that can't > happen, you just solved the halting problem. > Congratulation! My code works during system calls (before the real one). Interrupts are enabled. If it enters the loop scheduler still can switch tasks (using timer for example). If it doesn't work in such way I can easily call schedule(); implicitly after some time limit will be reached - it's VM, so it's easy to do such things. So, it's my pleasure to accept your congratulations :-) Thanks. Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 18:16 ` Sergiy Lozovsky @ 2004-04-06 20:01 ` Valdis.Kletnieks 2004-04-06 21:38 ` Sergiy Lozovsky 0 siblings, 1 reply; 84+ messages in thread From: Valdis.Kletnieks @ 2004-04-06 20:01 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Horst von Brand, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 986 bytes --] On Tue, 06 Apr 2004 11:16:03 PDT, Sergiy Lozovsky said: > My code works during system calls (before the real > one). Interrupts are enabled. If it enters the loop > scheduler still can switch tasks (using timer for > example). If it doesn't work in such way I can easily > call schedule(); implicitly after some time limit will > be reached - it's VM, so it's easy to do such things. Yes, but your security manager is *still* in an infinite loop, and eventually you *will* come to a grinding halt, as each process gets queued up waiting for a decision from the security manager. As an aside, the original posting said it was a restricted subset of Lisp that didn't include recursion. Aside from the technical difficulties of detecting two or more routines that mutually recurse, it's unclear that Lisp without recursion is at all interesting or useful.... This is sounding more and more like the old adage: "When all you have is a hammer, everything starts looking like a thumb". [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 20:01 ` Valdis.Kletnieks @ 2004-04-06 21:38 ` Sergiy Lozovsky 2004-04-06 22:46 ` Timothy Miller 0 siblings, 1 reply; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-06 21:38 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Horst von Brand, Linux Kernel Mailing List --- Valdis.Kletnieks@vt.edu wrote: > On Tue, 06 Apr 2004 11:16:03 PDT, Sergiy Lozovsky > said: > > > My code works during system calls (before the real > > one). Interrupts are enabled. If it enters the > loop > > scheduler still can switch tasks (using timer for > > example). If it doesn't work in such way I can > easily > > call schedule(); implicitly after some time limit > will > > be reached - it's VM, so it's easy to do such > things. > > Yes, but your security manager is *still* in an > infinite loop, and eventually > you *will* come to a grinding halt, as each process > gets queued up waiting for > a decision from the security manager. No. VXE has completely different architecture. Separate logical copy of LISP program is for each subsystem we protect. (sure they share the same code of LISP interpreter). So, if there will be any problems - it's for particular subsystem only. Other subsystems (protected and not protected) will not be affected. It's like event driven model. There is no constantly running servers. > As an aside, the original posting said it was a > restricted subset of Lisp that > didn't include recursion. Aside from the technical > difficulties of detecting > two or more routines that mutually recurse, it's > unclear that Lisp without > recursion is at all interesting or useful.... It's misunderstanding. There are no any recursion restrictions. Author of particular security model (LISP program) should avoid recursions; it's not very hard actually. When we write program at language other than LISP - we rarely use recursion. Yes, it's against LISP style, but not a big problem. > This is sounding more and more like the old adage: > "When all you have > is a hammer, everything starts looking like a > thumb". I know the better one. "As all Real Programmers know, the only useful data structure is the Array. Strings, Lists, Structures, Sets-- these are all special cases of arrays and can be treated that way just as easily without messing up your programming language with all sorts of complications." http://www.pbm.com/~lindahl/real.programmers.html Serge :-) __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: kernel stack challenge 2004-04-06 21:38 ` Sergiy Lozovsky @ 2004-04-06 22:46 ` Timothy Miller 0 siblings, 0 replies; 84+ messages in thread From: Timothy Miller @ 2004-04-06 22:46 UTC (permalink / raw) To: Sergiy Lozovsky Cc: Valdis.Kletnieks, Horst von Brand, Linux Kernel Mailing List Sergiy Lozovsky wrote: > It's misunderstanding. There are no any recursion > restrictions. Author of particular security model > (LISP program) should avoid recursions; it's not very > hard actually. When we write program at language other > than LISP - we rarely use recursion. Yes, it's against > LISP style, but not a big problem. If you are going to throw away the most basic and fundamental feature of LISP for this..... why use LISP? ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <24DA9B48-8827-11D8-87A5-000A9585C204@able.es>]
* Re: kernel stack challenge [not found] <24DA9B48-8827-11D8-87A5-000A9585C204@able.es> @ 2004-04-07 0:27 ` Sergiy Lozovsky 0 siblings, 0 replies; 84+ messages in thread From: Sergiy Lozovsky @ 2004-04-07 0:27 UTC (permalink / raw) To: J.A. Magallon; +Cc: Linux-Kernel --- "J.A. Magallon" <jamagallon@able.es> wrote: > > On 7 abr 2004, at 01:17, Sergiy Lozovsky wrote: > > > > What? Give an example. I want something high > level, so > > Forth will not do. Sure, encapsulation is needed, > to > > protect kernel from pointer errors and so on. > > > > Ple What is this? I used PL/1 some time ago, is PLE - PL/1 Extended? Or Enlarged? (just kidding) If you will provide link to the source code with documentation - that would help. Google knows nothing about Ple. (just to check it out I tried to search for LISP - google knows it well :-). Serge. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <58907794@toto.iv>]
* Re: kernel stack challenge [not found] <58907794@toto.iv> @ 2004-04-07 4:29 ` Peter Chubb 0 siblings, 0 replies; 84+ messages in thread From: Peter Chubb @ 2004-04-07 4:29 UTC (permalink / raw) To: Horst von Brand; +Cc: Sergiy Lozovsky, Linux Kernel Mailing List >>>>> "Horst" == Horst von Brand <vonbrand@inf.utfsm.cl> writes: >> The only one is that performance would suffer because of use of >> higher level language than C or Assembler. Horst> Because the performance and size of kernel code is _critical_, Horst> maybe? Because much of the kernel code has been carefully Horst> tuned for maximum performance perhaps? >> There is a reason people use languages like PERL, Java and so on. Horst> And there are solid reasons for _not_ writing operating system Horst> kernels in them too... Hey, why not just port Xemacs to run on the bare metal. That way you get a lisp interpreter `for free'. :-) -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <20040409182517.330.qmail@web40508.mail.yahoo.com>]
* Re: kernel stack challenge [not found] <20040409182517.330.qmail@web40508.mail.yahoo.com> @ 2004-04-10 4:17 ` Horst von Brand 0 siblings, 0 replies; 84+ messages in thread From: Horst von Brand @ 2004-04-10 4:17 UTC (permalink / raw) To: Sergiy Lozovsky; +Cc: Linux Kernel Mailing List [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 7851 bytes --] Sergiy Lozovsky <serge_lozovsky@yahoo.com> said: > Horst von Brand said: [...] > Working version of VXE was developed before SELinux. Before Flux (the experimental OS that was used to demonstrate the ideas)? Before the development of the architecture? SELinux is quite old, and the ideas behind it even more... In any case, who was first has very little to say about which one is better. > So you suggest using competing products, which were > developed later :-) Are they better and easier to use? > I'm not sure. Doesn't matter if the product is completely off-track. I'd take anything that was developed by some of the top people in the security area over something by an amateur each day. Unless there is _solid_ evidence for the amateurs, that is... and if they do completely nonsensical things like LISP in kernel, that is in my view evidence that they don't even know what a clue is. [...] > VXE is more granular and convenient tool, than chroot > jail. Here is why: > > 1. It can be a complicated task, to move all needed > file for chroot. So? > If it is a big system, like Oracle - > it can be hard (it's possible, but too complicated). In that case you can afford to set up a machine (or complete environment) just for Oracle. > VXE can protect working subsystems without making any > changes in their location, nor configuration. How? It requires _intimate_ knowledge of what the application needs, that is very much unlikely to be in the hands of the hapless sysadmin in charge. Who built the package in the first place is in a better position, and for them it is easier to give directions on setting up a chroot jail (available with any Unix!) than to fool around with a thinly-used, experimental "security package" for an operating system that is on itself (as yet) little used in hardened application needs. > 2. Many systems have shared information. If we place > subsystems in different chroot jails - who will > synchronize this information? Example - sendmail and > POPD - sendmail places mail into POPDs mailboxes. If > they are in different chroot jails it is impossible. No... they can comunicate over the network. Or share files by mounting an area twice. By shared memory. By other shared resources inherited from a common ancestor. Besides, writing secured mail systems _has_ been done. Several times. > Another example - many subsystems share /etc/passwd > /etc/shadow information, if they are in different > chroot jails - who will do synchronisation/data > exchange between them? NIS, NIS+, LDAP ring a bell? > 3. If some file in chroot is read only - in case if > hacker will get root - he can overwrite this file. > It's not the case for VXE. What part of "regular user in chroot jail" didn't you get? If you get root in a chroot jail, the system is toast anyway. [...] > > Plus > > you make the programmer's/configurator's job a _lot_ > > harder. > You raised a very good question. It is exactly what > makes VXE different from other systems. Many security > systems dont address this question, but VXE does. You make the programmer's job essentially impossible. How on earth should I know how many times my program will legitimately call open(2)? How do I guarantee it does the same number of open(2)s each time? How do I ensure all open(2)s are done before the cracker hijacks the program? What if glibc changes, and now opens extra files behind my back? The only real anwers are "specific r/w/x acces to <foo> required" and "<foo> is off-limits" (regular permissions, perhaps ACLs) and "it does need to use it" or "it should never use it" (something in the line of capabilities). > That's why it's easy to use. One guy said that VXE is > a self-learning system (I would not go so far, but > would say that the process of building VXED (Virtual > Executing Environment Description) or jail is > automated. During creation of VXED - it runs in a test > mode - collects information about resources used by > the subsystem we want to put in 'jail'. In test mode > all violations of VXED are registered in log, but > syscalls are performed. So, administrator usually > doesnt add entries to VXED description - he just > confirms inclusion of discovered resources to be > included into VXED. Other thing administrator does is > generalization - if POPD accessed > /var/spool/mail/user1 - it's obviously should be > changed to /var/spool/mail/*. In real VXED there are > only a few entries which need generalization, so it's > easy enough. What a few particular test runs access is _not_ what all runs need, and perhaps has little in common with what is required to do the job... that requires knowledge of the task at hand, design and care. Just checking what a particular (perhaps badly written) application does in a few test cases is of absolutely no use for security. > If it would not be automated - it would be a nightmare > (as moving all needed files into chroot jail). Same nightmare. Only probably much worse. [...] > 1. If you admit that chroot helps - VXE helps even > more - it's superset of chroot features. What is the cost of that "even more"? What new security risks are involved? > 2. I didn't get it. POPD can not send e-mails. It can communitate with whoever called it, if it is your cracker... > It can > alter mailboxes in a mailbox directory. Adding, deleting, changing, rerouting delivered mail, ... > So, what do > you say? That some messages can be placed in mailboxes > of existing users? (new users can't be created - no > way to alter /etc/passwd). That is quite enough for havoc. [...] > > There are much easier ways to do this. Besides, just > > catching a problem > > that might have security implications isn't really > > enough (it means each > > time the bug is triggered you get a crash). It would > > be much better to work > > on finding and fixing the bug. > It's not the case in real life, that's why I gave a > real example - sendmail. There were a lot of problems > in sendmail for a long time - fixes were published > continuously. And people were using it. We could give > advice to sendmail developers to go and fix ALL bugs - > I can imagine their answer to such suggestion :-) They are finding and fixing bugs. There have been other architectures for MTAs proposed, designed specifically for security (sendmail was born _before_ security became an issue...). Same for other parts of the mail system. [...] > There can be bugs in VXE as well as in chroot > implementation, but people still use chroot. There are > two ideas behind that: There are a few other security mechanisms around... > 1. VXE adds security mechanisms, without replacing > existing mechanisms. So, is VXE fails there are two > possibilities: - subsystem will be terminated (most > likely - default value returned by small C code in > case of troubles with the rest of VXE is EACCESS); - > due to an error VXE will give permission for syscall - > in such case subsystem will operate as it is without > VXE, with existing security mechanisms; so - VXE > increases protection of the system. (main goal is to > prevent compromising of the system, though service can > be disrupted in some cases). Denial of service _is_ a security problem... > 2. VXE mechanism is very simple enough - it's just > additional code which checks parameters for sys calls. In LISP code for each single call? You must be kidding... [I must be pretty bored to still waste time on this nonsense...] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2004-04-10 4:17 UTC | newest] Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-04-04 6:48 kernel stack challenge Sergiy Lozovsky 2004-04-05 9:39 ` Helge Hafting 2004-04-05 17:05 ` Sergiy Lozovsky 2004-04-05 18:06 ` Timothy Miller 2004-04-05 17:59 ` Sergiy Lozovsky 2004-04-05 19:27 ` Valdis.Kletnieks 2004-04-05 21:14 ` Timothy Miller 2004-04-05 20:09 ` John Stoffel 2004-04-05 20:54 ` Sergiy Lozovsky 2004-04-05 21:08 ` Chris Wright 2004-04-05 21:40 ` Sergiy Lozovsky 2004-04-05 21:53 ` Chris Wright 2004-04-05 22:22 ` Timothy Miller 2004-04-05 23:49 ` Sergiy Lozovsky 2004-04-06 13:25 ` Jesse Pollard [not found] ` <20040406132750$3d4e@grapevine.lcs.mit.edu> [not found] ` <mit.lcs.mail.linux-kernel/20040406132750$3d4e@grapevine.lcs.mit.edu> 2004-04-06 16:40 ` Patrick J. LoPresti 2004-04-06 19:10 ` Timothy Miller 2004-04-06 20:53 ` Patrick J. LoPresti 2004-04-06 21:24 ` Timothy Miller 2004-04-07 14:36 ` Jesse Pollard 2004-04-05 21:28 ` Timothy Miller 2004-04-05 21:21 ` Stephen Smoogen 2004-04-05 22:25 ` Timothy Miller 2004-04-05 21:30 ` Sergiy Lozovsky 2004-04-05 21:45 ` Kevin Fox 2004-04-05 21:59 ` Robin Rosenberg 2004-04-05 22:52 ` Sergiy Lozovsky 2004-04-06 0:46 ` Robin Rosenberg 2004-04-06 0:55 ` Robin Rosenberg 2004-04-06 3:02 ` Sergiy Lozovsky 2004-04-06 3:04 ` Randy.Dunlap 2004-04-05 22:20 ` Timothy Miller 2004-04-05 23:27 ` Sergiy Lozovsky 2004-04-06 20:16 ` Horst von Brand 2004-04-06 20:58 ` Timothy Miller 2004-04-06 22:05 ` Sergiy Lozovsky 2004-04-06 22:56 ` Timothy Miller 2004-04-06 23:17 ` Sergiy Lozovsky 2004-04-08 13:11 ` Martin Waitz 2004-04-08 22:33 ` Sergiy Lozovsky 2004-04-07 2:44 ` Horst von Brand 2004-04-07 17:54 ` Sergiy Lozovsky 2004-04-08 2:43 ` Horst von Brand 2004-04-08 4:07 ` Sergiy Lozovsky 2004-04-08 4:29 ` Horst von Brand 2004-04-08 22:51 ` Sergiy Lozovsky 2004-04-08 15:44 ` Valdis.Kletnieks 2004-04-08 22:22 ` Sergiy Lozovsky 2004-04-09 15:27 ` Jesse Pollard 2004-04-05 21:12 ` Timothy Miller 2004-04-06 13:32 ` Helge Hafting 2004-04-06 17:44 ` Sergiy Lozovsky 2004-04-07 1:02 ` Horst von Brand 2004-04-07 1:34 ` Sergiy Lozovsky 2004-04-07 8:57 ` David Weinehall 2004-04-07 13:38 ` Chris Friesen 2004-04-07 17:12 ` Sergiy Lozovsky 2004-04-07 17:16 ` Sergiy Lozovsky 2004-04-07 2:30 ` viro 2004-04-06 18:33 ` Jamie Lokier 2004-04-06 18:51 ` Sergiy Lozovsky [not found] <1H9LV-5Jb-1@gated-at.bofh.it> 2004-04-04 11:27 ` Andi Kleen 2004-04-04 18:24 ` Sergiy Lozovsky 2004-04-04 18:38 ` Muli Ben-Yehuda [not found] <200404052043.i35KhDvS020176@turing-police.cc.vt.edu> 2004-04-05 21:06 ` Sergiy Lozovsky [not found] <200404052026.i35KQh5g004342@eeyore.valparaiso.cl> 2004-04-05 21:21 ` Sergiy Lozovsky 2004-04-06 20:01 ` Horst von Brand [not found] <200404061606.i36G6YLE003375@eeyore.valparaiso.cl> 2004-04-06 18:04 ` Sergiy Lozovsky 2004-04-06 18:28 ` John Stoffel 2004-04-06 18:48 ` Sergiy Lozovsky 2004-04-06 18:57 ` Richard B. Johnson 2004-04-06 21:15 ` Sergiy Lozovsky 2004-04-06 22:44 ` Timothy Miller 2004-04-06 22:57 ` viro 2004-04-06 23:32 ` Sergiy Lozovsky 2004-04-06 23:45 ` Robin Rosenberg 2004-04-07 2:25 ` Horst von Brand [not found] <200404061618.i36GIHgW003419@eeyore.valparaiso.cl> 2004-04-06 18:16 ` Sergiy Lozovsky 2004-04-06 20:01 ` Valdis.Kletnieks 2004-04-06 21:38 ` Sergiy Lozovsky 2004-04-06 22:46 ` Timothy Miller [not found] <24DA9B48-8827-11D8-87A5-000A9585C204@able.es> 2004-04-07 0:27 ` Sergiy Lozovsky [not found] <58907794@toto.iv> 2004-04-07 4:29 ` Peter Chubb [not found] <20040409182517.330.qmail@web40508.mail.yahoo.com> 2004-04-10 4:17 ` Horst von Brand
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).