Re: Meltdown and spectre

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> 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
> <rajendra.pande_at_ubs.com>]
> *Sent:* Monday, January 08, 2018 8:10 AM
> *To:* knecht.stefan_at_gmail.com; dmarc-noreply_at_freelists.org
> *Cc:* tim_at_oracle-base.com; andrew.kerber_at_gmail.com; mwf_at_rsiz.com;
> oracle-l_at_freelists.org; fmhabash_at_gmail.com; 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
> <knecht.stefan_at_gmail.com>]
> *Sent:* Friday, January 05, 2018 4:58 PM
> *To:* dmarc-noreply_at_freelists.org
> *Cc:* tim_at_oracle-base.com; Pande, Rajendra; Andrew Kerber; Mark W.
> Farnham; oracle-l_at_freelists.org; fmhabash_at_gmail.com;
> 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> 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_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
> *Cc:* Andrew Kerber; Mark W. Farnham; oracle-l_at_freelists.org;
> dmarc-noreply_at_freelists.org; fmhabash_at_gmail.com;
> 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> 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] *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; fmh;
> niall.litchfield_at_gmail.com; 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> 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] *On Behalf Of *Tim Hall
> *Sent:* Friday, January 05, 2018 12:18 PM
> *To:* dmarc-noreply_at_freelists.org
> *Cc:* mwf_at_rsiz.com; niall.litchfield_at_gmail.com; 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> 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 <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
> *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>
> 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> 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
> | _at_zztat_oracle
>
>
>

-- 

Regards,

John

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