Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #212161
| From | John Levine <johnl@taugh.com> |
|---|---|
| Newsgroups | alt.folklore.computers |
| Subject | Re: Early mainframe security and channel programs |
| Date | 2020-06-30 02:58 +0000 |
| Organization | Taughannock Networks |
| Message-ID | <rde9o7$uq$1@gal.iecc.com> (permalink) |
| References | <rddjkg$ffe$1@z-news.wcss.wroc.pl> <rddo9i$ujo$1@dont-email.me> <rde0tn$n2b$1@z-news.wcss.wroc.pl> |
In article <rde0tn$n2b$1@z-news.wcss.wroc.pl>, <antispam@math.uni.wroc.pl> wrote: >That is part I want to understand. It seems that access macros set >up control blocks in user space. So user could tamper those control >blocks in arbitrary way. It is not entirely clear to me how system >ensured that access method will do its job. IIUC access method >run outside of resident part of nucleus and it seems that it used >SVC to communicate with nucleus. Yup. The access method wrote its own channel programs and passed them to the supervisor to run. Of if you wanted, your application could do an EXCP itself to run any channel program it wanted. Sounds pretty dangerous, huh? Nope. It wrote a litttle channel program of its own that did a "set file mask" command and then jumped (TIC for transfer in channel) to your program. The set file mask tells the channel what your channel program is allowed to do, confining it to a particular cylinder or track. To prevent stomping other programs, every 2K storage block had a four-bit storage key, and each running program and each channel program also had a storage key which had to match the key for any data it wrote (and depending on settings, maybe also any data it read.) -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Back to alt.folklore.computers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Early mainframe security antispam@math.uni.wroc.pl - 2020-06-29 20:40 +0000
Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 13:49 -0700
Re: Early mainframe security Dan Espen <dan1espen@gmail.com> - 2020-06-29 16:53 -0400
Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-29 23:59 +0000
Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 17:24 -0700
Re: Early mainframe security Thomas Koenig <tkoenig@netcologne.de> - 2020-06-30 07:57 +0000
Re: Early mainframe security "Kerr-Mudd,John" <notsaying@invalid.org> - 2020-06-30 08:21 +0000
Re: Early mainframe security Douglas Miller <durgadas311@gmail.com> - 2020-06-29 13:55 -0700
Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-29 17:40 -0400
Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-06-30 00:08 +0000
Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 07:38 -0700
Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-01 15:14 +0000
Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 13:03 -0700
Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-02 00:52 +0000
Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-11 18:04 -0700
Re: Early mainframe security Grant Taylor <gtaylor@tnetconsulting.net> - 2020-07-11 19:10 -0600
Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-07-12 02:50 +0000
Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-13 14:26 -0700
Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-29 23:00 +0100
Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-30 00:27 +0000
Re: Early mainframe security and channel programs John Levine <johnl@taugh.com> - 2020-06-30 02:58 +0000
Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 11:34 +0100
Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-30 06:15 -0700
Re: Early mainframe security antispam@math.uni.wroc.pl - 2020-06-30 14:01 +0000
Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 22:39 +0100
Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-06-30 19:37 -0500
Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-06-29 22:18 +0000
Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-29 15:49 -0700
Re: Early mainframe security Grant Taylor <gtaylor@tnetconsulting.net> - 2020-06-29 18:28 -0600
Re: Early mainframe security Quadibloc <jsavard@ecn.ab.ca> - 2020-06-29 21:11 -0700
Re: Early mainframe security David Wade <g4ugm@dave.invalid> - 2020-06-30 11:35 +0100
Re: Early mainframe security Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-06-30 22:18 +0000
Re: Early mainframe security scott@slp53.sl.home (Scott Lurndal) - 2020-07-01 15:08 +0000
Re: Early mainframe security Thomas Koenig <tkoenig@netcologne.de> - 2020-06-30 07:51 +0000
Re: Early mainframe security Bob Eager <news0073@eager.cx> - 2020-06-30 08:49 +0000
Re: Early mainframe security Ahem A Rivet's Shot <steveo@eircom.net> - 2020-06-30 09:43 +0100
Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-06-30 19:23 -0500
Re: Early mainframe security Peter Flass <peter_flass@yahoo.com> - 2020-06-30 18:03 -0700
Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-30 22:32 -0400
Re: Early mainframe security John Levine <johnl@taugh.com> - 2020-07-01 03:21 +0000
Re: Early mainframe security J. Clarke <jclarke.873638@gmail.com> - 2020-06-30 23:52 -0400
Re: Early mainframe security Dan Espen <dan1espen@gmail.com> - 2020-06-30 23:56 -0400
Re: Early mainframe security Jon Elson <elson@pico-systems.com> - 2020-07-01 22:21 -0500
Re: Early mainframe security timcaffrey420@gmail.com - 2020-07-01 07:33 -0700
Re: Early mainframe security Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-03 12:25 -1000
Re: Early mainframe security Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-03 12:58 -1000
csiph-web