Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Tue, 12 Nov 2002 13:30, you wrote: > xc & relatives On further reflection, those fail before they start. However, if they're subject to an execute instruction I think you have difficulties. Mind you, if you're contemplating a new CPU design, you can also consider a microcode update to an existing one. Years ago, Software AG had a Database Engine, AKA ESP, which was (I think) a Magnasson S/370 clone with extra jellyware, OS/VS1 (I think) and Adabas. It connected via CTC. Neale, do you know more about this? -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Tue, 12 Nov 2002 11:38, you wrote: > On Tue, Nov 12, 2002 at 02:00:14AM +0100, Ulrich Weigand was heard to remark: > > Linas Vepstas wrote: > > >-- if 'exception 04' can be caught and passed back up to the library, > > > > Unfortunately it can't, as key-protection violation is a 'terminating' > > exception condition, which means the CPU state at the time the > > interruption is delivered is undefined. This means that the instruction > > that caused the exception might have already been *partially* executed, > > but there's no way to find out whether and to what extent that happened. > > Ugh. Well, that could stop the show. But since the instruction causing > this would be a problem state instruction, maybe there are fewer wacky > situations to deal with. Clearly, a store can be re-executed without > harm, even if its been partly executed before. The problem would be > with any instructions that had side effects, that would not do the same > thing the second time around, as it did the first time. I don't know > what these would be. decimal instructions - ap, mp and such. xc & relatives Of more concern's the info I turned up, that the ILC can be unpredictable. Without that, you can't determine what the instruction is. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Tue, Nov 12, 2002 at 02:00:14AM +0100, Ulrich Weigand was heard to remark: > Linas Vepstas wrote: > > >-- if 'exception 04' can be caught and passed back up to the library, > > Unfortunately it can't, as key-protection violation is a 'terminating' > exception condition, which means the CPU state at the time the > interruption is delivered is undefined. This means that the instruction > that caused the exception might have already been *partially* executed, > but there's no way to find out whether and to what extent that happened. Ugh. Well, that could stop the show. But since the instruction causing this would be a problem state instruction, maybe there are fewer wacky situations to deal with. Clearly, a store can be re-executed without harm, even if its been partly executed before. The problem would be with any instructions that had side effects, that would not do the same thing the second time around, as it did the first time. I don't know what these would be. > >Aside: In some varients, the access was per-thread. > > Now this is distincly weird ;-) I would imagine this made the Well, the graphics commands were not inherently atomic; they have to be serialized. To avoid race conditions, either you allowed only one thread to have direct access :-( or you forced the use of a lock, which was out of the question because of the performance hit, or you gave each thread its own graphics context. Technically, its not hard to implement this, but it drove traditional unix guys (and torvalds & alan cox) nuts. (Since we used page tables to enforce access, each thread would have slightly different page tables: one reason they hated it.) I've never heard of direct-hardware access to an ethernet card, but in principle, one could do it: then one could avoid things like the zero-copy technology much balyhooed in the Linux kernel, and could avoid having to put portions of a web server in the kernel (khttpd), since presumably, the application could now just blast bytes directly into the ethernet card. But if one did this, imagine the bad stuff that would happen if the app was allowed to have two threads to blast bytes into the card, and you didn't do something to control that situation. You could argue for "cooperative multi-threading" but that sure has the flavour of bad old msdos/mac/win. Damned if you do, damned if you don't. anyway, to summarize: I still think that providing some mechanism to build a 'trust barrier' between app and library would be a very good tool to add to the programmer's toolkit, even if/when there are other ways to acheive the same effect. (By the same token, threads are "just processes with shared memory", and so therefore traditional unix should not support threads? But we do, and there are certain problem domains where they are just the right thing. Threads are not easy to use, and require some sophistication, but thier utility is undoubted these days.) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 msg09415/pgp0.pgp Description: PGP signature
Re: Anyone running a 2.5 kernel?
On Tue, 12 Nov 2002 01:34, you wrote: > n Mon, Nov 11, 2002 at 10:34:10AM -0500, Post, Mark K wrote: > > The only warning I can think of is that you're going to be running a > > "development" kernel. Unless you're planning on being part of the > > development process, providing feedback to the kernel developers, etc., > > you don't want to do that. If that _is_ your intent, then go for it. > > Conversely, if the 2.5 series has some new feature you find useful that > isn't present in 2.4, it makes plenty of sense to run it. I haven't > kept up with 2.5, but if we can set the wayback machine > > It was a really long time between the 1.0 release and the 1.2 release, > and somewhere in there 1.1 got loadable kernel modules. So I ran > 1.1.whatever in production for a very long time, because I was typically > running on very memory constrained systems and being able to build a > minimal kernel and load and unload device drivers at whim was very > useful to me. There is, though, a considerable difference between whatever you were doing back then and what someone might be doing on a s/390 or zSeries machine. It comes down to, if it's for educational purposes go ahead (but maybe on a PC). If it's production, only if there's not a better way. Same when 2.6 first comes out. I personally had problems with 2.2.0 and 2.4.0, with hardware that worked before didn't work now. AFAIK it still doesn't work in 2.4, last time there was some dicussion it went like this: device driver author <- it's his fault -> ext2 author -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Tue, 12 Nov 2002, Ulrich Weigand wrote: > Linas Vepstas wrote: > > >-- if 'exception 04' can be caught and passed back up to the library, > > Unfortunately it can't, as key-protection violation is a 'terminating' > exception condition, which means the CPU state at the time the > interruption is delivered is undefined. This means that the instruction > that caused the exception might have already been *partially* executed, > but there's no way to find out whether and to what extent that happened. > The only thing you can reliably do in that situation is to terminate > the process. I don't know where to look to verify that, but I did discover at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR006/6.1.4.2?SHELF=&DT=19990630131355 that the ILC can have random values at some times so I guess you're right. So, can PER be used? -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: CPU Arch Security [was: Re: Probably the first published shell code]
Linas Vepstas wrote: >-- if 'exception 04' can be caught and passed back up to the library, Unfortunately it can't, as key-protection violation is a 'terminating' exception condition, which means the CPU state at the time the interruption is delivered is undefined. This means that the instruction that caused the exception might have already been *partially* executed, but there's no way to find out whether and to what extent that happened. The only thing you can reliably do in that situation is to terminate the process. This is as opposed to a regular protection violation, which is a 'suppressing' exception condition, i.e. the interruption is delivered with a CPU state corresponding to the state before the start of the instruction causing the exception. This allows the kernel to fix up whatever caused the fault and restart the instruction. >Aside: In some varients, the access was per-thread. Now this is distincly weird ;-) I would imagine this made the implementation much more difficult (aren't threads supposed to share the same address space? ;-/), and I can't quite see the security benefits as any non-privileged thread could 'take over' the privileged thread by overwriting the code that this thread was currently executing ... >Last I heard, when a similar proposal was made for adding this to the >Linux kernel, Torvalds called it a "stupid idea" (he didn't think >per-thread storage should be done that way.) So even that did not >fit well with 'traditional unix concepts'. Well, I certainly agree with Linus as to the per-thread thing here ;-) However, if we are simply talking per-process, I think something like this is already now in the Linux kernel: the direct-rendering module (DRM) extension uses a special X server module in conjunction with kernel support to provide a similar facility to user-space processes AFAIK (on cards that have the required hardware support, of course). >If you mean, "how can we automatically check that the arguments to a=20 >subroutine call have valid values", I don't know of anyway of doing >this easily at run-time, and there are only limited tools at compile-time. >But this is a generic problem, and not limited to this discussion. >e.g. in gnome, (gtk, and in glib2 'gobjects'), there are C macros=20 >that you are supposed to use that perform run-time type checking >and type-casting. Well, I was not so much thinking about programming errors, but more about deliberate attempts to trick the trusted part into violating security. For example, on Intel the kernel address space is actually part of the process' 4 GB address space, it just isn't accessible. However, imagine a malicious user space application performs a write system call and passes a buffer address that points to some *kernel* address (i.e. above 3 GB). If the kernel would now naively fulfil the write request, it would access the data to write (which is now, in kernel context, perfectly readable) and put it into the file. User space could then read the file back, and -voila- it has accessed memory it should not be allowed to access ;-) While this problem is well-known to kernel programmers, even now there are sometimes new security exposures found due to this type of failure to validate syscall arguments ... >? Huh? A unix 'system call' is still expressed as a standard C >function call, although the 'linkage' is certainly unusual in that >it involves an SVC, and argument passing happens quite differently >than as in between 'ordinary' C calls. Well, what is expressed as a standard C function call *is* in fact a standard C function call, namely to a function implemented in libc (which actually performs the real SVC system call). As to the calling convention of the SVC itself, we cheated by disallowing more than 5 arguments, so that all arguments can be passed in registers (if there are more than 5 arguments, the libc stub packs them into a struct and passes a pointer to it to the SVC). >The 'performance' argument is difficult to win, or loose, since OS >weaknesses and strengths fundamentally alter how one goes about >designing applications & libraries. Indeed. One should never make performance arguments without having actual measurements as support; I've been bitten by 'I think this should be faster' arguments before ;-) >The 'features' argument is quite different. Clearly, the creators of >apache accept and trust all apache modules. Would they still do so >if it was 'easy' not to trust them? I suspect not. On the other hand, if it was important to them to establish a trust boundary, they could easily do so by running modules as separate processes; AFAIK the main task of a module is to create a stream of bytes to be returned to the remote user, so the interface would naturally fit a pipe/socket-based inter-process communication mechanism ... But I guess if you can't trust the module, you can't really trust the whole server, as the module is the instance that generates the data the user actuall
Re: zipl question
Mark, You were giving me the answer all the time. I was so sure I was IPLing from the correct device. I had an IPLable image on two disks and didn't realize I was booting from the wrong one. Thanks, Betsie Spann VM Systems Programmer - Original Message - From: "Post, Mark K" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 11, 2002 4:39 PM Subject: Re: zipl question > Betsie, > > Sorry I haven't gotten back to you on this sooner. I'm assuming you're > IPLing from device number 200? If not, then which unit? If so, then what > does Linux show you for the parmline contents? > > Mark Post > > -Original Message- > From: Betsie Spann [mailto:betsie.spann@;oracle.com] > Sent: Monday, November 04, 2002 11:25 AM > To: [EMAIL PROTECTED] > Subject: Re: zipl question > > > Mark, > I have a 200, 201, 203, 204. 200 is /, 201 is swap, 203 is /usr and 204 is > /home. > df > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/dasda1 348608 65644264972 20% / > /dev/dasde11417240884300460948 66% /usr > /dev/dasdd1 69640 132 65916 1% /home > [root@vmlinuxg2 root]# > > cat /proc/dasd/devices > cat /proc/dasd/devices > 0200(ECKD) at ( 94: 0) is dasda : active at blocksize: 4096, 9 > blocks, > 351 MB > 0201(FBA ) at ( 94: 4) is dasdb : active at blocksize: 512, 20480 > blocks, > 10 MB > 0202(none) at ( 94: 8) is dasdc : unknown > 0203(ECKD) at ( 94: 12) is dasdd : active at blocksize: 4096, 18000 > blocks, > 70 MB > 0204(ECKD) at ( 94: 16) is dasde : active at blocksize: 4096, 36 > blocks > , 1406 MB > [root@vmlinuxg2 root]# > cat /etc/zipl.conf > [defaultboot] > default=linux > [linux] > target=/boot/ > image=/boot/vmlinuz-2.4.9-37 > parameters="root=/dev/dasda1 dasd=200-204,300-302,400-405" > > [root@vmlinuxg2 root]# > > CP Q V DA > DASD 0190 3390 430RES R/O107 CYL ON DASD 3662 SUBCHANNEL = 0006 > DASD 0191 3390 VM365E R/O 1 CYL ON DASD 365E SUBCHANNEL = 0007 > DASD 019D 3390 430RES R/O102 CYL ON DASD 3662 SUBCHANNEL = 0005 > DASD 019E 3390 430RES R/O175 CYL ON DASD 3662 SUBCHANNEL = 0004 > DASD 0200 3390 LX1026 R/W500 CYL ON DASD 1026 SUBCHANNEL = 0008 > DASD 0201 9336 (VDSK) R/W 20480 BLK ON DASD VDSK SUBCHANNEL = 0018 > DASD 0203 3390 LX1206 R/W100 CYL ON DASD 1206 SUBCHANNEL = 0009 > DASD 0204 3390 LX1206 R/W 2000 CYL ON DASD 1206 SUBCHANNEL = 000A > DASD 0300 3390 LX100B R/W 1000 CYL ON DASD 100B SUBCHANNEL = 000B > DASD 0301 3390 LX1110 R/W 1000 CYL ON DASD 1110 SUBCHANNEL = 000C > DASD 0302 3390 LX112F R/W 1000 CYL ON DASD 112F SUBCHANNEL = 000D > DASD 0400 3390 LX100B R/W 1000 CYL ON DASD 100B SUBCHANNEL = 000E > DASD 0401 3390 LX1110 R/W 1000 CYL ON DASD 1110 SUBCHANNEL = 000F > DASD 0402 3390 LX112F R/W 1000 CYL ON DASD 112F SUBCHANNEL = 0010 > DASD 0403 3390 LX120A R/W 1000 CYL ON DASD 120A SUBCHANNEL = 0011 > DASD 0404 3390 LX120A R/W 1000 CYL ON DASD 120A SUBCHANNEL = 0012 > DASD 0405 3390 LX120A R/W 1000 CYL ON DASD 120A SUBCHANNEL = 0013 > DASD 0592 3390 430W01 R/O 67 CYL ON DASD 3663 SUBCHANNEL = 0014 > > Thanks for any insight you may have on this. > > > > Betsie Spann > VM Systems Programmer > - Original Message - > From: "Post, Mark K" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 01, 2002 5:40 PM > Subject: Re: zipl question > > > > Betsie, > > > > That was just a test to make sure zipl wasn't picking up parameters from > > somewhere else. It apparently is not, so you can rename it back. > > > > I guess I'd still like to know... are you sure you are booting from the > same > > DASD volume as /boot is on? What does a "df" command show, as well as > "cat > > /proc/dasd/devices" and what is in your /etc/zipl.conf? > > > > Mark Post > > > > -Original Message- > > From: Betsie Spann [mailto:betsie.spann@;oracle.com] > > Sent: Friday, November 01, 2002 6:18 PM > > To: [EMAIL PROTECTED] > > Subject: Re: zipl question > > > > > > Mark, > > I renamed /etc/zipl.conf and got an error message telling me that it could > > not access configuration file /etc/zipl.conf and that a target directory > > was not specified on the command line or in a config file. > > I added 'noinitrd' to the parm file but it made no difference. > > Does this have anything to do with the s390-tools or s390-utils? > > > > Betsie Spann > > VM Systems Programmer > > - Original Message - > > From: "Post, Mark K" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, November 01, 2002 1:22 PM > > Subject: Re: zipl question > > > > > > > Betsie, > > > > > > Try renaming /etc/zipl.conf to something else and see what happens when > > you > > > run the command. > > > > > > Also, are you booting from the same DASD volume as /boot is on? > > > > > > Mark Post > >
Re: zipl question
Betsie, Sorry I haven't gotten back to you on this sooner. I'm assuming you're IPLing from device number 200? If not, then which unit? If so, then what does Linux show you for the parmline contents? Mark Post -Original Message- From: Betsie Spann [mailto:betsie.spann@;oracle.com] Sent: Monday, November 04, 2002 11:25 AM To: [EMAIL PROTECTED] Subject: Re: zipl question Mark, I have a 200, 201, 203, 204. 200 is /, 201 is swap, 203 is /usr and 204 is /home. df Filesystem 1k-blocks Used Available Use% Mounted on /dev/dasda1 348608 65644264972 20% / /dev/dasde11417240884300460948 66% /usr /dev/dasdd1 69640 132 65916 1% /home [root@vmlinuxg2 root]# cat /proc/dasd/devices cat /proc/dasd/devices 0200(ECKD) at ( 94: 0) is dasda : active at blocksize: 4096, 9 blocks, 351 MB 0201(FBA ) at ( 94: 4) is dasdb : active at blocksize: 512, 20480 blocks, 10 MB 0202(none) at ( 94: 8) is dasdc : unknown 0203(ECKD) at ( 94: 12) is dasdd : active at blocksize: 4096, 18000 blocks, 70 MB 0204(ECKD) at ( 94: 16) is dasde : active at blocksize: 4096, 36 blocks , 1406 MB [root@vmlinuxg2 root]# cat /etc/zipl.conf [defaultboot] default=linux [linux] target=/boot/ image=/boot/vmlinuz-2.4.9-37 parameters="root=/dev/dasda1 dasd=200-204,300-302,400-405" [root@vmlinuxg2 root]# CP Q V DA DASD 0190 3390 430RES R/O107 CYL ON DASD 3662 SUBCHANNEL = 0006 DASD 0191 3390 VM365E R/O 1 CYL ON DASD 365E SUBCHANNEL = 0007 DASD 019D 3390 430RES R/O102 CYL ON DASD 3662 SUBCHANNEL = 0005 DASD 019E 3390 430RES R/O175 CYL ON DASD 3662 SUBCHANNEL = 0004 DASD 0200 3390 LX1026 R/W500 CYL ON DASD 1026 SUBCHANNEL = 0008 DASD 0201 9336 (VDSK) R/W 20480 BLK ON DASD VDSK SUBCHANNEL = 0018 DASD 0203 3390 LX1206 R/W100 CYL ON DASD 1206 SUBCHANNEL = 0009 DASD 0204 3390 LX1206 R/W 2000 CYL ON DASD 1206 SUBCHANNEL = 000A DASD 0300 3390 LX100B R/W 1000 CYL ON DASD 100B SUBCHANNEL = 000B DASD 0301 3390 LX1110 R/W 1000 CYL ON DASD 1110 SUBCHANNEL = 000C DASD 0302 3390 LX112F R/W 1000 CYL ON DASD 112F SUBCHANNEL = 000D DASD 0400 3390 LX100B R/W 1000 CYL ON DASD 100B SUBCHANNEL = 000E DASD 0401 3390 LX1110 R/W 1000 CYL ON DASD 1110 SUBCHANNEL = 000F DASD 0402 3390 LX112F R/W 1000 CYL ON DASD 112F SUBCHANNEL = 0010 DASD 0403 3390 LX120A R/W 1000 CYL ON DASD 120A SUBCHANNEL = 0011 DASD 0404 3390 LX120A R/W 1000 CYL ON DASD 120A SUBCHANNEL = 0012 DASD 0405 3390 LX120A R/W 1000 CYL ON DASD 120A SUBCHANNEL = 0013 DASD 0592 3390 430W01 R/O 67 CYL ON DASD 3663 SUBCHANNEL = 0014 Thanks for any insight you may have on this. Betsie Spann VM Systems Programmer - Original Message - From: "Post, Mark K" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 01, 2002 5:40 PM Subject: Re: zipl question > Betsie, > > That was just a test to make sure zipl wasn't picking up parameters from > somewhere else. It apparently is not, so you can rename it back. > > I guess I'd still like to know... are you sure you are booting from the same > DASD volume as /boot is on? What does a "df" command show, as well as "cat > /proc/dasd/devices" and what is in your /etc/zipl.conf? > > Mark Post > > -Original Message- > From: Betsie Spann [mailto:betsie.spann@;oracle.com] > Sent: Friday, November 01, 2002 6:18 PM > To: [EMAIL PROTECTED] > Subject: Re: zipl question > > > Mark, > I renamed /etc/zipl.conf and got an error message telling me that it could > not access configuration file /etc/zipl.conf and that a target directory > was not specified on the command line or in a config file. > I added 'noinitrd' to the parm file but it made no difference. > Does this have anything to do with the s390-tools or s390-utils? > > Betsie Spann > VM Systems Programmer > - Original Message - > From: "Post, Mark K" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 01, 2002 1:22 PM > Subject: Re: zipl question > > > > Betsie, > > > > Try renaming /etc/zipl.conf to something else and see what happens when > you > > run the command. > > > > Also, are you booting from the same DASD volume as /boot is on? > > > > Mark Post > > > > -Original Message- > > From: Betsie Spann [mailto:betsie.spann@;oracle.com] > > Sent: Friday, November 01, 2002 3:56 PM > > To: [EMAIL PROTECTED] > > Subject: Re: zipl question > > > > > > 'strace zipl.conf' gave me strace: zipl.conf: command not found > > when I did, "strace /sbin/zipl", I got a display similar to yours. It > > pointed to /etc/zipl.conf and /boot/parmfile. Both had the same "dasd=" > > string but neither matched the dasd used in the "Kernel command line" > shown > > at boot time or from dmesg. > > > > Betsie Spann > > VM Systems Programmer > > - Original Message - > > From: "Post, Mark K" <[EMA
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Mon, Nov 11, 2002 at 08:40:45PM +0100, Ulrich Weigand was heard to remark: > Linas Vepstas wrote: > > Every page of memory has a storage key, which holds a key and a > fetch-protection bit. If the fetch-protection bit is cleared, > then anyone can read the page; if the fetch-protection bit is > set, only code running with a PSW key equal to the page key > can read the page. So I guess you could make pages read-only > to everyone. > > Still, the question is whether read-only access is enough; a typical > library function interface is: here's a buffer, please write some > data into it. -- if 'exception 04' can be caught and passed back up to the library, then potentially the library can decide what sort of access should have been allowed: none, read-only (change fetch protection bit), and read-write (change key). -- its important to distinguish what the 390 can do today, from "what could be done if *it* (whatever *it* is) was done right". I am guilty of mising up these two. > >OK, I presented a spcific example, from the land of graphics hardware, > >from the mid 1990's, where these traditional unix solutions completely > >failed. [...] > the same: this process. Aside: In some varients, the access was per-thread. > Therefore it easily fits into the whole > Unix access rights concept. Hmm. To implement this stuff, we needed to design some fairly sophisticated kernel modules, and make some changes to page & process tables. The unix guys screamed bloody murder at the time. Last I heard, when a similar proposal was made for adding this to the Linux kernel, Torvalds called it a "stupid idea" (he didn't think per-thread storage should be done that way.) So even that did not fit well with 'traditional unix concepts'. > What you propose is a finer-grained X (not 'this process' but > 'this process while it is executing code mapped from this library'). > This is what IMO is the core problem of this idea. > > To stay with your example: why didn't you change the system so that > a process was allowed to directly access the (whole) video memory, Because we didn't trust the process > but only why it was executing code from a special, trusted video > library that ensured it didn't do anything it shouldn't? That > would have been comparable ... Because there is no way (in todays unix, in (most of) today's cpus) to trust a library. We might have argued for fundamental changes in the CPU design, if we'd figured this out earlier, but it was too late for that, and besides, as this conversation attests, new ideas are not easily accepted when it comes to the architected interface of a CPU. The app did have to use a special graphics library which made some special kernel calls to set things up. Once set up, we used a page-fault-like mechanism to serialize access to the graphics hardware. i.e. only n apps could have direct access, the (n+1)th would page fault. We'd use time-slices to make sure all n+1 had a shot at running. > Yes, but what about the difficult questions? ;-) Dunno. Wish I had enough time to think about this properly, try some prototypes, etc. As stated before, I'm not convinced that the 390 in its current state can really support the idea. It seems to have at least some of the pieces. > Where are the > arguments passed and returned? Where does the stack reside, and is > it switched at function call or not? Dunno. > [If yes, the standard C calling > convention doesn't work any more -- what to use instead? ? Huh? A unix 'system call' is still expressed as a standard C function call, although the 'linkage' is certainly unusual in that it involves an SVC, and argument passing happens quite differently than as in between 'ordinary' C calls. If done right, with all the bells & whistles, one would need to have a way of informing the linker that this is a 'special' call, and to insert some different subroutine glue code. > How to avoid tricking the xlib into doing bad things by passing incorrect > arguments to it? Well, certainly, one can check argument validity manually. The x server does this by examining each packet it receives, and doing bounds checks, etc. There is a fair amount of programmer-hour overhead to do this. If you mean, "how can we automatically check that the arguments to a subroutine call have valid values", I don't know of anyway of doing this easily at run-time, and there are only limited tools at compile-time. But this is a generic problem, and not limited to this discussion. e.g. in gnome, (gtk, and in glib2 'gobjects'), there are C macros that you are supposed to use that perform run-time type checking and type-casting. There's also crap in there for marshalling and closures and etc. that are handy for ensuring program correctness. But I view this as a language design issue, since the closure thing is more important java and scheme than it is to C. > I think in this particular example, those questions might be solvable,
Re: Virtual network topology questions...
On Mon, 2002-11-11 at 18:06, Marcy Cortes wrote: > Adam wrote: > >Here's how: go get the virgin 2.4.19 kernel sources > >from kernel.org. Go get the s390-may2002, s390-1-may2002, and > >timer-1-may2002 patches from IBM Developerworks, and apply them in > >that order. Also get the qeth driver from there. Build a kernel. > >Build your modules. Copy the qeth driver somewhere under your modules > >directory. Run depmod -a. Edit zipl.conf to boot from your new kernel, > >and run zipl. ReIPL your Linux image--into CMS, if you can. > > > Suppose another customer had a SuSE support contract. Could > that customer email Robert the kernel patch rpm file without > violating their support contract? That's all he would need to run > guest LAN on his existing HW/SW. If its GPL licensed software then the SuSE customer can do that, they can put it on the net, make T-shirts of it too. The GPL prohibits "additional restrictions", so if the support contract forbade doing that with GPL software then they would be violating the license.
Re: CPU Arch Security [was: Re: Probably the first published shel l code]
On Mon, 11 Nov 2002, Post, Mark K wrote: > Linas, > > No. Either your storage key matches, or it doesn't. If it matches, you get > read and write access, if it doesn't match, you get neither. (You _do_ get > a S0C4 abend.) > A better source;-) http://doclib.ucs.indiana.edu/cgi-bin/bookmgr/bookmgr.exe/BOOKS/DZ9AR007/3.3 A storage key is associated with each 4K-byte block of storage that is available in the configuration. The storage key has the following format: _ _ _ |ACC |F|R|C| ||_|_|_| 0 46 The bit positions in the storage key are allocated as follows: Access-Control Bits (ACC): If a reference is subject to key-controlled protection, the four access-control bits, bits 0-3, are matched with the four-bit access key when information is stored, or when information is fetched from a location that is protected against fetching. Fetch-Protection Bit (F): If a reference is subject to key-controlled protection, the fetch-protection bit, bit 4, controls whether key-controlled protection applies to fetch-type references: a zero indicates that only store-type references are monitored and that fetching with any access key is permitted; a one indicates that key-controlled protection applies to both fetching and storing. No distinction is made between the fetching of instructions and of operands. Reference Bit (R): The reference bit, bit 5, normally is set to one each time a location in the corresponding storage block is referred to either for storing or for fetching of information. Change Bit (C): The change bit, bit 6, is set to one each time information is stored at a location in the corresponding storage block. Storage keys are not part of addressable storage. The entire storage key is set by SET STORAGE KEY EXTENDED and inspected by INSERT STORAGE KEY EXTENDED. Additionally, the instruction RESET REFERENCE BIT EXTENDED provides a means of inspecting the reference and change bits and of setting the reference bit to zero. Bits 0-4 of the storage key are inspected by the INSERT VIRTUAL STORAGE KEY instruction. The contents of the storage key are unpredictable during and after the execution of the usability test of the TEST BLOCK instruction. > Mark Post > > -Original Message- > From: Linas Vepstas [mailto:linas@;linas.org] > Sent: Monday, November 11, 2002 12:57 PM > To: [EMAIL PROTECTED] > Subject: Re: CPU Arch Security [was: Re: Probably the first published > shell code] > > > -snip- > It has been years since I last looked at the 390 instruction set. Can't one > set a read-only mode for selected PSW keys? > -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: CPU Arch Security [was: Re: Probably the first published shell code]
Hello from Gregg C Levine No you won't. Laughed at, yes, lynched, no. However, I did look at the product, for Windows. And I wasn't thrilled by it. But what did happen to Multics? And when will it be released to the public? However, Scott, if you want to have something happen to you, I know a nice place on Kessel. --- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@;VM.MARIST.EDU] On Behalf Of > Scott Courtney > Sent: Monday, November 11, 2002 4:51 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] CPU Arch Security [was: Re: Probably the first > published shell code] > > On Tuesday 05 November 2002 11:13 pm, David Boyes wrote: > > > > b) Same scenario as above, but word-substitute apache->kernel and > > > >mod_trojan->device driver. [...] > > > > And we reinvent the Multics ring structure one more time > > > > dockmaster.af.mil, wherefore art thou? > > I'll be lynched for saying this, but > > Intel's iRMX operating system used to have something like this, too. > > -- > - > Scott D. Courtney, Senior Engineer Sine Nomine Associates > [EMAIL PROTECTED] http://www.sinenomine.net/
Re: CPU Arch Security [was: Re: Probably the first published shel l code]
On Mon, 11 Nov 2002, Post, Mark K wrote: > Linas, > > No. Either your storage key matches, or it doesn't. If it matches, you get > read and write access, if it doesn't match, you get neither. (You _do_ get > a S0C4 abend.) > I am looking at http://www.share.org/proceedings/SH98/data/S2826.PDF The stroage key is 7 bits. 0-3 Protect key, 0-15 4 F Fetch 5 R 6 C A program may fetch if its PDW key matches, or the F bit is zero. I'm having difficulty reading it; it's a slide presentation, landscape format and Mozilla's running xpdf inside the browser window. I turned the image round, but it's cropped. Actually, gets cropped both ways;-( My recollection, from over 20 years ago, that the page can be ro and it can be changed, but I don't see how that fits R. > Mark Post > > -Original Message- > From: Linas Vepstas [mailto:linas@;linas.org] > Sent: Monday, November 11, 2002 12:57 PM > To: [EMAIL PROTECTED] > Subject: Re: CPU Arch Security [was: Re: Probably the first published > shell code] > > > -snip- > It has been years since I last looked at the 390 instruction set. Can't one > set a read-only mode for selected PSW keys? > -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Virtual network topology questions...
On Mon, 11 Nov 2002, McKown, John wrote: > > -Original Message- > > From: Marcy Cortes [mailto:marcy@;WellsFargo.COM] > > Sent: Monday, November 11, 2002 12:06 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Virtual network topology questions... > > > > Suppose another customer had a SuSE support contract. Could > > that customer email Robert the kernel patch rpm file without > > violating their support contract? That's all he would need to run > > guest LAN on his existing HW/SW. > > > > Marcy Cortes > > Wells Fargo Services Co > > > > I think that's a very interesting question. I cannot think of how, legally, > SuSE can stop you from sending a RPM which contains "free" patches to > another person. But whether it is morally correct to "redistribute" > something for which you paid a fee and which is a source of livelihood for a > company is another question. Or can a person or organization own a > "compilation copyright" on the rpm itself, without having a copyright on any > of the elements within the RPM. I do understand how SuSE, et al., can stop > the redistribution of something like YaST. > > Discussion? Compilation is a bit like a singer's performance. Several copyrights may apply: Composer of the music Writer of the words Arranger Singer and supporting musicians. Arguably, the performance is a derived work, as is the compilation. GPL requires derived works to be GPL. -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Tuesday 05 November 2002 11:13 pm, David Boyes wrote: > > > b) Same scenario as above, but word-substitute apache->kernel and > > >mod_trojan->device driver. [...] > > And we reinvent the Multics ring structure one more time > > dockmaster.af.mil, wherefore art thou? I'll be lynched for saying this, but Intel's iRMX operating system used to have something like this, too. -- - Scott D. Courtney, Senior Engineer Sine Nomine Associates [EMAIL PROTECTED] http://www.sinenomine.net/
Re: mono RPMs
On Mon, Nov 11, 2002 at 09:59:57PM +0100, Jochen Rvhrig wrote: > On Mon, Nov 11, 2002 at 02:39:05PM -0500, Matt Zimmerman wrote: > > Have you tried the Debian packages for mono found here: > > > > http://www.debianplanet.org/mono/ > > They don't provide binaries for Debian/390 and the latest source-package > is based in mono release 0.15 (Aug 23rd, 2002) which does not yet include > Neale's patches. > > Probably the easiest way for just trying it out on Debian/390 is to build > the latest snapshot-tarball from the mono CVS-repository > (http://go-mono.com/snapshots/). Or apply the Debian packaging diff from the debianplanet.org packages to the latest mono release or snapshot (which is more or less what I was suggesting). -- - mdz
Re: mono RPMs
On Mon, Nov 11, 2002 at 02:39:05PM -0500, Matt Zimmerman wrote: > Have you tried the Debian packages for mono found here: > > http://www.debianplanet.org/mono/ They don't provide binaries for Debian/390 and the latest source-package is based in mono release 0.15 (Aug 23rd, 2002) which does not yet include Neale's patches. Probably the easiest way for just trying it out on Debian/390 is to build the latest snapshot-tarball from the mono CVS-repository (http://go-mono.com/snapshots/). Jochen Rvhrig ([EMAIL PROTECTED])
Re: CPU Arch Security [was: Re: Probably the first published shel l code]
The keys don't have to match if the fetch pretection bit is 0. See from z/900 PofO: 3.3 Storage Key A storage key is associated with each 4K-byte block of storage that is available in the configuration. The storage key has the following format: ACC FRC 0 46 Fetch-Protection Bit (F): If a reference is subject to key-controlled protection, the fetch-protection bit, bit 4, controls whether key-controlled protection applies to fetch-type references:a zero indicates that only store-type references are monitored and that fetching with any access key is permitted; a one indicates that key-controlled protection applies to both fetching and storing. No distinction is made between the fetching of instructions and of operands. To: [EMAIL PROTECTED] "Post, Mark K" cc: (bcc: Michael Short/Towers Perrin) <[EMAIL PROTECTED]Subject: Re: CPU Arch Security [was: Re: Probably the first published shel l m>code] Sent by: Linux on 390 Port <[EMAIL PROTECTED] IST.EDU> 11/11/2002 02:27 PM Please respond to Linux on 390 Port Linas, No. Either your storage key matches, or it doesn't. If it matches, you get read and write access, if it doesn't match, you get neither. (You _do_ get a S0C4 abend.) Mark Post -Original Message- From: Linas Vepstas [mailto:linas@;linas.org] Sent: Monday, November 11, 2002 12:57 PM To: [EMAIL PROTECTED] Subject: Re: CPU Arch Security [was: Re: Probably the first published shell code] -snip- It has been years since I last looked at the 390 instruction set. Can't one set a read-only mode for selected PSW keys?
Re: Virtual network topology questions...
Without having seen one of those contracts, I would not be able to comment on the particulars. Since the pieces under discussion in this scenario are all GPL, then any recipient has the right to redistribute it freely. Any attempt to restrict that right is in itself a violation of the GPL. Sharing such things as userids and passwords to restricted sites would be another matter entirely. Mark Post -Original Message- From: Marcy Cortes [mailto:marcy@;WellsFargo.COM] Sent: Monday, November 11, 2002 1:06 PM To: [EMAIL PROTECTED] Subject: Re: Virtual network topology questions... Adam wrote: >Here's how: go get the virgin 2.4.19 kernel sources >from kernel.org. Go get the s390-may2002, s390-1-may2002, and >timer-1-may2002 patches from IBM Developerworks, and apply them in >that order. Also get the qeth driver from there. Build a kernel. >Build your modules. Copy the qeth driver somewhere under your modules >directory. Run depmod -a. Edit zipl.conf to boot from your new kernel, >and run zipl. ReIPL your Linux image--into CMS, if you can. Suppose another customer had a SuSE support contract. Could that customer email Robert the kernel patch rpm file without violating their support contract? That's all he would need to run guest LAN on his existing HW/SW. Marcy Cortes Wells Fargo Services Co
Re: CPU Arch Security [was: Re: Probably the first published shel l code]
> -Original Message- > From: Post, Mark K [mailto:mark.post@;eds.com] > Sent: Monday, November 11, 2002 1:28 PM > To: [EMAIL PROTECTED] > Subject: Re: CPU Arch Security [was: Re: Probably the first > published shel l code] > > > Linas, > > No. Either your storage key matches, or it doesn't. If it > matches, you get > read and write access, if it doesn't match, you get neither. > (You _do_ get > a S0C4 abend.) > > Mark Post > Not entirely true, but it can be a bit complicated. If the PSW key is zero, then it can fetch from any page and store into any page except: addresses 0-511 if "low address protection" is turned on. (and bytes 4096-4607 in zArchitecture mode as well) The page table entry for the address is marked as "read only". If the PSW key is not zero and matches the key of the piece of storage, it can store into the page unless the page table entry is marked as "read only". It can always fetch the contents of the page. If the PSW key is not zero and does not match the key in storage, it cannot store into the page under any conditions. (Well, this is a lie, but even more complicated due to "subspace groups" which are not used in Linux/390). It can fetch from the page if the "fetch protect" bit is *not* on. If the "fetch protect" bit is on, then it will get an interrupt code 4. -- John McKown Senior Technical Specialist UICI Insurance Center Applications & Solutions Team +1.817.255.3225
Re: mono RPMs
On Mon, Nov 11, 2002 at 08:28:42PM +0100, Jochen Rvhrig wrote: > I'm just trying to get the alien-converted rpm's running on a Debian/390 > system and unfortunately I only get a segfault when running mint on my > sample program ... Have you tried the Debian packages for mono found here: http://www.debianplanet.org/mono/ -- - mdz
Re: CPU Arch Security [was: Re: Probably the first published shell code]
Linas Vepstas wrote: On Sat, Nov 09, 2002 at 08:01:55PM +0100, Ulrich Weigand was heard to remark: >> Just use mmap, and use file access rights to protect the data. > >How can a library get read-write access to a file, while preventing >the app from writing to the same file? Of course you need two processes, that's my point: different access rights means different processes. Once you have two processes, it is trivial; one process gets read-write access to the file, the other read-only. >> Because the library call has switched the PSW key, that was your >> whole point, wasn't it? So if the caller was able to access that >> memory, the callee (running with a different PSW key) won't be. > >OK, on this point, maybe I am indeed quite stupid. It has been years >since I last looked at the 390 instruction set. Can't one set a >read-only mode for selected PSW keys? Every page of memory has a storage key, which holds a key and a fetch-protection bit. If the fetch-protection bit is cleared, then anyone can read the page; if the fetch-protection bit is set, only code running with a PSW key equal to the page key can read the page. So I guess you could make pages read-only to everyone. Still, the question is whether read-only access is enough; a typical library function interface is: here's a buffer, please write some data into it. >OK, I presented a spcific example, from the land of graphics hardware, >from the mid 1990's, where these traditional unix solutions completely >failed. This is fine, but it is quite different from what you're suggesting here. These high-end graphics cards allow access to part of the video memory, however the access is still per-process. I.e. if you characterize access rights in the form 'X is allowed to do Y', then these mechanisms enable a finer-grained Y (instead of 'access video memory' only 'access this part of video memory'), while X is still the same: this process. Therefore it easily fits into the whole Unix access rights concept. What you propose is a finer-grained X (not 'this process' but 'this process while it is executing code mapped from this library'). This is what IMO is the core problem of this idea. To stay with your example: why didn't you change the system so that a process was allowed to directly access the (whole) video memory, but only why it was executing code from a special, trusted video library that ensured it didn't do anything it shouldn't? That would have been comparable ... >OK, take for example, the X11 server. Rip out the socket communications >part, and let the xlib calls call directly those routines that the >X11 server would call, after it decodes a bit of protocol it read from a >socket. > >> (I.e. which memory areas get what storage >> key, what's in them, what pieces of code run under which >> PSW key and/or mask, and at what places the keys are switched?) > >The psw key would switch at the xlib boundary. The memory that >is in the x-server would run under the x-server's key, while the client >would run under a different key. Yes, but what about the difficult questions? ;-) Where are the arguments passed and returned? Where does the stack reside, and is it switched at function call or not? [If yes, the standard C calling convention doesn't work any more -- what to use instead? If no, the program can potentially corrupt the library's stack or vice versa.] How to avoid tricking the xlib into doing bad things by passing incorrect arguments to it? I think in this particular example, those questions might be solvable, because the current design already has a clear separation in place. So you'd for example just continue to do the same validity checks on arguments that the X server currently does. Also, the data is currently already prepared for passing across a socket, so you don't need to pass complex data structures containing pointers; this means it would be easy to pass just a single data block across the protection boundary. But if you do that, you basically have exactly the same scenario as now, except that the read/write across the socket is replaced by a program call (plus possibly some other actions like stack switching; in fact you might even need to perform a system call to inform the kernel that you're now in another protection domain). So what does all this buy you? A context switch on Linux is already quite fast, and while a program call might be a bit faster, it is also a complex milli-coded instruction that takes hundreds of cycles AFAIK, so I'm not convinced this gets you a huge increase in speed ... (This holds even more if you do need a system call; a system call with or without a context switch takes about the same time, at least on S/390.) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
Re: Virtual network topology questions...
On Mon, Nov 11, 2002 at 10:06:01AM -0800, Marcy Cortes wrote: > Suppose another customer had a SuSE support contract. Could > that customer email Robert the kernel patch rpm file without > violating their support contract? That's all he would need to run > guest LAN on his existing HW/SW. I think so. I would assume that SuSE cannot restrict the distribution of patches to the GPL parts of the system, of which the kernel is certainly one. I am not a lawyer, etc., and all the standard disclaimers apply. Adam
Re: mono RPMs
Neale, On Fri, Nov 08, 2002 at 01:36:47PM -0700, Ferguson, Neale wrote: > For those who'd like to play with the C# open-source package "mono", > the necessary RPMs can be downloaded from "http://go-mono.com/download";. > I don't think you need the -devel RPMs if you just want to play. What modifications did you do to get it running on 390? Do you have some patches or source-rpm's? On what system did you build the rpm's? SuSE? RedHat? What version? I'm just trying to get the alien-converted rpm's running on a Debian/390 system and unfortunately I only get a segfault when running mint on my sample program ... Jochen Rvhrig ([EMAIL PROTECTED])
Re: CPU Arch Security [was: Re: Probably the first published shel l code]
Linas, No. Either your storage key matches, or it doesn't. If it matches, you get read and write access, if it doesn't match, you get neither. (You _do_ get a S0C4 abend.) Mark Post -Original Message- From: Linas Vepstas [mailto:linas@;linas.org] Sent: Monday, November 11, 2002 12:57 PM To: [EMAIL PROTECTED] Subject: Re: CPU Arch Security [was: Re: Probably the first published shell code] -snip- It has been years since I last looked at the 390 instruction set. Can't one set a read-only mode for selected PSW keys?
Re: Virtual network topology questions...
> -Original Message- > From: Marcy Cortes [mailto:marcy@;WellsFargo.COM] > Sent: Monday, November 11, 2002 12:06 PM > To: [EMAIL PROTECTED] > Subject: Re: Virtual network topology questions... > > Suppose another customer had a SuSE support contract. Could > that customer email Robert the kernel patch rpm file without > violating their support contract? That's all he would need to run > guest LAN on his existing HW/SW. > > Marcy Cortes > Wells Fargo Services Co > I think that's a very interesting question. I cannot think of how, legally, SuSE can stop you from sending a RPM which contains "free" patches to another person. But whether it is morally correct to "redistribute" something for which you paid a fee and which is a source of livelihood for a company is another question. Or can a person or organization own a "compilation copyright" on the rpm itself, without having a copyright on any of the elements within the RPM. I do understand how SuSE, et al., can stop the redistribution of something like YaST. Discussion? -- John McKown Senior Technical Specialist UICI Insurance Center Applications & Solutions Team +1.817.255.3225
Re: Virtual network topology questions...
Adam wrote: >Here's how: go get the virgin 2.4.19 kernel sources >from kernel.org. Go get the s390-may2002, s390-1-may2002, and >timer-1-may2002 patches from IBM Developerworks, and apply them in >that order. Also get the qeth driver from there. Build a kernel. >Build your modules. Copy the qeth driver somewhere under your modules >directory. Run depmod -a. Edit zipl.conf to boot from your new kernel, >and run zipl. ReIPL your Linux image--into CMS, if you can. Suppose another customer had a SuSE support contract. Could that customer email Robert the kernel patch rpm file without violating their support contract? That's all he would need to run guest LAN on his existing HW/SW. Marcy Cortes Wells Fargo Services Co
Re: CPU Arch Security [was: Re: Probably the first published shell code]
On Sat, Nov 09, 2002 at 08:01:55PM +0100, Ulrich Weigand was heard to remark: > Linas Vepstas wrote: > > > But in my storage-key world, I can imagine spearating the strcture > > from the data, and putting the structure in read-only memory, where the > > app can see it but not corrupt it, and putting the data in a read-write > > key, where the app can do whatever it wants. > > And *once you have cleanly separated the two* (which is the > diffcult part), why can't you just put them into two separate > files, one of which is mmapped read-only? because the library still needs to have read-write access to the data. Think about it. > > In this kind of app, if you had to hide the data behind a socket, > > I claim you would get performance roughly comparable to ordinary > > file-io, and nowhere near the speed of memory-mapped io. > > In Linux, memory-mapped io is usually somewhat slower than > file-io. (Both access the same page cache, but mmap in > addition has to maintain all those page tables ...) There Depends on the access pattern. Doing pointer math is a lot faster than calling read()/write(), esp. when the page in question is already mapped, and one is doing multiple writes. It can be hard to modify a library/app to consolidate memory access so that fewer write()'s can be used. > Just use mmap, and use file access rights to protect the data. How can a library get read-write access to a file, while preventing the app from writing to the same file? > Because the library call has switched the PSW key, that was your > whole point, wasn't it? So if the caller was able to access that > memory, the callee (running with a different PSW key) won't be. OK, on this point, maybe I am indeed quite stupid. It has been years since I last looked at the 390 instruction set. Can't one set a read-only mode for selected PSW keys? > I do not doubt that you might find some problems where the S/390 > storage keys could help. But I'm not convinced that any such > solution will be significantly easier to implement and/or show > significantly higher performance than solutions that could be > implmented using the generic Unix protection mechanisms (separate > processes, mmap, file access rights). OK, I presented a spcific example, from the land of graphics hardware, from the mid 1990's, where these traditional unix solutions completely failed. You can choose not to beleive me, or you can root around in the technical literature from that era (e.g. siggraph proceedings) to discover some of the novel machines that were built. These machines drove a multi-billion dollar industry at the time, and offered significant performance improvements (at least 10x and up from there) over "generic Unix protection mechanisms". > In any case, I have still not quite understood just how the > solution you are proposing is supposed to work. Could you > give an example of a problem you want to solve, and how you > would go about it? OK, take for example, the X11 server. Rip out the socket communications part, and let the xlib calls call directly those routines that the X11 server would call, after it decodes a bit of protocol it read from a socket. > (I.e. which memory areas get what storage > key, what's in them, what pieces of code run under which > PSW key and/or mask, and at what places the keys are switched?) The psw key would switch at the xlib boundary. The memory that is in the x-server would run under the x-server's key, while the client would run under a different key. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
Re: Anyone running a 2.5 kernel?
I personally would not recommend that someone else run a development kernel in production, unless they really understand just what that means. The potential for system problems is very much higher which may (or may not) offset the added functionality. Before going that route, try it out as thoroughly as possible in a test image before putting workload of any value on the system. Make sure you have good backups. :) Mark Post -Original Message- From: Adam Thornton [mailto:athornton@;sinenomine.net] Sent: Monday, November 11, 2002 12:35 PM To: [EMAIL PROTECTED] Subject: Re: Anyone running a 2.5 kernel? n Mon, Nov 11, 2002 at 10:34:10AM -0500, Post, Mark K wrote: > The only warning I can think of is that you're going to be running a > "development" kernel. Unless you're planning on being part of the > development process, providing feedback to the kernel developers, etc., you > don't want to do that. If that _is_ your intent, then go for it. Conversely, if the 2.5 series has some new feature you find useful that isn't present in 2.4, it makes plenty of sense to run it. I haven't kept up with 2.5, but if we can set the wayback machine It was a really long time between the 1.0 release and the 1.2 release, and somewhere in there 1.1 got loadable kernel modules. So I ran 1.1.whatever in production for a very long time, because I was typically running on very memory constrained systems and being able to build a minimal kernel and load and unload device drivers at whim was very useful to me. Adam
Re: Anyone running a 2.5 kernel?
n Mon, Nov 11, 2002 at 10:34:10AM -0500, Post, Mark K wrote: > The only warning I can think of is that you're going to be running a > "development" kernel. Unless you're planning on being part of the > development process, providing feedback to the kernel developers, etc., you > don't want to do that. If that _is_ your intent, then go for it. Conversely, if the 2.5 series has some new feature you find useful that isn't present in 2.4, it makes plenty of sense to run it. I haven't kept up with 2.5, but if we can set the wayback machine It was a really long time between the 1.0 release and the 1.2 release, and somewhere in there 1.1 got loadable kernel modules. So I ran 1.1.whatever in production for a very long time, because I was typically running on very memory constrained systems and being able to build a minimal kernel and load and unload device drivers at whim was very useful to me. Adam
Re: Device busy
Werner, This has been experienced previously. If you're "adding" a new control unit to an LPAR, you have to manually configure it online to the LPAR before it can be used. For MVS, etc., this can be done by the operating system, but you'll probably need to do it from the service console. Mark Post -Original Message- From: Werner Kuehnel [mailto:werner.kuehnel@;mannheimer.de] Sent: Monday, November 11, 2002 6:05 AM To: [EMAIL PROTECTED] Subject: Device busy I installed Linux (SLES for S/390) onto 3 3390-3 volumes some months ago and got it started from disk. When trying to restart last week I discovered that the 3 volumes were no longer accessible by the Linux LPAR, sometime the configuration changed. So I changed the IODF/IOCDS dynamically to allow the Linux LPAR access to only the 3 volumes and the OSA and OSA-Express devices (chpids are of course shared by EMIF). After starting the LOAD at HMC the following message appear: "The load control unit and device is busy. The load control unit and device may be shared by another system." The 3 volumes are offline and has no logical paths in all running LPARs. All other LPARs are deactivated. I've searched all archives, fora and redbooks, well, there are some hits, mostly with IPL from tape, but couldn't find yet any hint how to overcome this problem. I'd really appreciate any help. Thanks, Werner -- _ Werner Kuehnel IMD GmbH (Mannheimer Versicherung) Mannheim - Germany "Besuchen Sie uns im Internet: http://www.mannheimer.de";
Re: CPU Arch Security
Hi, I think that I can understand both views, but I can only say that I think the concepts needed to exploit the different execution domains within one process is asking for a new operating system and that I guess this new operating system might be S/390-specific or the applications using it would be specific to S/390, but then the IBM model of having one OS (Linux) for every IBM eServer would not fit for this thing. >From the development and testing perspecive it would also be better to work on improving the existing Linux applications and operating system environments to run a normal user, use capabilites, compartments (chrooted environments) and everybody, not only the S/390 server users would benefit.(I want to have the same capabilies on my home server or PDA) Bernd
sysconfig files and such
Hello all- I have a couple of general questions that I was wondering about: 1. My linux boxes keep coming up with the network configs being wrong, mostly the netmask is wrong, and hence the default route doesn't work or isn't there at all, because the network is unreachable. I have defined the netmask in the ifcfg-"interface type"0 file in /etc/sysconfig/network-scripts directory as NETMASK=255.255.255.xxx. Is there something I am missing? This definition works quite well on a standard RedHat box on Intel, and there shouldn't be any issues with platform after the OS is booted for this config. I have the interface aliased in /etc/modules.conf, and it is getting defined and brought up there, but my netmask (and hence, the default route) are not there when I come up, any ideas? 2. I need a number of routes on one of my boxes to come up at boot, where do I define these? I haven't done the google search yet for this, and I imagine the answer will be right there when I run that, but as I am writing this right now, I figured to ask here. Thanks in advance for any help, have a good day M Butler
Re: CPU Arch Security
Jan Jaeger wrote: >I am not sure that one would run away from the concept of unix. One can >easily (in concept anyway) add more spaces to one process, separate spaces >for code, stack and data for example. >Similarly, shared libs could reside in their own space, one would need a >different linkage mechanism, but it can effectively been done. Such a >linkage mechanism can also reduce/extend the program authority (based on key >masks for example, and what spaces are accesible from the shared lib, and to >what extent). The same logic can be applied to different code segments >within one process. The (initial) linkage would need some supervisor >assistance in order to setup/verify program authorisations. Yes, but the problem remains that you need to have the kernel aware of those sub-process authorization domains, so that it will be able to properly allow or reject syscall actions depending on what part of the process performed the syscall. So there's at least one fundamentally new concept needed, and I'm not sure what exactly the proper semantics of this concept should be. As a secondary consideration you need to make sure that user space cannot undermine this new authorization domain scheme; this means that code running in one domain cannot modifiy memory belonging to another one, but also e.g. that you cannot randomly call into another domain but only at defined entry points. (This item is where hardware support is helpful.) Obviously, you'd also need to use different stacks for code running in different domains. Finally, for this to make any sense the various pieces of code running in different domains would need to treat all input received from other domains as potentially hostile and fully validate it (like the kernel needs to validate all syscall arguments to avoid being tricked into doing something bad by hostile user space). The same applies for data residing in 'shared' memory (i.e. memory that is accessible from multiple domains) -- everything there must also be validated before being used. >I would actually like to see those mechanisms applicable to one process, >inter process communication is a different issue. Surely, one can do a lot >of message passing between processes in order to isolate different program >segments, but that is not quite what I see as an issue here, or even a >solution. What I don't understand is why this is all that different. Seeing as how you need to be very careful with any input received from another domain, cross-domain calls would need to be carefully implemented and all arguments would need to undergo validation, this means that you'd structure those interfaces quite similar to inter-process interfaces in any case. >If one where to implement any sort of facility that compartimentalises >programs and code fragments in their execution environment, then that could >greatly reduce the damage a potential exploit or programming error could do. Sure, but my point was what additional advantages authorization domains within a single process have over just using multiple processes as domains. If the former would allow existing programs to be made more secure without major changes, I could see the point. But I don't believe this to be the case, in fact I think that changing a program to exploit these domains would need at least as much effort as changing it to a multi-process regime. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
Re: Anyone running a 2.5 kernel?
Don, The only warning I can think of is that you're going to be running a "development" kernel. Unless you're planning on being part of the development process, providing feedback to the kernel developers, etc., you don't want to do that. If that _is_ your intent, then go for it. Mark Post -Original Message- From: Don Mulvey [mailto:dlmulvey@;us.ibm.com] Sent: Monday, November 11, 2002 10:10 AM To: [EMAIL PROTECTED] Subject: Anyone running a 2.5 kernel? Hi, I was wondering if any of you were running a 2.5 kernel. I haven't tried it yet myself and am about to do so. Any warnings/suggestions would be appreciated. Thanks, Don
New Linux/390 Redpiece - Experiences with Oracle for Linux on zSe ries
On November 4th, IBM released a draft of a new Redbook. The abstract page states: This IBM Redbook describes experiences gained while installing and testing Oracle9i for Linux on zSeries, such as: -Setting up the development systems at Oracle for the Linux on zSeries environment -Installing the Oracle9i instances for Linux/390 on zSeries -Performing basic monitoring and tuning exercises. The book is based on real-world experiences gained by team members and technical professionals during development and early testing of this product at: -The IBM Oracle EMEA Joint Solution Center, Montpellier, France -The IBM Oracle International Competency Center, San Mateo, California -Early customer installations -Development systems at Oracle in Redwood Shores, California. This redbook will be of use to those customers who are using Oracle9i for Linux/390 on zSeries for the first time. http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/sg246552.html Mark Post
Anyone running a 2.5 kernel?
Hi, I was wondering if any of you were running a 2.5 kernel. I haven't tried it yet myself and am about to do so. Any warnings/suggestions would be appreciated. Thanks, Don
Re: Device busy
No, just one CEC. I also believe that a POR would do the job, but I fear I won't get the time for a POR :-( I'd like to know if this is a consequence of dynamically changing the access to the devices and OS/390 2.10 or JES3 doesn't really give them free, although they're offline. Werner Kuehnel IMD GmbH (Mannheimer Versicherung) Mannheim - Germany "McKown, John" wrote: > > Ouch! That hurts. I'm at a loss. I am fairly sure that a POR of the box will > clear the condition. But that is very extreme and likely to get other people > a bit upset at you . Do you have more than one CEC? Could another CEC > have the device "tied up"? > > -- > John McKown > Senior Technical Specialist > UICI Insurance Center > Applications & Solutions Team > +1.817.255.3225 > --
Re: What to ask RedHat presenters about SuSE on OS/390 vs Redhat?
On Mon, Nov 11, 2002 at 09:38:16AM -0500, David Boyes wrote: > > I don't think that Red Hat is new to non-IA32 archs at all. I'm sure > > I'm getting my years wrong, but they did have an Alpha and Sparc port > > throughout the late 1990s. > > At least until 2000, I believe. I remember talking with a customer just > after RH discontinued the Sparc port, and the RH person in the room > casually said if you'd buy 600 copies at full price, they'd bring it > back. ftp.auroralinux.org contains a real nice and stable sparc port of Red Hat Linux 7.3. It has many sparc fixes in it as well as some important errata rpms past the release. Should be a real nice start and in general you can easily recompile further errata rpms released for x86. Red Hat Linux is very modular and in general easily ported to new archs, the question is more the demand for such ports. greetings, Florian La Roche
Re: Device busy
Ouch! That hurts. I'm at a loss. I am fairly sure that a POR of the box will clear the condition. But that is very extreme and likely to get other people a bit upset at you . Do you have more than one CEC? Could another CEC have the device "tied up"? -- John McKown Senior Technical Specialist UICI Insurance Center Applications & Solutions Team +1.817.255.3225 -Original Message- From: Werner Kuehnel [mailto:werner.kuehnel@;mannheimer.de] Sent: Monday, November 11, 2002 8:17 AM To: [EMAIL PROTECTED] Subject: Re: Device busy Hi John, just tried it, not even with a RESET CLEAR it works. Werner
Re: What to ask RedHat presenters about SuSE on OS/390 vs Redhat?
> I don't think that Red Hat is new to non-IA32 archs at all. I'm sure > I'm getting my years wrong, but they did have an Alpha and Sparc port > throughout the late 1990s. At least until 2000, I believe. I remember talking with a customer just after RH discontinued the Sparc port, and the RH person in the room casually said if you'd buy 600 copies at full price, they'd bring it back. -- db
Re: Device busy
Hi John, just tried it, not even with a RESET CLEAR it works. Werner "McKown, John" wrote: > > Werner, > I got something like that on an OS/390 IPL attempt. The same message, and > the devices in question were "off line" to all other LPARs. I then did a > "reset clear" on the LPAR that I was attempting to IPL, then IPL'ed it > again. This time it worked! It appears that the microcode assumed that the > IPL was still being attempted, even after the error message was displayed. > The "RESET CLEAR" cleared up the problem. > > -- > John McKown > Senior Technical Specialist > UICI Insurance Center > Applications & Solutions Team > +1.817.255.3225 > > > -Original Message- > From: Werner Kuehnel [mailto:werner.kuehnel@;mannheimer.de] > Sent: Monday, November 11, 2002 5:05 AM > To: [EMAIL PROTECTED] > Subject: Device busy > > > I installed Linux (SLES for S/390) onto 3 3390-3 volumes some months ago and > got it started from disk. When trying to restart last week I discovered that > the 3 volumes were no longer accessible by the Linux LPAR, sometime the > configuration changed. So I changed the IODF/IOCDS dynamically to allow the > Linux LPAR access to only the 3 volumes and the OSA and OSA-Express devices > (chpids are of course shared by EMIF). After starting the LOAD at HMC the > following message appear: "The load control unit and device is busy. The > load control unit and device may be shared by another system." The 3 volumes > are offline and has no logical paths in all running LPARs. All other LPARs > are deactivated. I've searched all archives, fora and redbooks, well, there > are some hits, mostly with IPL from tape, but couldn't find yet any hint how > to overcome this problem. > > I'd really appreciate any help. > > Thanks, > Werner > -- > > _ > > Werner Kuehnel > IMD GmbH (Mannheimer Versicherung) > Mannheim - Germany > > "Besuchen Sie uns im Internet: http://www.mannheimer.de"; -- _ Werner Kuehnel IMD GmbH (Mannheimer Versicherung) Mannheim - Germany "Besuchen Sie uns im Internet: http://www.mannheimer.de";
Re: Device busy
Werner, I got something like that on an OS/390 IPL attempt. The same message, and the devices in question were "off line" to all other LPARs. I then did a "reset clear" on the LPAR that I was attempting to IPL, then IPL'ed it again. This time it worked! It appears that the microcode assumed that the IPL was still being attempted, even after the error message was displayed. The "RESET CLEAR" cleared up the problem. -- John McKown Senior Technical Specialist UICI Insurance Center Applications & Solutions Team +1.817.255.3225 -Original Message- From: Werner Kuehnel [mailto:werner.kuehnel@;mannheimer.de] Sent: Monday, November 11, 2002 5:05 AM To: [EMAIL PROTECTED] Subject: Device busy I installed Linux (SLES for S/390) onto 3 3390-3 volumes some months ago and got it started from disk. When trying to restart last week I discovered that the 3 volumes were no longer accessible by the Linux LPAR, sometime the configuration changed. So I changed the IODF/IOCDS dynamically to allow the Linux LPAR access to only the 3 volumes and the OSA and OSA-Express devices (chpids are of course shared by EMIF). After starting the LOAD at HMC the following message appear: "The load control unit and device is busy. The load control unit and device may be shared by another system." The 3 volumes are offline and has no logical paths in all running LPARs. All other LPARs are deactivated. I've searched all archives, fora and redbooks, well, there are some hits, mostly with IPL from tape, but couldn't find yet any hint how to overcome this problem. I'd really appreciate any help. Thanks, Werner -- _ Werner Kuehnel IMD GmbH (Mannheimer Versicherung) Mannheim - Germany "Besuchen Sie uns im Internet: http://www.mannheimer.de";
Re: What to ask RedHat presenters about SuSE on OS/390 vs Redhat?
On Mon, 2002-11-11 at 02:45, Alex deVries wrote: > Jon R. Doyle wrote: > > I have too, it is my experience RH is new to the multi-platform > > capability, but they are not new to marketing, they are great at that, ala > > M$. > > > > I don't think that Red Hat is new to non-IA32 archs at all. I'm sure > I'm getting my years wrong, but they did have an Alpha and Sparc port > throughout the late 1990s. Red Hat have done Sparc and Alpha releases, also PPC and some other bits, as well as a "rough cuts" CD of the third party ports to m68k, (yes I ran Red Hat on my MacII), mips and the like. Unlike Debian which does have things like a MacII port, MCA bus, and the like Red Hat can't go around doing ports that are not commercially viable, especially as we then have to provide the customers support. Alan
Device busy
I installed Linux (SLES for S/390) onto 3 3390-3 volumes some months ago and got it started from disk. When trying to restart last week I discovered that the 3 volumes were no longer accessible by the Linux LPAR, sometime the configuration changed. So I changed the IODF/IOCDS dynamically to allow the Linux LPAR access to only the 3 volumes and the OSA and OSA-Express devices (chpids are of course shared by EMIF). After starting the LOAD at HMC the following message appear: "The load control unit and device is busy. The load control unit and device may be shared by another system." The 3 volumes are offline and has no logical paths in all running LPARs. All other LPARs are deactivated. I've searched all archives, fora and redbooks, well, there are some hits, mostly with IPL from tape, but couldn't find yet any hint how to overcome this problem. I'd really appreciate any help. Thanks, Werner -- _ Werner Kuehnel IMD GmbH (Mannheimer Versicherung) Mannheim - Germany "Besuchen Sie uns im Internet: http://www.mannheimer.de";
Re: What to ask RedHat presenters about SuSE on OS/390 vs Redhat?
Hello from Gregg C Levine And you are not. I will accept corrections, but I believe they were the first ones to create non Intel ports of Linux. That is actively released ones. Everyone one was, and still is tinkering their way through such. --- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@;VM.MARIST.EDU] On Behalf Of > Alex deVries > Sent: Sunday, November 10, 2002 9:46 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] What to ask RedHat presenters about SuSE on OS/390 > vs Redhat? > > Jon R. Doyle wrote: > > I have too, it is my experience RH is new to the multi-platform > > capability, but they are not new to marketing, they are great at that, ala > > M$. > > > > I don't think that Red Hat is new to non-IA32 archs at all. I'm sure > I'm getting my years wrong, but they did have an Alpha and Sparc port > throughout the late 1990s. > > > - Alex > > -- > Alex deVries > Principal Architect, Linuxcare Canada, Inc. > (613) 562 2759 > > Linuxcare. Simplifying Server Consolidation.
