From plug-discuss-bounces@lists.phxlinux.org Fri Jan 12 04:41:31 2018 Return-Path: X-Original-To: lurker@lists.phxlinux.org Delivered-To: lurker@lists.phxlinux.org Received: from phxlinux.org (localhost [127.0.0.1]) by phxlinux.org (Postfix) with ESMTP id 1276932A01B9; Fri, 12 Jan 2018 04:41:31 -0700 (MST) X-Original-To: plug-discuss@lists.phxlinux.org Delivered-To: plug-discuss@lists.phxlinux.org Received: from mr26p44im-ztdg08103301.me.com (mr26p44im-ztdg08103301.me.com [17.111.247.49]) by phxlinux.org (Postfix) with ESMTPS id E6C0732A01B6 for ; Fri, 12 Jan 2018 04:41:29 -0700 (MST) Received: from process-dkim-sign-daemon.mr26p44im-ztdg08103301.me.com by mr26p44im-ztdg08103301.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P2F00700XPADF00@mr26p44im-ztdg08103301.me.com> for plug-discuss@lists.phxlinux.org; Fri, 12 Jan 2018 11:40:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1515757259; bh=cF0d1kQWdc5u/06zUg5ZKAb7pWXtmmL1T8vzzh/CC1k=; h=From:MIME-version:Content-type:Subject:Date:To:Message-id; b=S7TiZbCGy4KjPiwqNjovufRv2glxvvADrSs3WTkfk1VzrVsenwwKoUuQlJrQX4tv9 ADXQS/DJd2rvC9NbhRZTijsguGbZWy0G3Xb2uOiQ+NWTDFDdx+dIrx7CmZGsrXU2ND 2jAuLGALcXgiLVm0HH7yf9XwXBsc1FPVAczQ5ov1uOZKNhnhx/+5kOF/U4eIxQDN3Q XqaDAlQpRQdQymR1s2b2qeE9TtiXuPF1mntyKka631f5dRLvXX//GazhAWzvgXCjew FOS9Wxx5bvmlu7tvvVOlifiOoVOU22s2P8l1qcB6BTZjpnHqHElIeoJJSLBIxrD3kD Ylxryv8wdhxOA== Received: from icloud.com ([127.0.0.1]) by mr26p44im-ztdg08103301.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P2F004FWXS93R50@mr26p44im-ztdg08103301.me.com> for plug-discuss@lists.phxlinux.org; Fri, 12 Jan 2018 11:40:59 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-12_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1801120158 From: Eric Oyen MIME-version: 1.0 (Apple Message framework v1283) Subject: =?windows-1252?Q?Re=3A_Post_=3A_INTEL=92S_SECURITY_FLAW_IS_NO_FL?= =?windows-1252?Q?AW?= Date: Fri, 12 Jan 2018 04:40:57 -0700 In-reply-to: To: Main PLUG discussion list References: <20180111000358.4592442b@mydesk.domain.cxm> <1b93cf5ba951530d4a1aed28a87abbb5@phpcoderusa.com> <63D55323-B50A-493A-BE6D-DCB9D7FA9AC4@gmail.com> <7820ffa052c1a6a00d6d1ef2330f92ec@phpcoderusa.com> <784a30bb-ab26-5592-0383-6742ed9cc03e@stcaz.net> <56D43456-E4C4-4112-AA37-C6C8C2AA1F8B@gmail.com> Message-id: X-Mailer: Apple Mail (2.1283) X-BeenThere: plug-discuss@lists.phxlinux.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Main PLUG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Main PLUG discussion list Content-Type: multipart/mixed; boundary="===============6244907501463825160==" Errors-To: plug-discuss-bounces@lists.phxlinux.org Sender: "PLUG-discuss" --===============6244907501463825160== Content-type: multipart/alternative; boundary="Apple-Mail=_FDD724B8-1A02-4082-8CDD-25E9B87A75EC" --Apple-Mail=_FDD724B8-1A02-4082-8CDD-25E9B87A75EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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-helicopte= r-24960500/ >=20 > 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=92t find any more about his experience.=20 >=20 > I would like to have a decibel comparison between the new silent = blackhawk and the loach-p. Silent being relative. >=20 > On Jan 12, 2018, at 12:29 AM, Stephen Partington = wrote: >=20 >> Yes. There were a couple of details I wanted but was not finding. = Thank you.=20 >>=20 >> On Jan 11, 2018 7:24 PM, "Aaron Jones" wrote: >> Thanks Joe. >>=20 >> You should blog an article about this cuz that was the best = explanation for the issue I have read so far. >>=20 >> > 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. >> >> >> >>> =46rom 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. >> >>> >> >>> --------------------------------------------------- >> >>> 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 >>=20 >> --------------------------------------------------- >> 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 --Apple-Mail=_FDD724B8-1A02-4082-8CDD-25E9B87A75EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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:


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=92t 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 <cryptworks@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" <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.
>>
>>> =46rom 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&= gt; 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-bounc= es@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.phxlinu= x.org
>>> To subscribe, unsubscribe, or to change your mail = settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss [1]
>>
>>> = ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
>>> To subscribe, unsubscribe, or to change your mail = settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss [1]
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss [1]
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss
>>
>> Links:
>> ------
>> [1] http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss
>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-dis= cuss

-------------------------------------------------= --
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinu= x.org
To subscribe, unsubscribe, or to change your = mail settings:
http://li= sts.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discus= s mailing list - PLUG-discuss@lists.phxlinu= x.org
To subscribe, unsubscribe, or to change your mail = settings:
http://li= sts.phxlinux.org/mailman/listinfo/plug-discuss

<= /div>= --Apple-Mail=_FDD724B8-1A02-4082-8CDD-25E9B87A75EC-- --===============6244907501463825160== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBMVUct ZGlzY3VzcyBtYWlsaW5nIGxpc3QgLSBQTFVHLWRpc2N1c3NAbGlzdHMucGh4bGludXgub3JnClRv IHN1YnNjcmliZSwgdW5zdWJzY3JpYmUsIG9yIHRvIGNoYW5nZSB5b3VyIG1haWwgc2V0dGluZ3M6 Cmh0dHA6Ly9saXN0cy5waHhsaW51eC5vcmcvbWFpbG1hbi9saXN0aW5mby9wbHVnLWRpc2N1c3M= --===============6244907501463825160==--