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_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] *On Behalf Of *Mark W. Farnham
> *Sent:* Friday, January 05, 2018 8:38 AM
> *To:* niall.litchfield_at_gmail.com; andrew.kerber_at_gmail.com
> *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_at_freelists.org
> <mailto:oracle-l-bounce_at_freelists.org>
> [mailto:oracle-l-bounce_at_freelists.org] *On Behalf Of *Niall Litchfield
> *Sent:* Thursday, January 04, 2018 10:58 AM
> *To:* andrew.kerber_at_gmail.com <mailto:andrew.kerber_at_gmail.com>
> *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_at_gmail.com
> <mailto:andrew.kerber_at_gmail.com>> 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_at_gmail.com
> <mailto:fmhabash_at_gmail.com>> 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=>
>

--
http://www.freelists.org/webpage/oracle-l