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
I am not dismayed. REFRPROT works exactly the way I intended it to
work.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
"IBM Mainframe Assembler List" wrote on
11/16/2020 08:35:29 PM:
> From: "Paul Gilmartin"
That is correct, a subpool has 2 SPQEs - one for EXECUTABLE=YES,
and one for EXECUTEABLE=NO. In z/OS 2.3 and 2.4, we search
only the SPQE for the EXECUTABLE attribute that you specify
when releasing storage, In future release which follows
z/OS 2.4, release processing has been enhanced to
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
Ok, this is a piece of information in line of what i was looking for. Could
you please refer me to documentation about storage obtain and storage
releaseThank youZA
Sent from Yahoo Mail on Android
On Mon, Nov 16, 2020 at 5:29 PM, Ngan, Robert wrote: I found
out the hard way that, if
I found out the hard way that, if you code EXECUTABLE=YES of the STORAGE
OBTAIN, you must also code it on the associated STORAGE RELEASE.
Evidently, it's implemented as a subpool under the covers, so like subpool
getmains, you must have matching values on OBTAIN and RELEASE.
Robert Ngan
HCL
All programs except the IPL text, the nucleus and a few things like that are
of course loaded into "GETMAIN" storage. An across the board restriction on
executing in GETMAIN storage would not just break things, it would break
every thing. It would totally brick the box.
Charles
-Original
> If a program has a bug such that it treats part of its input data as a branch
> offset without validating it,
> then it is useful to have the normal kind of storage not allow execution.
Yes, and to help prevent a bad guy from sending a z/OS program some sort of
"message" -- perhaps a URL or
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
It is not necessary to getmain storage in which to run a dynamically created
program. I wrote a simple subroutine to retrieve the LE CAA address from R12
that can be stored in a COBOL WORKING-STORAGE area and executed very easily.
Sample code below.
You could copy this simple subroutine into
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
I am pretty certain that something would break. My question was to guide me to
where the security model is discussed, so I could code a valid and safe
application that actually does what I've described in a safe and compliant way.
ZA
Sent from Yahoo Mail on Android
On Mon, Nov 16, 2020 at
An across the board restriction would brek, e.g., LOADER.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Ze'ev Atlas <01774d97d104-dmarc-requ...@listserv.uga.edu>
Sent: Monday, November 16,
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
19 matches
Mail list logo
