+1, that is another point Rob. When I started this thread my main interest was disk and then firmware. It is clear we really need to have a clear discussion on this, as imho I would not be supportive or lease baremetal to tenants if I can not guarantee the service, otherwise the cost of risking tenants to adverse attacks and data screening are far greater that the revenue generated from the service. When it comes to the tenants in our DC we consider all tenants need to be provided a guarantee of the baremetal service on the disk, loaders etc etc, otherwise its difficult to assure your customer.
/Alan -----Original Message----- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: January-18-14 12:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
