Here are the latest advisories from IBM, published/updated within the past
couple hours as I write this:
https://www.ibm.com/blogs/psirt/potential-cpu-security-issue/
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
---
Yes, please contact "your friendly IBM representative" before you attempt
to run JZOS (or any portion thereof) on something other than a licensed
z/OS instance. That goes for anything and everything that's part of z/OS,
or any other licensed software product for that matter. Unless there's
somethin
Got an acknowledgement post from syszsec today.
– Vignesh
Mainframe Infrastructure
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: 05 January 2018 06:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw
O
On Thu, 4 Jan 2018 05:07:03 -0600, Elardus Engelbrecht wrote:
>
>Now, those algorithms are exploited. Basically, you load a 'fetch protected'
>address and then use/mis-use 'out of order execution' and 'speculative
>execution' while messing around with the contents of CPU caches.
>
>Long story, b
I think I out-clevered myself. x'' is the highest numbered device, but
since x'' is also a valid device number, the total number is 65,536 UCBs.
In any case, we need to go beyond that limit in a single LPAR. It's only
temporary, but the alternative is drawn out and laborious.
1. Identi
Yes. 65,535 is the maximum number of devices that can be represented with four
hex digits. If you add one more device, you need an extra hex digit. I
understand that channel sets can allow for more than 64K UCBs in an IODF, but I
thought that no single LPAR could address all of them at the same
Ah, UCB's are HEX, so x'' = 65535, correct?
Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 6:20 PM
To:
So this would involve 5-digit UCBs? We could probably manage that as long as
all devices are concurrently accessible. Aren't commands like VARY limited to
four digits?
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595
On 18Jan04:1432-0800, Charles Mills wrote:
> On 18Jan04:1406-0500, David L. Craig wrote:
>
> > On 18Jan04:1603-0600, Dana Mitchell wrote:
> >
> > > I assume IBM will soon patch any Intel based HMC's and SE's.
> >
> > Why? Theoretically nothing can get in there to attempt any mischief.
>
> You
By using the CSSID/SS* in the IODF you can get way more than the
basic number
Example from a z13
CSS Devices in SS0Devices in SS1Devices in SS2Devices
in SS3
/ ID Maximum + Actual Maximum + Actual Maximum + Actual Maximum
+ Actual
_ 0 65280 12384 65535 0
I missed the mark a little with, "z/OS 1.19"
LOL, I meant z/OS 1.9. I don't believe a z/OS 1.19 will ever see the light of
day.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.u
1.19?
On Thu, Jan 4, 2018 at 5:36 PM, Adam Johanson
wrote:
> John, you mentioned:
>
>
> Of course, this is a lot of "overhead" and would
> likely cause upper level management to explode in rage and force me to put
> it in key 8 CSA unencrypted for "ease of use".
>
>
> This wouldn't work indefi
rt.citrix.com/article/CTX231399> January 4, 2018
F5 <https://support.f5.com/csp/article/K91229003> January 4, 2018
Google
<https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html>
January
4, 2018
Huawei
<http://www.huawei.com/en/psirt/security-notices/hua
We would like to be able to access >65535 device addresses (UCBs) from a single
LPAR via a single IODF. The need is for bringing a new DASD subsystem online
while retaining the old subsystem until all volumes can be copied across. We
currently have spare UCBs available, but not enough to have al
John, you mentioned:
Of course, this is a lot of "overhead" and would
likely cause upper level management to explode in rage and force me to put
it in key 8 CSA unencrypted for "ease of use".
This wouldn't work indefinitely, as the Announcement for z/OS 2.3 indicated
that 2.3 will be the last
Dana Mitchell wrote:
>Rex, anything that touches cardholder data is in scope:
True, unless the data is encrypted in the actual terminal (the swipey part), as
it might be with Voltage SecureData. The POS terminal would then never touch
actual card data, and thus be out of scope.
Or maybe they h
You don't think like an auditor LOL.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David L. Craig
Sent: Thursday, January 4, 2018 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Intel Chip flaw
On 18Jan04:1603-0600, Dana
On 18Jan04:1603-0600, Dana Mitchell wrote:
> I assume IBM will soon patch any Intel based HMC's and SE's.
Why? Theoretically nothing can get in there to attempt
any mischief.
--
May the LORD God bless you exceedingly abundantly!
Dave_Craig__
"So the
I assume IBM will soon patch any Intel based HMC's and SE's.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Rex, anything that touches cardholder data is in scope:
The PCI DSS security requirements apply to all system components included in or
connected
to the cardholder data environment. The cardholder data environment (CDE) is
comprised of
people, processes, and technologies that store, process, or
Dana,
I'm asking this more out of ignorance than anything else. Would the front-end
terminal need to specifically comply with PCI if it is merely a data entry
device and isn't actually storing any information? Not knowing how Walmart's
systems are set up, if the XP machine and scanner are har
I wasn't concerned about legal issues at all. I was (until now!) only
wondering if the JZOS facilities that allow this actually require a z/OS
environment to even work. Though now that I think about it, perhaps we could
use JZOS to translate the vendor data to data that is easier to deal with
The data is generated on the vendors mainframe and transmitted to us. From the
time we get it we'd like to be able to "process" the data (most likely placing
it in an Oracle database) without the need for z/OS on our side.
From: IBM Mainframe Discussion List on
Kolusu, I ran these statements and found the job to be incredibly fast. I
added an INCLUDE COND statement to filter out only what I needed (based on
the IfThen statements at the top), and was able to process
a 21,403,200-record file to produce 1,633,601 output records in only 20
seconds!
I also do
How can that possibly pass PCI?
On Thu, 4 Jan 2018 12:17:41 -0800, Tom Brennan
wrote:
>Edward Finnell wrote:
>> ... Just for curiosity's sake I watched the self-serve terminal boot at
>> Walmart last night. Sure enough-powered by Intel/ Windows XP.
>
>That may actually be a benefit, assuming t
Edward Finnell wrote:
... Just for curiosity's sake I watched the self-serve terminal boot at Walmart
last night. Sure enough-powered by Intel/ Windows XP.
That may actually be a benefit, assuming the CPU is as old as XP and
perhaps not susceptible.
-
We'll have to see how it shakes out. Just from heuristic point of view it would
seem the z114/ZBX would have heightened exposure. But think about how pervasive
this is going to be. Peripherals to include printers, PC's, HMC, SE,routers and
switches. Then there's all the imbedded stuff. Just for
On Thu, Jan 4, 2018 at 12:26 PM, Charles Mills wrote:
> My very amateur reading of the paper is that it affects fetch-protected
> memory that is otherwise addressable by the intruder. So my wild guess is
> that it would affect fetch-protected common storage on any Z OS, but would
> not allow an i
My very amateur reading of the paper is that it affects fetch-protected memory
that is otherwise addressable by the intruder. So my wild guess is that it
would affect fetch-protected common storage on any Z OS, but would not allow an
intruder to read data in another address space. But my degree
On Thu, Jan 4, 2018 at 11:41 AM, Raja Mohan wrote:
> Redhat did confirm in their advisory that it impacts Linux on Z. we may have
> to wait on IBM to confirm if it impacts z/OS, z/VM and z/VSE
>
IBM, if it finds it, will only issue a patch without details.
--
Mike A Schwab, Springfield IL USA
W
Redhat did confirm in their advisory that it impacts Linux on Z. we may have to
wait on IBM to confirm if it impacts z/OS, z/VM and z/VSE
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@l
On 18Jan04:1030-0600, Tom Marchant wrote:
> On Thu, 4 Jan 2018 04:11:22 -0600, Cannaerts, Jan wrote:
>
> >This article:
> >https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
> >
> >Mentions the following:
> >
> >> Additional exploits for other architectures ar
Back to the beginning. Way back in the late 1970's US corporate bosses
(elites) changed their plans from advancing their business to advancing
their personal wealth. The education classes that corps offered
disappeared as I well remember. Free trade agreements helped the bottom
line, but made no
> you'd fetch protect what you didn't want fetched
You might just fetch protect on GP. I cache data in common storage that is
of fairly low "exploit value" but I fetch protect it because I can with
little trouble (and to possibly make prospects with checklists happy).
Charles
-Original Mess
I don't see the reference to System Z in the article. Am I missing something?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cannaerts, Jan
Sent: Thursday, January 4, 2018 2:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: In
On Thu, 4 Jan 2018 04:11:22 -0600, Cannaerts, Jan wrote:
>This article:
>https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
>
>Mentions the following:
>
>> Additional exploits for other architectures are also known to exist. These
>> include IBM System Z, POWE
Wow... what a writeup! I'll never understand even 1% of it. What I did
learn so far is that when you find something like this, you need to make
up cool names like Spectre and Meltdown.
Cannaerts, Jan wrote:
This article:
https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memor
NB: I do not speak for IBM on licensing issues on this. at all.
The JZOS Record Generator is not part of the z/OS SDK, but it does include
the runtime classes (com.ibm.jzos.fields).
It is available free to z/OS users. See:
https://www.ibm.com/support/knowledgecenter/SSMQ4D_3.0.0/documentation/w
On Thu, Jan 4, 2018 at 7:30 AM, Kirk Wolf wrote:
> The com.ibm.jzos.fields package supports binary, packed, zoned, and HFP
> data and will run on non-z/OS Java platforms.
> When running on z/OS, some of the converters will use "data access
> acceleration" primitives to speed things up, but otherw
The com.ibm.jzos.fields package supports binary, packed, zoned, and HFP
data and will run on non-z/OS Java platforms.
When running on z/OS, some of the converters will use "data access
acceleration" primitives to speed things up, but otherwise the code is just
Java.
Kirk Wolf
Dovetailed Technologi
What I understood is, that Linux, Windows and Apple OS's are vulnerable. The
leak is in the way memory areas of different tasks are isloated from each
other. I doubt that zSystems / zArchitecture are vulnerable to this bug.
Kees.
> -Original Message-
> From: IBM Mainframe Discussion Lis
On Thu, Jan 4, 2018 at 12:01 AM, Timothy Sipples wrote:
> Frank Swarbrick wrote:
> >We're also interested in any solution NOT requiring z/OS.
>
> I understand IBM is working on data teleportation, or what some people call
> the "psychic engine." This technology will be able to read the "minds" of
Hi
Cross Posted
Good morning
Has any attempted to convert the BDT NJE to TCPIP NJE ?
Any document or manual which was followed to achieve this migration would
be of great help me to research.
We are still using JES3.
Regards
Jake
--
This is interesting. And I've been following some of the discussion over on
"Vulture Central",
http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/
. But as I understand it, this is a hardware bug on Intel. And there is no
indication that the IBMZ architect
Martin Packer wrote:
>Surely the term "fetch-protected" says it all: In principle you'd fetch
>protect what you didn't want fetched. :-) Now, I don't know if there is any
>overhead to fetch protection that might cause you not to fetch protect what
>should be.
This is the problem just there. 'f
Surely the term "fetch-protected" says it all: In principle you'd fetch
protect what you didn't want fetched. :-) Now, I don't know if there is
any overhead to fetch protection that might cause you not to fetch protect
what should be.
Cheers, Martin
Martin Packer
zChampion, Systems Investigat
This article:
https://googleprojectzero.blogspot.be/2018/01/reading-privileged-memory-with-side.html
Mentions the following:
> Additional exploits for other architectures are also known to exist. These
> include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9
> (Little Endian).
47 matches
Mail list logo
