> On 2020-11-17, at 10:21:10, Binyamin Dissen wrote:
>
> On Tue, 17 Nov 2020 13:58:23 + Seymour J Metz wrote:
>
> :>Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK
> IBM has cleaned up all such abominations, and the binder does not allow you
> to create a load
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
On Tue, 17 Nov 2020 13:58:23 + Seymour J Metz wrote:
:>Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK
IBM has cleaned up all such abominations, and the binder does not allow
ble.
You are asserting that RENT now forces REFR?
:>
:>From: IBM Mainframe Assembler List on
behalf of Binyamin Dissen
:>Sent: Tuesday, November 17, 2020 2:35 AM
:>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
:>Subject: Re: security with storage all
dely known in the
hacker community compared to the Intel or ARM architectures.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of ste...@copper.net
Sent: Tuesday, November 17, 2020 10:40 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation
Mainframe Assembler List on behalf
of Tony Harminc
Sent: Monday, November 16, 2020 4:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
On Mon, 16 Nov 2020 at 12:24, Ze'ev Atlas
<01774d97d104-dmarc-requ...@listserv.uga.edu> wrote:
>
&
, 2020 4:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
On Mon, 16 Nov 2020 at 12:24, Ze'ev Atlas
<01774d97d104-dmarc-requ...@listserv.uga.edu> wrote:
>
> Hi allIn the 1970's I probably could have done some getmain, wri
of Farley, Peter x23353 <0dc9d8785c29-dmarc-requ...@listserv.uga.edu>
Sent: Monday, November 16, 2020 4:45 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
It is not necessary to getmain storage in which to run a dynamically created
progr
From: IBM Mainframe Assembler List on behalf
of Binyamin Dissen
Sent: Tuesday, November 17, 2020 2:35 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
On Mon, 16 Nov 2020 18:35:29 -0700 Paul Gilmartin
; From: "Ngan, Robert"
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 11/17/2020 02:03 AM
> Subject: Re: security with storage allocation under z.OS
> Sent by: "IBM Mainframe Assembler List"
>
> I found out the hard way that, if you code EXECUTAB
On Mon, 16 Nov 2020 18:35:29 -0700 Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
:>On 2020-11-16, at 17:47:10, Dan Greiner wrote:
:>> ...
:>> So, the facility only applies to virtual addresses on newer models. As I
recall, the development of this facility was
014e0e4a59b-dmarc-requ...@listserv.uga.edu>
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 11/17/2020 02:16 AM
> Subject: Re: security with storage allocation under z.OS
> Sent by: "IBM Mainframe Assembler List"
> Conversely, there's REFRPROT to prevent storing into programs
>
IBM Corp.
Poughkeepsie NY
"IBM Mainframe Assembler List" wrote on
11/16/2020 05:29:02 PM:
> From: "Ngan, Robert"
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 11/17/2020 02:03 AM
> Subject: Re: security with storage allocation under z.OS
> Sent by: "IBM
That make sense, as I am competing with the Linux develipers. I consider
implementing a simple model, befiting native z/OS, with option to implement the
security model when it becomes ubiquitous. I really thank you for the
information, as it gives me the basic answer to my question and
On 2020-11-16, at 17:47:10, Dan Greiner wrote:
> ...
> So, the facility only applies to virtual addresses on newer models. As I
> recall, the development of this facility was requested by z/Linux in order to
> help avoid classic stack-overflow exposures; but, it obviously has
>
The ability to prevent instruction execution was introduced by the
instruction-execution-protection (IEP) facility on the z14 (September 2017).
Per the facility blurb in Chapter 1 of the PoO:
"The instruction-execution-protection facility may be available on a model
implementing
-
From: IBM Mainframe Assembler List On Behalf
Of Steve Smith
Sent: Monday, November 16, 2020 11:39
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default is YES, and
for earlier releases
Technologies
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Steve Smith
Sent: Monday, November 16, 2020 11:39
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default
--Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Binyamin Dissen
Sent: Monday, November 16, 2020 1:58 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
Why would anything break? How would t
it could be induced to
modify maliciously.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Harminc
Sent: Monday, November 16, 2020 1:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation
Why would anything break? How would that be any different from the same code
being in your module?
On Mon, 16 Nov 2020 20:32:24 + Ze'ev Atlas
<01774d97d104-dmarc-requ...@listserv.uga.edu> wrote:
:>I am pretty certain that something would break. My question was to guide me
to where the
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: security with storage allocation under z.OS
Hi allIn the 1970's I probably could have done some getmain, write some code
into that obtained memory and jump to that code. I assume that nowadays, this
would be impossible and there is some security model to prevent
On Mon, 16 Nov 2020 at 12:24, Ze'ev Atlas
<01774d97d104-dmarc-requ...@listserv.uga.edu> wrote:
>
> Hi allIn the 1970's I probably could have done some getmain, write some code
> into that obtained memory and jump to that code. I assume that nowadays, this
> would be impossible and there is
equ...@listserv.uga.edu>
Sent: Monday, November 16, 2020 12:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: security with storage allocation under z.OS
Hi allIn the 1970's I probably could have done some getmain, write some code
into that obtained memory and jump to that code. I assume that no
ber 16, 2020 12:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: security with storage allocation under z.OS
Hi allIn the 1970's I probably could have done some getmain, write some code
into that obtained memory and jump to that code. I assume that nowadays, this
would be impossible and there i
And curiously the facility is present for STORAGE OBTAIN and ISRV64 but not for
IARCP64.
Sent from my iPhone
> On Nov 16, 2020, at 12:39 PM, Steve Smith wrote:
>
> There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default is YES,
> and for earlier releases there was no
There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default is YES,
and for earlier releases there was no execute-prevention capability afaik.
I don't know what to tell you about the "security model". It's a big
subject.
sas
On Mon, Nov 16, 2020 at 12:24 PM Ze'ev Atlas <
That is not impossible and used in many products for performance reasons, such
as sorting.
Sent from my iPhone
> On Nov 16, 2020, at 12:24 PM, Ze'ev Atlas
> <01774d97d104-dmarc-requ...@listserv.uga.edu> wrote:
>
> Hi allIn the 1970's I probably could have done some getmain, write some
Hi allIn the 1970's I probably could have done some getmain, write some code
into that obtained memory and jump to that code. I assume that nowadays, this
would be impossible and there is some security model to prevent such a security
breach.Do you know where can I find information on the
28 matches
Mail list logo
