From plug-discuss-bounces@lists.phxlinux.org Fri Jan 12 17:32:43 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 5684532A01B7; Fri, 12 Jan 2018 17:32:43 -0700 (MST) X-Original-To: plug-discuss@lists.phxlinux.org Delivered-To: plug-discuss@lists.phxlinux.org Received: from codezilla.xyz (codezilla.xyz [138.197.192.135]) by phxlinux.org (Postfix) with ESMTP id 9477432A01B6 for ; Fri, 12 Jan 2018 17:32:41 -0700 (MST) Received: from webmail.codezilla.xyz (hydrogen.codezilla.xyz [127.0.0.1]) by codezilla.xyz (Postfix) with ESMTP id 30B624194E for ; Fri, 12 Jan 2018 16:32:41 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_2a7e8792f07f7e23dc089486e045fba4" Date: Fri, 12 Jan 2018 17:32:41 -0700 From: Nathan O'Brennan To: Main PLUG discussion list Subject: =?UTF-8?Q?Re=3A_Post_=3A_INTEL=E2=80=99S_SECURITY_FLAW_IS_NO_FLA?= =?UTF-8?Q?W?= In-Reply-To: <732F89AC-D94D-4F15-9036-2388D5509F05@gmail.com> 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> <0856d5bf808bdeec1781d0c16bb437a1@codezilla.xyz> <732F89AC-D94D-4F15-9036-2388D5509F05@gmail.com> Message-ID: <9eb6943094a1a51b85fb25bb353e3232@codezilla.xyz> X-Sender: plugaz@codezilla.xyz User-Agent: Roundcube Webmail/1.3.0 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 Errors-To: plug-discuss-bounces@lists.phxlinux.org Sender: "PLUG-discuss" --=_2a7e8792f07f7e23dc089486e045fba4 Content-Type: multipart/alternative; boundary="=_9c9d894748cd46545d68a2f731c97f39" --=_9c9d894748cd46545d68a2f731c97f39 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII The part I find really scary with all of this, as Keith is saying, we are fixing hardware with software, meaning someone can "unpatch" the change. I don't believe that processor microcode can be "unpatched" nor can it easily be patched again to undo what was done. However, what I see as the real issue with all of this is the microcode updates allow software developers to choose whether or not they take advantage of the new IBPB, IBRS, STIBP, and or the retpoline changes. What this means is going forward we are at the mercy of the developers to believe they made the right choice, if they even had a clue to begin with. (by that I mean a developer wasn't a noob, or didn't use some point and click development tool). Remember the days when you could download a virus creation tool that would allow you to make some selections and it would spit out an .exe that would crash a system and made a world full of script kiddies happy? I see something similar to that coming for this. Someone will build a tool to check if X particular piece of code is protected and using memory the way it should be or not. Until compilers get updated, and we have some visual confirmation or something that the running code has been recompiled with the new compiler that enforces use of these new microcode instructions, we're kind of screwed. I didn't have a whole lot of trust in Microsoft before, and now I really don't. I think they will use this to their advantage to force people to upgrade to 10 (notice they said "a few win 10 workloads" but "most" win 7 and 8 workloads?) --=_9c9d894748cd46545d68a2f731c97f39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

The part I find really scary with all of this, as Keith is saying, we ar= e fixing hardware with software, meaning someone can "unpatch" the change= =2E

I don't believe that processor microcode can be "unpatched" nor can it e= asily be patched again to undo what was done.

However, what I see as the real issue with all of this is the microcode = updates allow software developers to choose whether or not they take advant= age of the new IBPB, IBRS, STIBP, and or the retpoline changes.

What this means is going forward we are at the mercy of the developers t= o believe they made the right choice, if they even had a clue to begin with= =2E (by that I mean a developer wasn't a noob, or didn't use some point and= click development tool).

Remember the days when you could download a virus creation tool that wou= ld allow you to make some selections and it would spit out an .exe that wou= ld crash a system and made a world full of script kiddies happy? I see some= thing similar to that coming for this. Someone will build a tool to check i= f X particular piece of code is protected and using memory the way it shoul= d be or not.

Until compilers get updated, and we have some visual confirmation or som= ething that the running code has been recompiled with the new compiler that= enforces use of these new microcode instructions, we're kind of screwed.

I didn't have a whole lot of trust in Microsoft before, and now I really= don't. I think they will use this to their advantage to force people to up= grade to 10 (notice they said "a few win 10 workloads" but "most" win 7 and= 8 workloads?)


--=_9c9d894748cd46545d68a2f731c97f39-- --=_2a7e8792f07f7e23dc089486e045fba4 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0x241A8881.asc Content-Disposition: attachment; filename=0x241A8881.asc; size=1723 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBFowSfIBCACObc9+OnP679qvRwNMHrgoAVpTAPmN9DiUbxPDi2GXeeTtGNLd Czs4LJiBlEOLP4Cz8j1no/84qiX6TQIaN9SNQpD5/r824i6qu7HYjEgF15/Gtn7g XpYUiy/H3SVOctJWvZoDji3ZaLzS2JonzLjytoW1L6EdhJywhr6qkLqqD9KOrMCa n24Fo+6tUG3UvYcposv/3eg3OjQK/oH1UEdDx5JZkBnLwCNCYqfYRPKc+mdOMdi9 Onjhbw6a2pPG5gBSpbnws06hSwY0RuqUoQuL+BTz9yNEE85tDYyl28qBMyCPwn6h 9SCj51PpgMmDiaTftw2vPPWfIjaG+ICzRbutABEBAAG0J05hdGhhbiBPJ0JyZW5u YW4gPHBsdWdhekBjb2RlemlsbGEueHl6PokBNQQQAQgAKQUCWjBJ8wYLCQgHAwIJ EIESaBskGoiBBBUIAgoDFgIBAhkBAhsDAh4BAAB0tAf/X5rq4dxyEEqsyfMPo2dB TacqJnlV5yGIku4ki0JX7OBChsm+qcT9SobEun4Earte/A89ZngGrY7Wsr6S5Ihr AgPWXMkRXdSvgMCPT9NqpsP4cMz2v41JORgHIZbh2aVPwRvG/oLsmgDXlNrx8Q35 rHoXDK5uOtUIvFxWPJ/EH2uqtYULtiQKZ8bospGCVopQBJ+Dw0VdvaTJuLV3VXZJ IThhX38QevmebpxBcer/Z0x0BDQwLnn+XQqqFSatHnCHtxCuDjxCqlg3jV4xwj3d Rq0BMPzvpuDCkPkiWBcEw1xZq1zaRGzBbypg4jSWq1RR4Vz9gfoHznPxOJFv9aCT 6bkBDQRaMEnyAQgArAiPsMmz8gkZ5WwYoU2QV9eT2jcakO03JD9/vmEh4yYxRpJh DXlbzEibVcIR89RyKjuWhmSJMiyLyA63RV1tJdjSEQyQKmkAIEysz5gunAm9Nx+p S9tfZxAmL5ZQ7shblNUFJvbdPS3THD4nU7e52jPDZoVZvo4Q003pE0vCYfkuIwtb BLu8qKN2kUta8Y6B88izU0/ww/NYMwuVve61y5O+oVz5jidczRmM1y/FTSuCNQ6x cYk4HuSpmBDanO5C7hmYUjIs0DCbp61BFyFqHl842aDMp9Nqij/9uf5ZVsd/5Qho 7bkg8z2o4k4F9lpNremoYIOH1WUFO8pGdwBYTQARAQABiQEfBBgBCAATBQJaMEnz CRCBEmgbJBqIgQIbDAAAhw8H/1s66QGktAEnH86lWW2xoCbyyC84lzGfm5Z+HZNu 4i7lY39i4lf4B5KYHSvbd0VRpxYV+CTNgb4TItgcEkuenV1ZYruj1jbxyEwLLH7a IDUcg2gbfj+PPtIpU2QgzkdYCZUzbqndtk88ELYpk+LvhX60iw6BK7iNeTAp5xTJ kZYiUYSH9OV2qb9wi6jD0w0SijjHAZSNTbDx9FL15oP2AxYKVeYToYczeWRsoH0w cOIwqS3c9O+c9neI9mljwhiwssHaELoKkL1cQgYK65wpyxwiO0LZRfZngqqtBHkA yQpMhKboCT40nDWbRx2pvpDAxW+9kweNuFYby+wTpugNgpM= =cifu -----END PGP PUBLIC KEY BLOCK----- --=_2a7e8792f07f7e23dc089486e045fba4 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBMVUct ZGlzY3VzcyBtYWlsaW5nIGxpc3QgLSBQTFVHLWRpc2N1c3NAbGlzdHMucGh4bGludXgub3JnClRv IHN1YnNjcmliZSwgdW5zdWJzY3JpYmUsIG9yIHRvIGNoYW5nZSB5b3VyIG1haWwgc2V0dGluZ3M6 Cmh0dHA6Ly9saXN0cy5waHhsaW51eC5vcmcvbWFpbG1hbi9saXN0aW5mby9wbHVnLWRpc2N1c3M= --=_2a7e8792f07f7e23dc089486e045fba4--