RE: Meltdown and spectre

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.

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

On Sat, Jan 6, 2018 at 4:34 AM, Reen, Elizabeth
<dmarc-noreply@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>> wrote:
All of that happens in the O/S not on the chip. One does not log
into a processor.

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<mailto: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

“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?

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<mailto: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.

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.

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<mailto: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<mailto: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.