Yes. There were a couple of details I wanted but was not finding. Thank
you.
On Jan 11, 2018 7:24 PM, "Aaron Jones" <
retro64xyz@gmail.com> wrote:
Thanks Joe.
You should blog an article about this cuz that was the best explanation for
the issue I have read so far.
> On Jan 11, 2018, at 6:42 PM, Joseph Sinclair <plug-discussion@stcaz.net>
wrote:
>
> There seems to be a lot of confusion surrounding the recently disclosed
CPU hardware issues...
> A few points to consider:
> 1) This is a cache timing attack using speculative execution (a key
performance feature in the hardware) that exposes data (i.e. it's not an
exploit to "take over" a system); it can only read memory, and only VERY
slowly, while thrashing the heck out of the CPU.
> 2) Abusing speculative execution is literally something nobody thought of
doing until a few years ago.
> 3) The researchers spent an immense amount of time figuring out tactics
that worked, time no hardware design engineer would ever have had
available, assuming that engineer even had the knowledge to do the coding
required (hint: they don't).
> 4) Exploiting these flaws is HARD. It requires native code execution,
careful and highly skilled coding, specific targeting of the memory to be
read, and a lot of time on the target machine without tripping alarms due
to CPU use.
> 5) The major concern here is things like VM farms because this allows
untrusted code in a guest to (very slowly) read memory from the host or
other guests. It's possible to use in other contexts, but the cost/benefit
balance is pretty bad; desktops and other targets are far easier to exploit
with well-known and widely used "social" hacks.
>
> Lacking the full detail, I would venture that this *type* of exploit is
possible (in some form) for every Intel CPU since the original Pentium PRO
which introduced speculative execution to the Intel architecture.
> We don't need to replace hardware, fortunately, this specific set of
tactics can be mitigated by having the Kernel (along with microcode, aka
firmware) set flags in the CPU to force a full context switch in the
specific situations identified by the researchers.
> Yes, mitigation slows down execution a bit; basically the IPC for Intel
chips now roughly matches the IPC for AMD chips which always forced the
context switch (due to a different design balance).
> I would venture that this flaw is actually caused by Intel having such a
heavy focus to achieve (and maintain) higher IPC levels than AMD, and
cutting a (seemingly benign) corner to accomplish that.
>
> A bit of inside-baseball here:
> Every digital design engineer looks for what we call "don't cares"
segments of the boolean map where the logic value has no impact on the
"correctness" of the result.
> Those are places where we can cut gate count or speed up execution.
> Avoiding a context switch in a CPU with the Intel design for 3 layer
caching is one of those areas where "don't cares" can show up.
> My gut feel is that the Intel engineers saw an opportunity to retain
"correct" execution of code while speeding up speculative execution by
skipping the context switch until it was actually necessary (e.g. the
speculative branch became "live").
> It is exactly the kind of thing I can see a really smart engineer doing
because, without future knowledge, it's actually the right thing to do.
> You get faster execution without any added cost and without breaking
existing code.
> That, in retrospect, was a mistake that allowed a very sophisticated
attacker to read a few bits of unauthorized memory in a very sneaky manner.
> That someone, a decade or two after the design arose, discovered a way to
misuse that design isn't a sign of malice or malpractice; it's a sign that
security researchers are getting REALLY good at finding unexpected ways to
use hardware design against security.
>
>
> P.S.
> That reddit article is utter garbage.
> Yes, there is, on some motherboards, a Management Engine which is a
*separate* CPU, is mostly present only on "business" and server
motherboards, and has NOTHING TO DO WITH the recent exploits. The FSF and
others have been warning about that particular bit of hardware for a long
time.
> The ME has valuable functionality that makes sense for servers
especially, and for business-owned machines in general (mostly remote
system management, particularly lights-out management).
> The ME was added to the system at the request of business customers so
they could remotely access machines owned by the business (even if turned
off) and either manage their servers or ensure the main O/S and
applications were kept in compliance with policy on desktops.
> Every motherboard I've seen with an ME (and only some have one) can
disable the ME; usually with a jumper or switch on the board.
> As I understand things it was actually government buyers who demanded the
ability to disable the ME (originally it couldn't be disabled), because
government agencies are targets far more often than they are attackers.
>
>> On 2018-01-11 10:36 AM, techlists@phpcoderusa.com wrote:
>> This is basic stuff. Kernel memory must be segregated and each
>> application's memory must be segregated. These are the basics of CPU
>> functionality. That is why I find theses issues perplexing. And it
>> leads me to one basic question. If these problems persisted since 1995,
>> how could these issue go undetected until recently when multiple
>> separate groups discovered these flows? AND is it possible others have
>> found and used these flaws for their own gain?
>>
>> No matter what happened, politics, accident... etc We have a HUGE
>> problem. Even if there were CPUs that were not vulnerable, it would
>> take years to replace all computers that are publicly facing. In the
>> mean time there are some seriously evil people / groups / countries that
>> will be looking into how they can use theses chip bugs / vulnerabilities
>> / features... to further their goals.
>>
>>> From what I can tell the solution is to use software - the kernel to fix
>> or patch the shortcomings of these CPUs. A software patch to fix
>> hardware. This is very scary. A software patch can be removed and / or
>> replaced, leaving the host vulnerable.
>>
>>> On 2018-01-11 10:10, Mark Phillips wrote:
>>>
>>> No, I don't work at Intel. I am, however, not a believer in all the
government conspiracy theories floating around the Internet.
>>>
>>> Mark
>>>
>>> On Thu, Jan 11, 2018 at 9:25 AM, Aaron Jones <retro64xyz@gmail.com>
wrote:
>>>
>>> Signals intelligence is believed to have been birthed in 1904.
>>>
>>> But exploiting hardware isn't new. For military, police, or criminal
intentions.
>>>
>>> You work at Intel Mark? Lol
>>>
>>> On Jan 11, 2018, at 9:11 AM, Mark Phillips <mark@phillipsmarketing.biz>
wrote:
>>>
>>> There is no conspiracy here. 23 years ago no one thought about attack
vectors and how to take over machines. It is only recently that we are all
sensitized to this problem. Even though the tech world is sensitized to the
nature of exploits, companies still ship brand new products (e.g. Nest,
cars, etc.) that can be exploited by almost anyone. It was only recently
that router and switch companies stopped using admin and admin as login
credentials!
>>>
>>> Your argument that these new CPU exploits are a government conspiracy
can be applied to any potential exploit discovered today in a piece of code
written yesterday.
>>>
>>> Mark
>>>
>>> On Thu, Jan 11, 2018 at 9:02 AM, Carruth, Rusty <
Rusty.Carruth@smartm.com> wrote:
>>> As mentioned earlier, I've done my share of ... um, looking for flaws
in design of operating systems back when I was in college. (What, 1976?)
>>>
>>> We discovered some bad flaws in the design of the <redacted>. How long
had the Univac been around? I don't know, but a while. Unless someone
with WAY too much time on their hands is actively seeking ways around
stuff, there's only so much 'bug' you can find. (and, actually, you really
need more than one person involved (partially so someone can ask the
'right' stupid question :-))
>>>
>>> Doesn't take malice or sloppiness, and I will say being a
publicly-traded company makes it very hard to spend the time required to
even start on the hacking required (Being publically-traded makes your
owner effectively insane, since your owner is actually many people, all
with different and often diametrically opposing goals for the company).
>>>
>>> Anyway, tell you what - go read the Intel hardware docs and see if you
can find the info needed to put together to see the bug. And this with
prior knowledge of where to look.
>>>
>>> I will say that this doesn't excuse much, but realize that being a
public company drives you insane ;-)
>>>
>>> Rusty
>>>
>>> -----Original Message-----
>>> From: PLUG-discuss [mailto:plug-discuss-bounces@lists.phxlinux.org] On
Behalf Of
techlists@phpcoderusa.com
>>> Sent: Thursday, January 11, 2018 8:42 AM
>>> To: Main PLUG discussion list
>>> Subject: Re: Post : INTEL'S SECURITY FLAW IS NO FLAW
>>>
>>> ...
>>>
>>> I've read these issues may have persisted as far back as 1995. How does
>>> that happen? How does an army of engineers miss this for 23 years? How
>>> do you explain that?
>>>
>>> That means lots of people came and went. There should have been lots of
>>> QA... for 23 years.
>>>
>>> How does this happen? Only two ways I can see 1) sloppy work, or 2)
>>> intentionally.
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1]
>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1]
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1]
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>> Links:
>> ------
>> [1] http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)