hah! with my ears, I don't care how bloody silent they make the things, I can still hear those blades slicing the air at 5 miles.
-eric from the central offices of the Technomage Guild, Sensors Dept. On Jan 12, 2018, at 3:53 AM, Aaron Jones wrote: > https://www.airspacemag.com/military-aviation/air-americas-black-helicopter-24960500/ > > 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. > > On Jan 12, 2018, at 12:29 AM, Stephen Partington <cryptwo...@gmail.com> wrote: > >> Yes. There were a couple of details I wanted but was not finding. Thank you. >> >> On Jan 11, 2018 7:24 PM, "Aaron Jones" <retro64...@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-discuss...@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, techli...@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 <retro64...@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 <m...@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.carr...@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-boun...@lists.phxlinux.org] On >> >>> Behalf Of techli...@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
--------------------------------------------------- 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
