I got an official announcement about these issues related to my Oracle
Cloud account. Basically it said the patches have been developed and there
will be maintenance work on Oracle Cloud to take corrective action. Watch
out for maintenance announcements etc.
On Thu, Jan 11, 2018 at 11:18 PM, Tim Hall <tim@xxxxxxxxxxxxxxx> wrote:
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.
# rpm -q --changelog kernel-uek | awk
'/CVE-2017-5715|CVE-2017-5753|CVE-2017-5754/{print
$NF}' | sort -u
{CVE-2017-5715}
{CVE-2017-5753}
{CVE-2017-5754}
#
The Spectre patches came out on the 6th. I think the Meltdown fix was
released Tuesday 9th evening (UK time). That coincides with what Maris said.
3) I don't use ksplice, so I can't comment about whether these are
available via ksplice yet, but they definitely exist for the conventional
route. :)
I imagine this is the beginning of a whole lot of patches being released
for the OS, and then a bunch more for applications running on the OS's too.
We will all be patch-tastic in the next few months. :)
Cheers
Tim...
On Thu, Jan 11, 2018 at 3:24 PM, Jeff Chirco <backseatdba@xxxxxxxxx>
wrote:
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@xxxxxxxxx>
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@xxxxxxxxx> 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
@MarisElsins <https://twitter.com/MarisElsins>
www.facebook.com/maris.elsins
On Tue, Jan 9, 2018 at 8:18 PM, Jeff Chirco <backseatdba@xxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx [mailto:timseanhall@xxxxxxxxx] *On
Behalf Of *Tim Hall
*Sent:* Friday, January 05, 2018 6:18 PM
*To:* Reen, Elizabeth [ICG-IT]
*Cc:* knecht.stefan@xxxxxxxxx; rajendra.pande@xxxxxxx; Andrew
Kerber; Mark W. Farnham; oracle-l@xxxxxxxxxxxxx; fmhabash@xxxxxxxxx;
niall.litchfield@xxxxxxxxx
*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@xxxxxxxx> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freeli
sts.org] *On Behalf Of *Stefan Knecht
*Sent:* Friday, January 05, 2018 4:58 PM
*To:* dmarc-noreply@xxxxxxxxxxxxx
*Cc:* tim@xxxxxxxxxxxxxxx; rajendra.pande@xxxxxxx; Andrew Kerber;
Mark W. Farnham; oracle-l@xxxxxxxxxxxxx; fmhabash@xxxxxxxxx;
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:
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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freeli
sts.org] *On Behalf Of *Tim Hall
*Sent:* Friday, January 05, 2018 4:06 PM
*To:* rajendra.pande@xxxxxxx
*Cc:* Andrew Kerber; Mark W. Farnham; oracle-l@xxxxxxxxxxxxx;
dmarc-noreply@xxxxxxxxxxxxx; fmhabash@xxxxxxxxx;
niall.litchfield@xxxxxxxxx
*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@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
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@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@xxxxxxxxxxxxx; fmh;
niall.litchfield@xxxxxxxxx; 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>
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freeli
sts.org] *On Behalf Of *Tim Hall
*Sent:* Friday, January 05, 2018 12:18 PM
*To:* dmarc-noreply@xxxxxxxxxxxxx
*Cc:* mwf@xxxxxxxx; niall.litchfield@xxxxxxxxx;
andrew.kerber@xxxxxxxxx; 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freeli
sts.org] *On Behalf Of *Mark W. Farnham
*Sent:* Friday, January 05, 2018 8:38 AM
*To:* 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.
mwf
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freeli
sts.org <oracle-l-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Niall
Litchfield
*Sent:* Thursday, January 04, 2018 10:58 AM
*To:* 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> 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>
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=>
| @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>
