Top Page
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: PLUG-discuss
To: Main PLUG discussion list

What you point out is great in a sterile / lab environment, but not in
the wild. I am hoping the courts will find the chip manufactures liable
for not doing more QA. These chips are used in banking, government, all
sorts of business, and by consumers. We have become so dependent on
computers that I venture to say if you took 90% of them away people
would die -- the supply chain would fail and there would be total chaos.

It is MY opinion that the chip manufactures have a fiduciary
responsibility to produce chips free of default, or at least free of
default to the degree of Meltdown and Spectre.

Just like auto manufactures have a fiduciary responsibility to produce
cars that cannot be hacked or go crazy and crash. Personally I do not
understand why cars need computers and especially why they need to be
connected to the Internet.

As for stockholders they probably will lose their shirts. Just think it
might have cost just a few pennies per CPU to find and eradicate these
issues before they became a problem. Would you be willing to pay a few
more dollars per CPU to not have this issue, I would.

AND I still think this is much larger than anyone wants to say. Patching
hardware with software is an exploit waiting to happen.

I assure you the Russians, Chinese, North Koreans, and possibly all the
members of the UN are looking at ways to use these CPU weaknesses
against us, not to mention every black hat in the world.

On 2018-01-11 18:42, Joseph Sinclair 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, 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 <>
>>> 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
>>> <> 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
>>> <> 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 []
>>> On Behalf Of
>>> Sent: Thursday, January 11, 2018 8:42 AM
>>> To: Main PLUG discussion list
>>> ...
>>> 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 -
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> [1]
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list -
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> [1]
>> ---------------------------------------------------
>> PLUG-discuss mailing list -
>> To subscribe, unsubscribe, or to change your mail settings:
>> [1]
>> ---------------------------------------------------
>> PLUG-discuss mailing list -
>> To subscribe, unsubscribe, or to change your mail settings:
>> Links:
>> ------
>> [1]
>> ---------------------------------------------------
>> PLUG-discuss mailing list -
>> To subscribe, unsubscribe, or to change your mail settings:
> ---------------------------------------------------
> PLUG-discuss mailing list -
> To subscribe, unsubscribe, or to change your mail settings:

PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings: