Re: Meltdown and spectre

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/mel

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