Just sharing a little reading... https://boingboing.net/2016/06/15/intel-x86-processors-ship-with.html
That seems to be quite misleading article. It fails to tell clearly that AMT is not a problem for normal consumer CPUs (at least this is what I've read elsewhere).
A lof of conflicting information about AMT. That article claims that AMT is "Built into every modern Intel-based PC" when e.g. this article on ssh.com says that "it is included in all modern Intel Xeon processors and associated chipsets" i.e. not in consumer PCs.
Short answer: Most of the ATOM processors such as the Braswell used in UDOO x86 do not have AMT capability, this include N3160 and N3710. I.e., case closed. VERY VERY Loooong answer (do not need to read and do not complain then) (1) view AMT as a group of technologies, main feature in AMT is about remote management (recent vulnerability found is related to remote management) (2) usually the client class (desktop, laptop) mainstream CPUs will use the same CPU/SoC's built-in standard Ethernet controller, as shared Ethernet port. If AMT is enabled in BIOS, two IP addresses will show up (one is the ordinary one and the other is the AMT mgmt Ethernet IP.) In server class CPU, AMT usually uses a separate AMT Ethernet port (if you unplug cable on that port, AMT feature is no longer accessible.) (3) In the case of Braswell such as N3160, there is no Ethernet controller in its SoC. The Ethernet controller is a separate chip: Realtek RT8111, thus there is no way AMT can even reach the Braswell SoC at all. (4) Intel has been using a separate microcontroller to assist the main CPU for years. It performs many tasks. AMT is just one of them, if the CPU's SKU supports such feature. Such controller used to live inside MCH (south bridge), later combined and moved into PCH (platform control hub), and nowadays, move into the CPU SoC package itself. (5) that microprocessor runs a special ROM code stored/burned-in inside the SoC package as well as used in combination with a special code section (protected and encrypted) of the SPI BIOS chip. (6) all these are Intel proprietary. Many had attempted to get into but failed. The one who succeeded won't talk anyway.
@ccs_hello thanks for long answer that may interest you http://me.bios.io/images/5/5c/Attacking_Intel_BIOS.pdf they succesfully flash from cpu the AMT chip out of cpu using bogus uefi update entry check... I was wondering... what could forbid that on udoo ? isn't there devices able to be flashed everywhere on soc or sbc? https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr =>> it seems concern more than the amt stuff: vpro, ist, ime? and I'll edit the topic name cause yeah its was misleading
What forbids that on UDOO is the fact that AMT does not exist on the chips SECO installs on the boards. Just like @ccs_hello already stated. AMT is a part of vPro which the UDOO processors don't have. IME is a part of AMT. IST is also something the UDOO processors do not have. There is no concern.
But couldnt the stm be flashed with something nasty using the cpu while the O.S is running? I'll have a look to the smbus spec then I may come back with other THEORICALS questions Edit: bios is in a N25Q064A11E chip pcu isp talk based
BIOS SPI ROM 25Q064 is on its own dedicated and isolated bus to communicate with the Braswell CPU/SoC. STM32 is using a common SMbus (system mgmt bus) to communicate with the Braswell. It is mainly used for housekeeping function for the UDOO x86 system's submodules. It does not touch the sensitive/critical data paths. About the STM32 itself, its normal programming path is thru CN23 JTAG connector to be reflashed. There may be another way but I'll leave it to UDOO x86 engineers to worry about. ccs_hello
