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.
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
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: 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
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 grin. 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?
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
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 grin. 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 --
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
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
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: 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
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: 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: 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: 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: 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 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: 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]
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 mcode] 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: 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: 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: 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: 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 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: 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.) 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: 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 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, because the current design already has a
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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 12:48 PM Subject: Re: zipl question
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 -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
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 actually sees. Can one create a
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: 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, 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: 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, 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
