RE: Meltdown and spectre

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <rajendra.pande@xxxxxxx>, <knecht.stefan@xxxxxxxxx>, <dmarc-noreply@xxxxxxxxxxxxx>
  • Date: Mon, 8 Jan 2018 09:33:16 -0500

The most likely result being security risk will dominate decisions, 
architectural topology will be ignored, and the CPU chewing patch will be 
applied to each component that represents risk as if it were itself exposed 
directly to external attack in a multi-user environment.

 

Instead of bounds checking memory versus rights in speculations before 
presumptive cache writing is done…

 

/cynicism warning on: After an initial dip, the resulting extra CPUs sold to 
replace lot cycles will push Intel stock through the roof and likewise Oracle 
for licensing the extra CPUs on premise or through competing cloud operations. 
/cynicism warning off

 

From: rajendra.pande@xxxxxxx [mailto:rajendra.pande@xxxxxxx] ;
Sent: Monday, January 08, 2018 8:10 AM
To: knecht.stefan@xxxxxxxxx; dmarc-noreply@xxxxxxxxxxxxx
Cc: tim@xxxxxxxxxxxxxxx; andrew.kerber@xxxxxxxxx; mwf@xxxxxxxx; 
oracle-l@xxxxxxxxxxxxx; fmhabash@xxxxxxxxx; niall.litchfield@xxxxxxxxx
Subject: RE: Meltdown and spectre

 

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  (Office) 

Service Now Group: CPB-ORACLE-DB-SUPPORT

 

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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://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=>
 
https://www.reuters.com/article/us-cyber-intel-researcher/how-a-researcher-hacked-his-own-computer-and-found-worst-chip-flaw-idUSKBN1ET1ZR
 

 

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx] 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@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

Other related posts: