Would SELinux protect in any way against either of these vulnerabilities? On 2018-01-12 00:18, Joseph Sinclair wrote: > Feel free to repost anywhere. I don't have a blog site I use; so no > real place to post a full article... > > On 2018-01-11 07:24 PM, Aaron Jones 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 >>> 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 >>>>> 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 . 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. >>>>>