---------------------------------------------------This article says they flew Laos to NV. But I swear the first time I heard this story the teller said Cambodia. The pilot on this did a really cool writeup I can’t find any more about his experience.I would like to have a decibel comparison between the new silent blackhawk and the loach-p. Silent being relative.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
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