Re: Meltdown and spectre

Hi.

From a straight patch perspective:

1. The RHEL kernel (RH compatibility kernel) patches were released last week some time. Possible over the weekend. Can't remember exactly. :)
2. The UEK patches have been around for a few days now. They are installed on some of my VMs at home and work.

{CVE-2017-5715}
{CVE-2017-5753}
{CVE-2017-5754}

> I opened a SR about Meltdown and Spectre patches for Oracle Linux and this
> is the response.
>
> 'Oracle has developed fixes addressing the Intel processor design flaws
> leading to vulnerabilities CVE-2017-5753, CVE-2017-5754, and CVE-2017-5715.
> Oracle will deliver those fixes, if applicable, in accordance with Oracle’s
> security update policies"
>
> So I guess they are not available yet.
>
> On Tue, Jan 9, 2018 at 2:52 PM, Jeff Chirco <backseatdba_at_gmail.com> wrote:
>
>> ksplice doesn't see to have that updated kernel. I run uptrack-upgrade
>> but there is nothing to be done.
>> Effective kernel version is 4.1.12-112.14.2.el7uek
>>
>> However a yum update listed the following
>> Installed:
>> kernel-uek.x86_64 0:4.1.12-112.14.10.el7uek
>>
>> kernel-uek-firmware.noarch 0:4.1.12-112.14.10.el7uek
>>
>> I am confused, also I am new to Linux environment.
>>
>> On Tue, Jan 9, 2018 at 1:03 PM, Maris Elsins <elmaris_at_gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I didn't red the whole history (so sorry if it was already mentioned),
>>> but the UEK fixes for Meltdown (CVE-2017-5754) were released this morning.
>>> See https://linux.oracle.com/cve/CVE-2017-5754.html for details.
>>>
>>> ---
>>> Maris Elsins
>>> _at_MarisElsins <https://twitter.com/MarisElsins>
>>> www.facebook.com/maris.elsins
>>>
>>>
>>>
>>> On Tue, Jan 9, 2018 at 8:18 PM, Jeff Chirco <backseatdba_at_gmail.com>
>>> wrote:
>>>
>>>> I am still confused how to tell if the exploit has been patched if I
>>>> run yum update or uptrack-upgrade
>>>>
>>>> On Tue, Jan 9, 2018 at 6:29 AM, Patrice sur GMail <
>>>> patrice.boivin_at_gmail.com> wrote:
>>>>
>>>>> that's the way it goes though.
>>>>>
>>>>> I remember Token Ring... vs. ethernet. Ethernet's up front costs were
>>>>> lower, people used that even though it had packet collision problems.
>>>>> token ring belonged to just one vendor, IBM. People probably didn't want
>>>>> to rely on just one vendor
>>>>>
>>>>> On Mon, Jan 8, 2018 at 3:39 PM, Reen, Elizabeth <
>>>>> dmarc-noreply_at_freelists.org> wrote:
>>>>>
>>>>>> The links I was referring to are
>>>>>> https://spectreattack.com/spectre.pdf and
>>>>>> https://meltdownattack.com/meltdown.pdf. They give an excellent
>>>>>> explanation. My masters is in systems engineering. My dissertation was
>>>>>> writing an operating system. I wish I have the time to surf the web to
>>>>>> read these things, but I have a real job supporting a couple hundred
>>>>>> databases. I got my information from the business journals my bosses were
>>>>>> reading. What they wrote was dumbed down and lacking the details. Most of
>>>>>> the vendor notes were as usual vague.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Linus Torvalds answer was just passing the buck. He depended on the
>>>>>> hardware to do his work. Did Intel know that he was outsourcing that to
>>>>>> them? It is not that hard to check that the process is not going outside
>>>>>> its memory. I will give him that he originally designed this as a single
>>>>>> user o/s. It has morphed into more but no one went back to look at the
>>>>>> design. One thing an o/s must do is protect itself against developers.
>>>>>> Leaving this open is like allowing anyone to update the disk map, an
>>>>>> invitation for disaster. I also question AWS and Oracle for allowing their
>>>>>> users to have the privs to do this. If you can control your own destiny it
>>>>>> is better. I understand that a lot of companies cannot afford their own IT
>>>>>> department.
>>>>>>
>>>>>>
>>>>>>
>>>>>> When you buy a Focus, you don’t expect it to be designed
>>>>>> like a Rolls Royce. Why people think that cheaper machines/software will
>>>>>> do the same thing as the more expensive versions is beyond me.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Liz
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* timseanhall_at_gmail.com [mailto:timseanhall_at_gmail.com] *On
>>>>>> Behalf Of *Tim Hall
>>>>>> *Sent:* Friday, January 05, 2018 6:18 PM
>>>>>> *To:* Reen, Elizabeth [ICG-IT]
>>>>>> *Cc:* knecht.stefan_at_gmail.com; rajendra.pande_at_ubs.com; Andrew
>>>>>> Kerber; Mark W. Farnham; oracle-l_at_freelists.org; fmhabash_at_gmail.com;
>>>>>> niall.litchfield_at_gmail.com
>>>>>>
>>>>>> *Subject:* Re: Meltdown and spectre
>>>>>>
>>>>>>
>>>>>>
>>>>>> RE: "This is the first piece that makes sense."
>>>>>>
>>>>>>
>>>>>>
>>>>>> This made me lol. Project Zero announced the issue. It was linked or
>>>>>> mentioned in pretty much every piece I read on this...
>>>>>>
>>>>>>
>>>>>>
>>>>>> RE: "I don’t see any reason why an O/S would allow a process to read
>>>>>> outside of its memory."
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not a CPU engineer or OS/Hypervisor developer so excuse my
>>>>>> over-simplistic thoughts and anyone feel free to jump in and correct me...
>>>>>> Operating systems and hypervisors will offload as much as possible to the
>>>>>> hardware. As an example, back in the day VMware used binary translation for
>>>>>> almost all system calls, but that was pretty slow. Once Intel and AMD
>>>>>> included their respective virtualization tech onto the chips (2006/2007)
>>>>>> guess what everyone they did? They passed some of this responsibility on to
>>>>>> the hardware to make the hypervisors leaner and more efficient. They trust
>>>>>> the chip to do what it says it will do. Likewise, if the OS or hypervisor
>>>>>> developer believes operations are safe because the chip is not going to do
>>>>>> something stupid, then they will definitely remove code path to improve
>>>>>> performance, since all the belt & braces code takes more processing and
>>>>>> slows stuff down. At the kernel level, every click counts, as is evident by
>>>>>> some of the performance impacts coming through.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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=wHP6u0BxMbXq5dlG98UAbpA2PaR_fjI1NM3ycJP9Qqs&s=M9waxcL2pdqDXF3Bg105rPVteDdKtTum1KZ13vuDjw8&e=>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Linus Torvalds response included,
>>>>>>
>>>>>>
>>>>>>
>>>>>> "A *competent* CPU engineer would fix this by making sure
>>>>>> speculation doesn't happen across protection domains."
>>>>>>
>>>>>>
>>>>>>
>>>>>> I know bugger all about this stuff, but his post reads to me like he
>>>>>> thought the CPU was protecting these calls, so the OS kernel didn't need to.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The picture from VMware doesn't sound so bad initially.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.vmware.com_security_2018_01_vmsa-2D2018-2D0002.html&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wHP6u0BxMbXq5dlG98UAbpA2PaR_fjI1NM3ycJP9Qqs&s=VAd2zEL94De6kQO6iC-r3xEaTaMB5a_LOdiAtcaCi7Y&e=>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I read some other stuff (can't find the links now) which suggested
>>>>>> VMware were being very naive and downplaying the problem. I guess we will
>>>>>> see how this one plays out over the coming weeks.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I also saw some other stuff, once again can't find the links, that
>>>>>> suggested it will need to be a combination of kernel and firmware to
>>>>>> mitigate the issues until the chip designs are altered.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tim...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 5, 2018 at 10:19 PM, Reen, Elizabeth <
>>>>>> elizabeth.reen_at_citi.com> wrote:
>>>>>>
>>>>>> Thanks Stefan! This is the first piece that makes sense. There is a
>>>>>> possibility that this could be fixed in the firmware, but that is going to
>>>>>> take time. I can see why an o/s fix would work. I don’t see any reason
>>>>>> why an O/S would allow a process to read outside of its memory. When I
>>>>>> played with assemblers, this was not allowed by the O/S.
>>>>>>
>>>>>>
>>>>>>
>>>>>> A shared environment such as AWS would be a great risk from this. An
>>>>>> environment within a company would be a lesser risk, but odds are they
>>>>>> would be hacked in an easier fashion. To give Linux and Windows their due,
>>>>>> they did start our as large multi user O/Ses.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Liz
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>>> sts.org] *On Behalf Of *Stefan Knecht
>>>>>> *Sent:* Friday, January 05, 2018 4:58 PM
>>>>>> *To:* dmarc-noreply_at_freelists.org
>>>>>> *Cc:* tim_at_oracle-base.com; rajendra.pande_at_ubs.com; 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/
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__googleprojectzero.blogspot.com_&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=CABPEKJ53eOCZbVN3rPW3M0UIHnB601cQA0kOVPS6zU&e=>
>>>>>>
>>>>>> "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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_1_3_797&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=tq1K8SJrK43F-6O_n2OAUuiPKQYUZPKZF0ik2TcSKWA&e=>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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 <(718)%20248-9930> (Office)
>>>>>>
>>>>>> Service Now Group: CPB-ORACLE-DB-SUPPORT
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>>>>>> sts.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/ho
>>>>>> w-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_freeli
>>>>>> sts.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_freeli
>>>>>> sts.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_freeli
>>>>>> sts.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_freeli
>>>>>> sts.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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__zztat.net&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=owvvbrhq6Z7kg7U-_DA7iMOlFl_IY0FC9C8vD3rwzL0&e=>
>>>>>> | Support our Indiegogo campaign at igg.me/at/zztat
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__igg.me_at_zztat&d=DwMFaQ&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=yWMFosURAngbt8VLeJtKLVJGefQxustAZ9UxecV7xpc&m=wROoeuG5HNCZhwPFchpBheTMHzfTwmwawpLi0NJySYU&s=_rErjKOWTCZSzV8SZaZVS6Pn6l_98ESD342VLu1FxDs&e=>
>>>>>> | _at_zztat_oracle
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> -- Patrice
>>>>> My profiles: [image: Facebook]
>>>>> <http://www.facebook.com/home.php?#!/profile.php?id=100000206805521>[image:
>>>>> LinkedIn] <http://ca.linkedin.com/pub/patrice-boivin/a/933/5a9>[image:
>>>>> Twitter] <http://www.twitter.com/PatriceBoivin>
>>>>>
>>>>
>>>>
>>>
>>
>

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