On 18 January 2014 12:21, Chris Friesen <chris.frie...@windriver.com> wrote: > On 01/17/2014 04:20 PM, Devananda van der Veen wrote: > >> tl;dr, We should not be recycling bare metal nodes between untrusted >> tenants at this time. There's a broader discussion about firmware >> security going on, which, I think, will take a while for the hardware >> vendors to really address. > > > What can the hardware vendors do? Has anyone proposed a meaningful solution > for the firmware issue?
So historically, for 99% of users of new machines, it's been considered a super low risk right - they don't boot off of unknown devices, and they aren't reusing machines across different users. Second hand users had risks, but vendors aren't designing for the second hand purchaser. However more and more viruses are targeting lower and lower parts of the boot stack (see why UEFI is so important) and there are now multiple confirmations of hostile payloads that can live in hard disk drive microcontrollers - and some of the NSA payloads look like they inhabit system management bioses... - it's become clear that this is something that is a genuine risk for all users; new users from viruses and other malware, second hand users from the original user. So, industry wise, I think over the next few years folk will finish auditing their supply chain to determine what devices are at risk and then start implementing defenses. The basic problem though is that our entire machine architecture trusts that the rest of the machine is trusted (e.g. device can DMA anything they want... - one previous class of attack was compromised firewire devices - plugin, and they would disable your screen saver without password entry.) > Given the number of devices (NIC, GPU, storage controllers, etc.) that could > potentially have firmware update capabilities it's not clear to me how this > could be reliably solved. Slowly and carefully :) -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev