Re: Meltdown and spectre

  • From: Andrew Kerber <andrew.kerber@xxxxxxxxx>
  • To: rajendra.pande@xxxxxxx
  • Date: Mon, 8 Jan 2018 09:36:05 -0600

IBM power series chips are affected.

On Mon, Jan 8, 2018 at 7:09 AM, <rajendra.pande@xxxxxxx> wrote:

Note that IBM main frame is not impacted unless you count a windows
console with a X86 architecture



I think there is a parallel similar to Android and Apple

If you control the entire eco system you decide all levels of control and
what sort of optimization will happen where

If you don't then everyone is sort of piggy backing to reduce their own
work and overhead

And thus you then get into a finger pointing and drawing of battle lines
on what belongs where and who owns and needs to fix it.

And depending on your individual philosophy you are bound to take/choose
sides



*From:* Stefan Knecht [mailto:knecht.stefan@xxxxxxxxx]
*Sent:* Friday, January 05, 2018 4:58 PM
*To:* dmarc-noreply@xxxxxxxxxxxxx
*Cc:* tim@xxxxxxxxxxxxxxx; Pande, Rajendra; Andrew Kerber; Mark W.
Farnham; oracle-l@xxxxxxxxxxxxx; fmhabash@xxxxxxxxx;
niall.litchfield@xxxxxxxxx
*Subject:* Re: Meltdown and spectre



I'm not a CPU engineer - but from my understanding, CPUs try to optimize
by "predicting" where they will need to jump to. And apparently that's
something that people can abuse.

The very first paragraph kind of has it all:

https://googleprojectzero.blogspot.com/

"We have discovered that CPU data cache timing can be abused to
efficiently leak information out of mis-speculated execution, leading to
(at worst) arbitrary virtual memory read vulnerabilities across local
security boundaries in various contexts."

The key being "mis-speculated". They apparently thought that it's a good
idea to execute something ahead of time, just in case we will need to
execute it. How no-one imagined the potential abuse is beyond me.

Also interesting to see Linus Torvald's response to all of this:
https://lkml.org/lkml/2018/1/3/797





Stefan





On Sat, Jan 6, 2018 at 4:34 AM, Reen, Elizabeth <
dmarc-noreply@xxxxxxxxxxxxx> wrote:

            All of that happens in the O/S not on the chip.  One does not
log into a processor.





Liz



Elizabeth Reen
CPB Database Group Manager
718.248.9930 <(718)%20248-9930>  (Office)

Service Now Group: CPB-ORACLE-DB-SUPPORT





*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org] *On Behalf Of *Tim Hall
*Sent:* Friday, January 05, 2018 4:06 PM
*To:* rajendra.pande@xxxxxxx
*Cc:* Andrew Kerber; Mark W. Farnham; oracle-l@xxxxxxxxxxxxx;
dmarc-noreply@xxxxxxxxxxxxx; fmhabash@xxxxxxxxx;
niall.litchfield@xxxxxxxxx


*Subject:* RE: Meltdown and spectre



According to this the RHEL fixes can be overridden if you need performance.



https://access.redhat.com/articles/3307751
<https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_articles_3307751&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=DefUibHP8mOarbcy_Sqc0vqq2lYmneEXAHlsUQivcb8&s=Ts69z7hsaaCuS9AcmtuVLi-4TXmIiEJGiIY3-U623JU&e=>



They say bare-metal and containers have similar overheads, but virtual
guests are likely to be hit harder...



Cheers



Tim... (On crappy phone)



On 5 Jan 2018 7:04 pm, <rajendra.pande@xxxxxxx> wrote:

The answer (ref meltdown) apparently is KAISER that has shown to be
effective against Meltdown and hence (I guess) updates to the OS



https://www.reuters.com/article/us-cyber-intel-
researcher/how-a-researcher-hacked-his-own-computer-and-
found-worst-chip-flaw-idUSKBN1ET1ZR
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.reuters.com_article_us-2Dcyber-2Dintel-2Dresearcher_how-2Da-2Dresearcher-2Dhacked-2Dhis-2Down-2Dcomputer-2Dand-2Dfound-2Dworst-2Dchip-2Dflaw-2DidUSKBN1ET1ZR&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=DefUibHP8mOarbcy_Sqc0vqq2lYmneEXAHlsUQivcb8&s=5gOzYaSHcG0HE_NGKyIdRbISTO3K7A2PXG2nwkleug0&e=>





*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org] *On Behalf Of *Andrew Kerber
*Sent:* Friday, January 05, 2018 1:58 PM
*To:* Mark W. Farnham
*Cc:* ORACLE-L; dmarc-noreply@xxxxxxxxxxxxx; fmh;
niall.litchfield@xxxxxxxxx; tim@xxxxxxxxxxxxxxx
*Subject:* Re: Meltdown and spectre



According to what i am reading Meltdown affects only Intel, but AMD is
affected by Spectre, as is Intel. And spectre may be a more difficult fix
in the long run.



On Fri, Jan 5, 2018 at 11:55 AM Mark W. Farnham <mwf@xxxxxxxx> wrote:

re: 2) was my question:



“So, will there be an “insecure” patch to skip the overhead and rely on
server access control?”

Follow-up: For all the millions of single user in fact intel based
systems, will there be “insecure” patches?

The point being, yes, you will have to do patches outside of lab machines
kept for particular vintage reasons.

Will you be forced to get the performance penalty?



*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org] *On Behalf Of *Tim Hall
*Sent:* Friday, January 05, 2018 12:18 PM
*To:* dmarc-noreply@xxxxxxxxxxxxx
*Cc:* mwf@xxxxxxxx; niall.litchfield@xxxxxxxxx; andrew.kerber@xxxxxxxxx;
fmh; ORACLE-L


*Subject:* Re: Meltdown and spectre



Does not compute.



1) This is a problem with Intel chips. It's not a problem with Linux. The
OS vendors are putting in patches to fix/mitigate issues so you don't have
to scrap your Intel servers and replace them with servers with AMD chips.



2) Do I need to patch my servers? So you are never going to patch your
kernel again? Ever? If you ever do, you will get these fixes. Good luck
with never patching stuff again...



Cheers



Tim...



On Fri, Jan 5, 2018 at 5:06 PM, Reen, Elizabeth <
dmarc-noreply@xxxxxxxxxxxxx> wrote:

            Since all of my servers are in house behind numerous
firewalls, do I need to patch everything?  The performance hit is going to
hurt.  Do I need to do that for dev and testing servers which run with
redacted data?  I could need to double the amount of servers I own.  Yes
they are cheap, but it adds up after a while.  What about licenses?  Will I
need to up them because I need more iron to do the same work?



            I agree that you can’t stop a fully prived account from
reading memory under this scenario.  It is a bad operating system that lets
this happen.  Given the say Linux was developed, it is easy for something
like this to sneak through.  Linux is a great o/s, but you get what you pay
for here.  The reason it is so popular is that it is so inexpensive.  This
is not an issue in AIX, Sparc, or HP/UX.  They cost money because they have
been designed and tested.  They did not start out life as an alternative to
windows.



            Wrapper on every syscall is probably the fastest fix.  It is
far from the best fix.  Hopefully they will put in the correct fix.



Liz



*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org] *On Behalf Of *Mark W. Farnham
*Sent:* Friday, January 05, 2018 8:38 AM
*To:* niall.litchfield@xxxxxxxxx; andrew.kerber@xxxxxxxxx
*Cc:* 'fmh'; 'ORACLE-L'
*Subject:* RE: Meltdown and spectre



This also poses what I think is a relevant question for folks who place
their physical RDBMS server(s) securely and only have privileged logons
anyway. (You really can’t stop a fully privileged account from viewing
memory or any other resources anyway and only in memory encryption can
frustrate that if a bad actor has gained a privileged access to a server.)



So, will there be an “insecure” patch to skip the overhead and rely on
server access control?



Then we can have a fresh round of the debate about whether “physical” or
“virtual” is faster with the playing field thus tilted significantly in
favor of “physical.”



I also wonder for “virtual” servers whether this could be merely a
“hypervisor” patch (which in ring security theory dating back to the 1970’s
could establish a memory address bounded area at the privileged account
layer (which should be a heckuva lot cheaper than a wrapper on every
“syscall.”)



DTSS is lookin’ pretty good right now. Still it was our own fault for not
explaining clearly to enough to management that 100 million (plus) copies
at $39.95 each was more than 12 copies at $10 million each. Sigh.



mwf



*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org <oracle-l-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Niall
Litchfield
*Sent:* Thursday, January 04, 2018 10:58 AM
*To:* andrew.kerber@xxxxxxxxx
*Cc:* fmh; ORACLE-L
*Subject:* Re: Meltdown and spectre



There absolutely should be an OEL patch for this - for the RH kernel
they'll probably take upstream - for UEK  I'd expect an Oracle patch. I'd
expect Oracle shops to be regression testing to determine the likely impact
on RDBMS (and java app for that matter) performance.



On Thu, Jan 4, 2018 at 3:40 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx>
wrote:

I was wondering the same thing. But I dont think its up to Oracle to patch
this, its going to be at the OS and firmware level.  But everything I read
says that its going be a huge performance hit, anywhere from 10-50%, and
the higher end will be on IO bound systems.



On Thu, Jan 4, 2018 at 9:33 AM, Fred Habash <fmhabash@xxxxxxxxx> wrote:

Checked Oracle security bulletins but didn't find anything related. Did
Oracle release an official statement for these vulnerabilities at least for
the RDBMS and OEL.



Thanks




--

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'





--

Niall Litchfield
Oracle DBA
http://www.orawin.info
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.orawin.info&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=Ent2QwI0UZIJhxZc_4tIFF6zE5BswrZloZ3PSouSC-s&s=tG0aJf6IYCqHy0hWApVNL3Fgpp7csC57ox5qflq6Org&e=>



--

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'



Please visit our website at
http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__financialservicesinc.ubs.com_wealth_E-2Dmaildisclaimer.html&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=DefUibHP8mOarbcy_Sqc0vqq2lYmneEXAHlsUQivcb8&s=Nt4EpbCt5o7Zw7ATaOlGCrtYlDrxT97Uey1C6LFQGJs&e=>
for important disclosures and information about our e-mail
policies. For your protection, please do not transmit orders
or instructions by e-mail or include account numbers, Social
Security numbers, credit card numbers, passwords, or other
personal information.





--

//

zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!

Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
| @zztat_oracle


Please visit our website at
http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
for important disclosures and information about our e-mail
policies. For your protection, please do not transmit orders
or instructions by e-mail or include account numbers, Social
Security numbers, credit card numbers, passwords, or other
personal information.




-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Other related posts: