I think I've answered my own questions by checking out the menuconfig options, it looks to me as though up to and including Skylake is possible, and flashing internally *should* be okay?
John. On 03/05/17 10:09, John Lewis wrote: > > Thanks everyone for the responses. > > The thing that bothers me, is if you take a possibly extreme > interpretation of "There is also a chance of attacks performed on > Intel systems without Intel AMT support." from the people who reported > the vuln @ https://www.embedi.com/news/mythbusters-cve-2017-5689 it > sounds like it could be every board since 2010. > > I understand that Intel have a vested interest in this being (or at > least appearing to be) as small as possible, whereas the reporter's > interest is for it to be as big as possible. I suspect the truth might > end up to be somewhere in between, e.g. that there is technically > something which may apply to all boards under certain circumstances, > but may not be considered realistically practicable on a > large/significant scale. > > Still, I think this does make a case for using ME cleaning of some > description, regardless of where this ends up, but presumably that > might not be entirely successful unless flashing externally? Is there > some form of ME cleaning available for all the chipsets up to Kabylake? > > John. > > > On 03/05/17 05:37, Zoran Stojsavljevic wrote: >> I also read in details some of the emails from the previous threads. >> I downloaded SCSDiscovery tool: >> https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-Utility >> and ran it on my notebook. >> >> I got as response a bunch of nonsense info (basically, it failed >> everywhere) : >> >> C:\Program Files\Intel_SCS_Discovery_11.1.0.75>type >> SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log >> 2017-05-03 06:15:19:(INFO) : ACU Configurator , Category: >> HandleOutPut: Starting log 2017-05-03 06:15:19 >> 2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category: >> -SystemDiscovery-: DESKTOP-@@@@@@@: Discovering the System information... >> 2017-05-03 06:15:33:(WARN) : SCSDiscovery.exe, Category: System >> Discovery: System Discovery finished with warnings: System Discovery >> failed to get data from some of the interfaces on this system. >> (0xc00027ff). Failed to get data from the OS Registry interface. >> (0xc0002840). Failed to read the registry value (Primary DNS suffix). >> (0xc0001f52). Failed to open the registry Key >> (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the >> file specified. (0xc0001f50). The registry key not >> found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed >> to get data from the GetDNSLookupName interface. (0xc0002842). >> Failed to retrieve the host onboard IPv4 IP (please check the LAN >> settings). (0xc0002836). >> 2017-05-03 06:15:33:(INFO) : SCSDiscovery, Category: Exit: >> ***********Exit with code 32 - Intel(R) AMT operation completed with >> warnings: Details: Success. System Discovery finished with warnings: >> System Discovery failed to get data from some of the interfaces on >> this system. (0xc00027ff). Failed to get data from the OS Registry >> interface. (0xc0002840). Failed to read the registry value (Primary >> DNS suffix). (0xc0001f52). Failed to open the registry Key >> (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the >> file specified. (0xc0001f50). The registry key not >> found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed >> to get data from the GetDNSLookupName interface. (0xc0002842). >> Failed to retrieve the host onboard IPv4 IP (please check the LAN >> settings). (0xc0002836). >> >> C:\Program Files\Intel_SCS_Discovery_11.1.0.75> >> >> Not surprised, since I do NOT have AMT capabilities (I have 1.5MB ME >> series 9). >> >> Zoran >> >> On Tue, May 2, 2017 at 11:56 PM, Vadim Bendebury >> <vben...@chromium.org <mailto:vben...@chromium.org>> wrote: >> >> I wonder if anyone ever completely trusted AMT - maybe some naive >> excessive cool-aid drinkers :) >> >> -vb >> >> On Tue, May 2, 2017 at 11:27 AM, ron minnich <rminn...@gmail.com >> <mailto:rminn...@gmail.com>> wrote: >> >> I wonder if anyone is going to completely trust AMT after >> this problem. It goes back almost 10 years. So for all those >> users who had it on for almost 10 years, the question >> becomes, how much did we lose and when did we lose it? The >> answer? We'll never know. Are we still owned? We don't know. >> Can we actually trust any reflash procedure, if the ME is >> owned while we try to reflash? Well, I hope so, but how can >> we know? >> >> It's a worrisome situation. >> >> ron >> >> On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot >> <coreboot@coreboot.org <mailto:coreboot@coreboot.org>> wrote: >> >> Semi-Accurate only claims accuracy according to what's on >> the box. The >> official documentation of the issue can be found at >> >> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 >> >> <https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075> >> >> It looks like a software bug in the AMT firmware. Therefore: >> - No AMT (eg on non-business consumer devices) -> no (bug >> | exploit). >> - Present but disabled AMT (eg. on business devices >> without AMT >> enrollment) -> no (bug | exploit). (although there's >> apparently a way >> to enable AMT unsupervised under some circumstances with >> some level of >> local access. or something.) >> >> >> Patrick >> >> 2017-05-02 19:31 GMT+02:00 John Lewis >> <jle...@johnlewis.ie <mailto:jle...@johnlewis.ie>>: >> > >> >> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ >> >> <https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/> >> > >> > The article says "all" Intel boards since 2008 are >> locally vulnerable >> > (ME exploit), but the Intel advisory (linked within) >> says consumer >> > devices are okay. >> > >> > What the article says about even low end devices still >> having the >> > features albeit turned "off" rings true to me, based on >> stuff I've read >> > here and elsewhere. What's your take (bearing in mind >> the technical >> > details aren't available, yet)? >> > >> > >> > -- >> > coreboot mailing list: coreboot@coreboot.org >> <mailto:coreboot@coreboot.org> >> > https://mail.coreboot.org/mailman/listinfo/coreboot >> <https://mail.coreboot.org/mailman/listinfo/coreboot> >> >> >> >> -- >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der >> Gesellschaft: Hamburg >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence >> Manicle >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> <mailto:coreboot@coreboot.org> >> https://mail.coreboot.org/mailman/listinfo/coreboot >> <https://mail.coreboot.org/mailman/listinfo/coreboot> >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> <mailto:coreboot@coreboot.org> >> https://mail.coreboot.org/mailman/listinfo/coreboot >> <https://mail.coreboot.org/mailman/listinfo/coreboot> >> >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> <mailto:coreboot@coreboot.org> >> https://mail.coreboot.org/mailman/listinfo/coreboot >> <https://mail.coreboot.org/mailman/listinfo/coreboot> >> >> >> >> >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot