On 05/08/2017 12:40 AM, ron minnich wrote:
I thought the whole reflash path of AMT was to ask it to reflash itself. Is that incorrect? If correct, and the AMT has been exploited via this path, can we really trust any reflash operation? Any thoughts on this from anyone who knows?
Yeah its a request, that can be denied or stealth-denied so it can't be trusted. I had a BIOS update on an older intel board go wrong as I had set in the ME OPROM "Firmware Update" to "Deny" it would be very simple to mess with the ME region re-writer programmer to re-add a backdoor to every internal flashed image, and how many corps actually flash externally? (none I assume)
I was involved in some USG issues around the time of Y2K and at least one agency shredded every non-Y2K-compliant system they had. Would that make sense for systems with this AMT vulnerability? Just assume the worst and destroy them?
I guess you can always re-flash externally, I don't think even a nation state has figured out the magic to get a regular flash EEPROM to stealth-deny writes (have they? :0)
I am long past believing one can build secure platforms on any x86 chipset. This mess only strengthens that conviction. But there are some great RISC-V announcements this week!
What about pre-PSP AMD? as 95% of the way there - with POWER as 100% if you get a fully open source, blob free machine like the palmetto or with a little work the firestone.
On 05/09/2017 05:26 PM, Taiidan@gmx.com wrote:
On 05/08/2017 12:40 AM, ron minnich wrote:
I am long past believing one can build secure platforms on any x86 chipset. This mess only strengthens that conviction. But there are some great RISC-V announcements this week!
How come risv-v has no DMA security features? ala IOMMU? if you want to do virtualization that is also a must have due to the performance differential - you couldn't push 1gbps on a emulated NIC without serious processing power.
I wish intel/amd had done their supervisor PU's as removable modules like a hardware TPM, for security (theater) they could have a fuse on the CPU that if blown will require the device to be present for the computer to boot up but otherwise it isn't required at all. Easy way to satisfy everyone.
On Tue, May 9, 2017 at 3:25 PM Taiidan@gmx.com Taiidan@gmx.com wrote:
How come risv-v has no DMA security features? ala IOMMU? if you want to do virtualization that is also a must have due to the performance differential - you couldn't push 1gbps on a emulated NIC without serious processing power.
well, because they are in their very first years, and survival is job 1, followed some time later by achieving high end performance.
And, further, if you look at lowrisc, it's not even clear you want a dma engine. maybe a core running one and only one kernel thread that moves data is what you want.
But we'll see. One thing at a time. Survival ahead of everything else.
On 10.05.2017 00:25, Taiidan@gmx.com wrote:
On 05/09/2017 05:26 PM, Taiidan@gmx.com wrote:
On 05/08/2017 12:40 AM, ron minnich wrote:
I am long past believing one can build secure platforms on any x86 chipset. This mess only strengthens that conviction. But there are some great RISC-V announcements this week!
How come risv-v has no DMA security features? ala IOMMU? if you want to do virtualization that is also a must have due to the performance differential - you couldn't push 1gbps on a emulated NIC without serious processing power.
Simple, RISC-V is an ISA, IOMMU is not an ISA concept. If somebody builds an SoC with RISC-V and doesn't implement an IOMMU between the memory bus and peripherals, ask him why he didn't. Of course, there could be an IOMMU standard, but would it have to be RISC-V specific?
Nico
I wish intel/amd had done their supervisor PU's as removable modules like a hardware TPM, for security (theater) they could have a fuse on the CPU that if blown will require the device to be present for the computer to boot up but otherwise it isn't required at all. Easy way to satisfy everyone.
-
Nico Huber -
ron minnich -
Taiidan＠gmx.com