Re: Meltdown and spectre

"X applied a fix for a defect, and the fix caused its products to not perform as promised, so Y was deprived of Z."

The technical aspects of a defect are unimportant given the existence of a fix.

Probably not too difficult to grasp, but you make a good point about Trump appointees...

On 1/8/18 15:25, John Thomas wrote:
> Possible. But what are the chances a senior court will grasp the
> technical aspects of the argument?
>
> On appeal, what is the chance that Trump appointees will understand
> any better, further up the chain?
>
> Just my 2 pence worth...
>
> Regards,
>
> JT
>
> On Mon, 8 Jan 2018 at 15:19 Tim Gorman <tim.evdbt_at_gmail.com
> <mailto:tim.evdbt_at_gmail.com>> wrote:
>
> 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_at_ubs.com <mailto:rajendra.pande_at_ubs.com>
>> [mailto:rajendra.pande_at_ubs.com]
>> *Sent:* Monday, January 08, 2018 8:10 AM
>> *To:* knecht.stefan_at_gmail.com <mailto:knecht.stefan_at_gmail.com>;
>> dmarc-noreply_at_freelists.org <mailto:dmarc-noreply_at_freelists.org>
>> *Cc:* tim_at_oracle-base.com <mailto:tim_at_oracle-base.com>;
>> andrew.kerber_at_gmail.com <mailto:andrew.kerber_at_gmail.com>;
>> mwf_at_rsiz.com <mailto:mwf_at_rsiz.com>; oracle-l_at_freelists.org
>> <mailto:oracle-l_at_freelists.org>; fmhabash_at_gmail.com
>> <mailto:fmhabash_at_gmail.com>; niall.litchfield_at_gmail.com
>> <mailto:niall.litchfield_at_gmail.com>
>> *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_at_gmail.com]
>> *Sent:* Friday, January 05, 2018 4:58 PM
>> *To:* dmarc-noreply_at_freelists.org
>> <mailto:dmarc-noreply_at_freelists.org>
>> *Cc:* tim_at_oracle-base.com <mailto:tim_at_oracle-base.com>; Pande,
>> Rajendra; Andrew Kerber; Mark W. Farnham; oracle-l_at_freelists.org
>> <mailto:oracle-l_at_freelists.org>; fmhabash_at_gmail.com
>> <mailto:fmhabash_at_gmail.com>; niall.litchfield_at_gmail.com
>> <mailto:niall.litchfield_at_gmail.com>
>> *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_at_freelists.org
>> <mailto:dmarc-noreply_at_freelists.org>> 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 GroupManager
>> 718.248.9930 (Office)
>>
>> Service Now Group: CPB-ORACLE-DB-SUPPORT
>>
>> *From:*oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>
>> [mailto:oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>] *On Behalf Of *Tim Hall
>> *Sent:* Friday, January 05, 2018 4:06 PM
>> *To:* rajendra.pande_at_ubs.com <mailto:rajendra.pande_at_ubs.com>
>> *Cc:* Andrew Kerber; Mark W. Farnham; oracle-l_at_freelists.org
>> <mailto:oracle-l_at_freelists.org>; dmarc-noreply_at_freelists.org
>> <mailto:dmarc-noreply_at_freelists.org>; fmhabash_at_gmail.com
>> <mailto:fmhabash_at_gmail.com>; niall.litchfield_at_gmail.com
>> <mailto:niall.litchfield_at_gmail.com>
>>
>>
>> *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_at_ubs.com
>> <mailto:rajendra.pande_at_ubs.com>> 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_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>
>> [mailto:oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>] *On Behalf Of *Andrew Kerber
>> *Sent:* Friday, January 05, 2018 1:58 PM
>> *To:* Mark W. Farnham
>> *Cc:* ORACLE-L; dmarc-noreply_at_freelists.org
>> <mailto:dmarc-noreply_at_freelists.org>; fmh;
>> niall.litchfield_at_gmail.com <mailto:niall.litchfield_at_gmail.com>;
>> tim_at_oracle-base.com <mailto:tim_at_oracle-base.com>
>> *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_at_rsiz.com
>> <mailto:mwf_at_rsiz.com>> 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_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>
>> [mailto:oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>] *On Behalf Of *Tim Hall
>> *Sent:* Friday, January 05, 2018 12:18 PM
>> *To:* dmarc-noreply_at_freelists.org
>> <mailto:dmarc-noreply_at_freelists.org>
>> *Cc:* mwf_at_rsiz.com <mailto:mwf_at_rsiz.com>;
>> niall.litchfield_at_gmail.com
>> <mailto:niall.litchfield_at_gmail.com>; andrew.kerber_at_gmail.com
>> <mailto:andrew.kerber_at_gmail.com>; 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_at_freelists.org
>> <mailto:dmarc-noreply_at_freelists.org>> 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>
>> [mailto: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
>> <mailto:niall.litchfield_at_gmail.com>; andrew.kerber_at_gmail.com
>> <mailto: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=>
>>
>> --
>>
>> 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 <http://zztat.net> | Support our Indiegogo
>> campaign at igg.me/at/zztat <http://igg.me/at/zztat> | _at_zztat_oracle
>>
>
>
>
> --
>
> Regards,
>
> John
>

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