[openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Fox, Kevin M Kevin.Fox at pnnl.gov
Thu Jan 16 17:29:14 UTC 2014

Yeah, I think the evil firmware issue is separate and should be solved separately.

Ideally, there should be a mode you can set the bare metal server into where firmware updates are not allowed. This is useful to more folks then just baremetal cloud admins. Something to ask the hardware vendors for.


From: CARVER, PAUL [pc2929 at att.com]
Sent: Thursday, January 16, 2014 5:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance       blueprint       of cinder.

Clint Byrum wrote:

>Is that really a path worth going down, given that tenant-A could just
>drop evil firmware in any number of places, and thus all tenants afterward
>are owned anyway?

I think a change of subject line is in order for this topic (assuming it hasn't been discussed in sufficient depth already). I propose "[Ironic] Evil Firmware" but I didn't change it on this message in case folks interested in this thread aren't reading Ironic threads.

Ensuring clean firmware is definitely something Ironic needs to account for. Unless you're intending to say that multi-tenant bare metal is a dead end that shouldn't be done at all.

As long as anyone is considering Ironic and bare metal in general as a viable project and service it is critically important that people are focused on how to ensure that a server released by one tenant is "clean" before being provided to another tenant.

It doesn't even have to be "evil" firmware. Simply providing a tenant with a server where the previous tenant screwed up a firmware update or messed with BIOS settings or whatever is a problem. If you're going to lease bare metal out on a short term basis you've GOT to have some sort of QC to ensure that when the hardware is reused for another tenant it's as good as new.

If not, it will be all too common for a tenant to receive a bare metal server that's been screwed up by a previous tenant through incompetence as much as through maliciousness.

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list