Youness Alaoui wrote:
avoid any malware writing to the flash
Just disallow flash writes by the platform. Allow flash writes only by dedicated hardware (maybe ChromeEC?) which implements a simple and efficient security protocol.
Looking for a software solution is IMO like Intel trying to secure SMM.
//Peter
On 28/09/2018, Peter Stuge peter@stuge.se wrote:
Youness Alaoui wrote:
avoid any malware writing to the flash
Just disallow flash writes by the platform. Allow flash writes only by dedicated hardware (maybe ChromeEC?) which implements a simple and efficient security protocol.
Relevant URL: https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect
Looking for a software solution is IMO like Intel trying to secure SMM.
Hear, hear!
On 9/28/18 1:30 AM, Peter Stuge wrote:
Youness Alaoui wrote:
avoid any malware writing to the flash
Just disallow flash writes by the platform. Allow flash writes only by dedicated hardware (maybe ChromeEC?) which implements a simple and efficient security protocol.
It's not as easy as you might think. You are looking forward to an additional flash chip at least because the ME needs direct access to a SPI flash (you could try to route that through the EC as well, but that would be everything but simple). Then your customers might ask for suspend-to-RAM, for which you need to cache memory-training data somewhere. You can't authenticate this data to the EC. That's solvable too, ofc. But there might be more pitfalls. And I'm not convinced that you'd end up with a simpler solution than your host firmware flipping a bit at the right point in time.
Looking for a software solution is IMO like Intel trying to secure SMM.
No matter if you run it on the EC or the host processor, it will be a software solution. You can make things simpler with a dedicated control- ler, right. But if you succeed still depends on the skills of software developers. ECs can be attacked too (especially if they have a host interface for software updates).
Nico
-
Nico Huber -
Peter Stuge -
Sam Kuper