Re: Meltdown and spectre

  • From: Tim Gorman <tim.evdbt@xxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Mon, 8 Jan 2018 08:18:21 -0700

Regarding Intel stock prices, this problem should be widespread enough to trigger cascading lawsuits to hold Intel ultimately responsible.  At least, we can hope so?

If so, it is likely that Intel has already set aside funds internally to settle these lawsuits, and the impact on profits will likely keep stock prices from increasing in the near term.  This impact might be exacerbated if any suits succeed over the long term.  Another side-effect might be price reductions, perhaps as high as 100%, on affected chips for certain customers.

Intel might make money from this debacle, but it is more likely to lose.  Since Intel is a near-monopoly, this will ultimately result in price increases, but not necessarily stock price increases. Intel does not want to trigger a monopoly investigation from the US DOJ.

Just my US$0.02...

On 1/8/18 07:33, Mark W. Farnham wrote:

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 <mailto:dmarc-noreply@xxxxxxxxxxxxx>
*Cc:* tim@xxxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxxx>; Pande, Rajendra; Andrew Kerber; Mark W. Farnham; oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>; fmhabash@xxxxxxxxx <mailto:fmhabash@xxxxxxxxx>; niall.litchfield@xxxxxxxxx <mailto: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:

"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:


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

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


Elizabeth Reen
CPB Database GroupManager
718.248.9930 (Office)


*From:*oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx> [mailto: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 <mailto:rajendra.pande@xxxxxxx>
*Cc:* Andrew Kerber; Mark W. Farnham; oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>; dmarc-noreply@xxxxxxxxxxxxx <mailto:dmarc-noreply@xxxxxxxxxxxxx>; fmhabash@xxxxxxxxx <mailto:fmhabash@xxxxxxxxx>; niall.litchfield@xxxxxxxxx <mailto:niall.litchfield@xxxxxxxxx>

*Subject:* RE: Meltdown and spectre

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

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


Tim... (On crappy phone)

On 5 Jan 2018 7:04 pm, <rajendra.pande@xxxxxxx <mailto: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 <>


*From:*oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx> [mailto: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 <mailto:dmarc-noreply@xxxxxxxxxxxxx>; fmh; niall.litchfield@xxxxxxxxx <mailto:niall.litchfield@xxxxxxxxx>; tim@xxxxxxxxxxxxxxx <mailto: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 <mailto: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?

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

    *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...



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

    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.


    <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
    *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.


    [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.


    Andrew W. Kerber

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

    Niall Litchfield
    Oracle DBA


Andrew W. Kerber

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

Please visit our website at <>
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 <> | Support our Indiegogo campaign at <> | @zztat_oracle

Other related posts: