🚀 go-pugleaf

"Duke Arber" <duke_arber@yahoo.com> wrote in message
news:b4ieak$2qn$1@slb9.atl.mindspring.net...
> I'm working on porting a cryptographic library to IBM's MVS (aka. OS/390
and
> z/OS) operating system.  One of the tasks is gathering data with
sufficient
> entropy for seeding the libraries PRNG (Pseudo Random Number Generator).
It
> requires about 1-4K of data.
>
> The programs using the library are running in a non-authorized state (not
> APF authorized).  This requirement has made it difficult to find any data
> from within the address space that has sufficient entropy.  A
non-authorized
> address space does not have access to any system-wide counters.
>
> The address spaces will be started at system boot time (IPL time) and on
> request throughout the life of an IPL.  Please keep in mind that the IPL
> sequence is the same every time and often MVS systems have an IPL schedule
> to accommodate testing periods (e.g. IPL occurs every Sunday at 3:00 AM).
>
> Does anyone know of data sources on MVS available to non-authorized
programs
> with sufficient entropy for seeding PRNGs?
>
> Thanks in advance.
>

How accurately can you measure time?

Read the time and date.  Reschedule so the operating system
runs and read the time when you are reactivated.  The
entropy comes from the run time of the other programs and
the date.  You may be able to play games with the disks and
operator reply times.

Andrew Swallow

"Duke Arber" <duke_arber@yahoo.com> writes:
> Does anyone know of data sources on MVS available to non-authorized programs
> with sufficient entropy for seeding PRNGs?

That means you're running on a virtual machine, right?  There's no
entropy at all.  Well, maybe you can sample a CPU cycle counter over a
long period or something like that.  There could be some entropy there
because of how other VM's on the same physical machine cause your
program to have more or less cache hits and misses.

> That means you're running on a virtual machine, right?  There's no
> entropy at all.  Well, maybe you can sample a CPU cycle counter over a
> long period or something like that.  There could be some entropy there
> because of how other VM's on the same physical machine cause your
> program to have more or less cache hits and misses.

MVS can run as a guest O/S on IBM's VM O/S or it can run as the only O/S.
The most likely case is running as the only O/S.

>
> How accurately can you measure time?
>
> Read the time and date.  Reschedule so the operating system
> runs and read the time when you are reactivated.  The
> entropy comes from the run time of the other programs and
> the date.  You may be able to play games with the disks and
> operator reply times.
>
> Andrew Swallow
>

The hardware clock resolution depends on the actual hardware model.  The
Time-Of-Day (TOD) API returns a microsecond resolution.  I think it's "safe
to say" that most of the models produced in the last 5 years have <=20
microsecond resolution.  Others in the IBM-MAIN newsgroup may be able to
fill in the details.

Basically, use the current O/S activity rate as a basis for entropy.  Hand
off control back to the O/S and depending on its activity, it will hand
control back in some period of time.  During an IPL, there is a lot of
activity.  During other periods of the day, there may be very little.  Would
this hold up during periods of low activity?

"Duke Arber" <duke_arber@yahoo.com> wrote in message
news:b4ihfk$4oh$1@slb0.atl.mindspring.net...
> >
> > How accurately can you measure time?
> >
> > Read the time and date.  Reschedule so the operating system
> > runs and read the time when you are reactivated.  The
> > entropy comes from the run time of the other programs and
> > the date.  You may be able to play games with the disks and
> > operator reply times.
> >
> > Andrew Swallow
> >
>
> The hardware clock resolution depends on the actual hardware model.  The
> Time-Of-Day (TOD) API returns a microsecond resolution.  I think it's
"safe
> to say" that most of the models produced in the last 5 years have <=20
> microsecond resolution.  Others in the IBM-MAIN newsgroup may be able to
> fill in the details.
>
> Basically, use the current O/S activity rate as a basis for entropy.  Hand
> off control back to the O/S and depending on its activity, it will hand
> control back in some period of time.  During an IPL, there is a lot of
> activity.  During other periods of the day, there may be very little.
Would
> this hold up during periods of low activity?
>
If the crypto program is the only one running the time delays
will be very similar making the values guessable.  This gives
low entropy.  Where there is a complicated mixture of programs
running the delay on a low priority program becomes
unpredictable producing lots of entropy.

Disk reads and writes, when the program waits until the
peripheral has completely finished, gains entropy from
several places.  First the random speed variations that all
motors have, second the variable distance between the
current location of the head and the required sector (assuming
that the disk is already run up) and third disk activity due to
other programs.

On PCs other measures such as amount of disk and
ram being used are also used as a source of entropy
by some web browsers.

Fitting a proper random number generator to the
computer would be a better source for random data.
If one is not made for your mainframe, buying a
PC random number generator module and fitting it
into a dedicated PC is a cheap way of making one.

Andrew Swallow

Hi Duke,

I haven't  played with IBM mainframes for quite some time, but I had a
similar problem many years ago.  The entity I settled on was derived from
the 8 byte TOD clock - but I reversed the BYTES not the bits.  As you know,
the high order byte of the TOD clock changes least quickly, while the low
order byte of the TOD clock changes most quickly.  From (dim) memory, the
(32 bit) code went something like

; get TOD into my memory
      SVC ???,TODF
      ICM R4,1,TODF
      ICM R4,2,TODF+1
      ICM R4,4,TODF+2
      ICM R4,8,TODF+3
      ICM R5,1,TODF+4      ; note adjacent register
      ICM R5,2,TODF+5
      ICM R5,4,TODF+6
      ICM R5,8,TODF+7
      STM R4,R5,TODR

TODF DS 1D    ; TOD Forwards
TODR DS 1D    ;TOD Reverse

I can't remember the exact format of the ICM instruction (does the mask come
first?).  I can't remember the exact SVC call to get the eight byte TOD
either.  What I do remember is that the results were more accurate than the
documentation described.

Bob

Duke,

The gettimeofday() function or a direct equivalent doesn't seem
to exist on OS/390 C like it does on Unix.

I have used an exclusive-or combination of time(), getpid() and the .tms_utime,
.tms_cutime, and .tms_cstime values returned by the times() function
as a source of entropy on OS/390.  Its hardly perfect, but it was good enough
for what I wanted.

Glenn.

Duke Arber wrote:

> >
> > How accurately can you measure time?
> >
> > Read the time and date.  Reschedule so the operating system
> > runs and read the time when you are reactivated.  The
> > entropy comes from the run time of the other programs and
> > the date.  You may be able to play games with the disks and
> > operator reply times.
> >
> > Andrew Swallow
> >
>
> The hardware clock resolution depends on the actual hardware model.  The
> Time-Of-Day (TOD) API returns a microsecond resolution.  I think it's "safe
> to say" that most of the models produced in the last 5 years have <=20
> microsecond resolution.  Others in the IBM-MAIN newsgroup may be able to
> fill in the details.
>
> Basically, use the current O/S activity rate as a basis for entropy.  Hand
> off control back to the O/S and depending on its activity, it will hand
> control back in some period of time.  During an IPL, there is a lot of
> activity.  During other periods of the day, there may be very little.  Would
> this hold up during periods of low activity?

Duke Arber wrote:
>>That means you're running on a virtual machine, right?  There's no
>>entropy at all.  Well, maybe you can sample a CPU cycle counter over a
>>long period or something like that.  There could be some entropy there
>>because of how other VM's on the same physical machine cause your
>>program to have more or less cache hits and misses.
> 
> 
> MVS can run as a guest O/S on IBM's VM O/S or it can run as the only O/S.
> The most likely case is running as the only O/S.

   The STCK instruction retrieves the actual system clock whether or not 
MVS is running under VM.
   You can use the STIMER macro to request an IRB be scheduled. Code 
running under the IRB can inspect the register contents of the 
interrupted PRB (although IIRC, the IRB is postponed if an SVRB is in 
progress).
   You can step through LPA, hoping for a page fault that would make the 
difference between STCK values less predictable. A fair amount of CSA is 
fetchable, and if it isn't there's some variance to be had in the time 
it takes to dispatch your ESTAE routine.
   I don't recall offhand if the trace table in the nucleus is fetch 
protected. It probably is.
   ENQing on a global resource can get you some variance in the time it 
takes for the token to pass through the various channel-to-channel adapters.

--Mike Amling

Bob wrote:
> Hi Duke,
> 
> I haven't  played with IBM mainframes for quite some time, but I had a
> similar problem many years ago.  The entity I settled on was derived from
> the 8 byte TOD clock - but I reversed the BYTES not the bits.  As you know,
> the high order byte of the TOD clock changes least quickly, while the low
> order byte of the TOD clock changes most quickly.  From (dim) memory, the
> (32 bit) code went something like
> 
> ; get TOD into my memory
>       SVC ???,TODF
>       ICM R4,1,TODF
>       ICM R4,2,TODF+1
>       ICM R4,4,TODF+2
>       ICM R4,8,TODF+3
>       ICM R5,1,TODF+4      ; note adjacent register
>       ICM R5,2,TODF+5
>       ICM R5,4,TODF+6
>       ICM R5,8,TODF+7
>       STM R4,R5,TODR
> 
> TODF DS 1D    ; TOD Forwards
> TODR DS 1D    ;TOD Reverse
> 
> I can't remember the exact format of the ICM instruction (does the mask come
> first?).  I can't remember the exact SVC call to get the eight byte TOD
> either.  What I do remember is that the results were more accurate than the
> documentation described.

   Your ICMs are OK. The register is first (as with L and ST). The 
8-byte TOD clock is available from the unprivileged STCK instruction 
(although it's also one of the formats you can ask for from the TIMER SVC).
   What's the advantage of reversing the order?

--Mike Amling