Score:3

Server

Does z/OS enforce memory protection between processes of the same user?

bbarker

4/24/23, 2:48 PM

It is often pointed out that each user has their own (virtual) address space in in z/OS; this is said as if it is a good thing, and I suppose it is compared to real mode. But in most modern systems I'm used to most processes (or jobs, in z/OS parlance, I suppose) having their own address space. This Unix approach seems strictly more secure at first glance.

That said, I have heard it claimed that z/OS jobs also each get their own address space, but I haven't seen any official documentation for this. Of course, if a user can only run one job at a time (I haven't checked this), then certainly this would not be an issue. (Aside: Traditionally z/OS must have been used for batch processing, so that might be a reasonable assumption. But, it is 2021, and things have perhaps changed, so knowing about job limitations per user would be good to know about as well.)

129

0 + 0

virtual-memory

zos

Score:3

Server

Hogstrom

4/24/23, 4:50 PM

You first paragraph isn’t clear as it seems to be contradictory.

On IBM Z you have the hardware and then the operating system. The hardware has a set of features that allow for separate address spaces and the virtual storage of each is protected from other users accessing the data. There are some caveats as IBM Z hardware uses a storage protection key to further identify how storage is protected. The keys can range from 0 - 15 (F) and the keys below 8 are reserved for the OS. z/OS uses this feature such that problem state (user programs) run in Key 8 on z/OS. The hardware also allows a protection on storage so that some storage is readable by all address spaces (generally OS memory) and some are fetch protected meaning you have to have the right key to read the data. All in all its a fairly comprehensive set of capabilities.

On z/OS there are address spaces which have their own virtual memory which is independent and inaccessible (in a controlled way) from other processes. Address spaces can host a JOB (managed by JES) or a system task (Started Task), … in each address space there can be multiple threads of execution.

That said, all this complexity is based on z/OS being a shared model of system resources which is different than Linux. Linux locks their kernel down and controls access through system calls. This actually makes z/OS highly efficient but is also its achilles heel as when things go bad they can go bad for all processes.

the platform is quite secure engineered from the hardware and operating systems to protect data and access. That said, operating systems (all of them) are written by fallible people and any of them can be hacked. z/OS is probably more difficult more so that its not ubiquitous like Linux or Windows.

0 + 0

bbarker

4/24/23, 5:56 PM

Thanks for the informative answer - you went above and beyond, and I appreciate it, as info is not readily available. It sounds like there are two degrees of address separation: at the hardware level (for users), and at the OS level (for processes). Maybe I got it wrong. Also, I reread my question and I haven't spotted the contradiction, so if you could elaborate, that may help clarify the situation (and I will try to clarify my question).

Kevin McKenzie

4/24/23, 7:39 PM

@bbarker I think part of the problem is you don’t understand the process model. In z/OS, there are address spaces. Each job has its own address space. Each logged on user has their own address space, and a separate address space may be created when a user executes a command, or a task/thread may run in the same address space, depending. Started tasks(daemons, sort of) run in their own address spaces. Both the hardware and software enforce memory separation at different levels.

Kevin McKenzie

4/24/23, 7:45 PM

Within an address space, there are different sections of virtual memory. Some is common between all address spaces, so they all have the same view of the world. Access to that storage is controlled by storage keys. So at a hardware level, it’s enforced that a problem state process can see certain information, but not change it.

Kevin McKenzie

4/24/23, 7:47 PM

This is all documented; I’d suggest starting with the ABCs of System Programming, or, for the hardcore, the Principles of Operations.

bbarker

4/24/23, 9:52 PM

Great looking resrouces - in the ABCs, I found this quote " There is at least one address space for each job in progress and one address space for each user logged on through TSO/E." I think this may explain my confusion - it wasn't clear to me why a user would need an address space if processes have it already, but it seems to be referring not to the user per se, but the user's TSO/E session. Similar to (but probably very different from) a user's shell process in a Unix OS.

Hogstrom

4/25/23, 2:47 AM

@bbarker This was the section, " But in most modern systems I'm used to most processes (or jobs, in z/OS parlance, I suppose) having their own address space. This Unix approach seems strictly more secure at first glance." It was the "This Unix approach" portion as you probably have done the math in your head of how Unix does process and memory management.

Hogstrom

4/25/23, 2:51 AM

@bbarker In response to the comment on ABC's . The Address Space is the biggest container and in them you can fit many processes. So lots of address spaces means lots of separation. TSO is like a user logging in and using a shell. From there lots of processes / threads of execution are possible.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Does z/OS enforce memory protection between processes of the same user?

TH: z/OS บังคับใช้การป้องกันหน่วยความจำระหว่างกระบวนการของผู้ใช้คนเดียวกันหรือไม่

RO: z/OS impune protecția memoriei între procesele aceluiași utilizator?

RU: Применяет ли z/OS защиту памяти между процессами одного и того же пользователя?

VI: z/OS có thực thi bảo vệ bộ nhớ giữa các tiến trình của cùng một người dùng không?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.