RE: Meltdown and spectre

  • From: "Reen, Elizabeth " <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "elizabeth.reen" for DMARC)
  • To: "'tim.evdbt@xxxxxxxxx'" <tim.evdbt@xxxxxxxxx>, "'ORACLE-L'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 5 Jan 2018 21:33:18 +0000

            I have a background in system engineering.  I don’t get how a chip 
can be exploited.  What code can be hacked there?  And if this is a chip 
problem, why aren’t we seeing a firmware fix?  Why are the O/S manufacturers 
putting out the fixes?

            Please note, I did not say I was not going to patch my Prods.  I’m 
thinking about not patching my devs.  I can see a financial impact here if I 
lose 50% of my computing power. The manufacturers can give me free hardware, is 
Oracle going to give me free licenses?


Liz


From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Tim Gorman
Sent: Friday, January 05, 2018 12:45 PM
To: 'ORACLE-L'
Subject: Re: Meltdown and spectre

Elizabeth,

Looking at this in terms of a RACI diagram, the HW vendors, HW resellers, and 
your organization's security team are accountable, sysadmin teams are 
responsible and consulted, and everyone else is informed.

I suspect that, in the end, most organizations are going to hold the HW 
resellers/vendors financially responsible.  Significant loss of productivity 
due to these bugs are likely to result in demands for free HW as compensation, 
resulting in a chain of lawsuits that roll recursively from HW resellers to HW 
vendors back to Intel.

Meltdown and Spectre are not Linux bugs;  they are Intel bugs, which means that 
any OS running on Intel is exposed.  Linux and other OS's running on Power, 
SPARC, or PA-RISC do not seem to be affected, though I suspect the jury might 
still be out on anything running in Itanium (i.e. Linux, HP-UX, Windows, etc)?

Hope this helps...

-Tim

On 1/5/18 10:06, Reen, Elizabeth (Redacted sender elizabeth.reen for DMARC) 
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
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mark W. Farnham
Sent: Friday, January 05, 2018 8:38 AM
To: niall.litchfield@xxxxxxxxx<mailto:niall.litchfield@xxxxxxxxx>; 
andrew.kerber@xxxxxxxxx<mailto: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
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Niall Litchfield
Sent: Thursday, January 04, 2018 10:58 AM
To: andrew.kerber@xxxxxxxxx<mailto: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<mailto: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<mailto: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=>

Other related posts: