The Making of OnMetal(scalescale.com)
scalescale.com
The Making of OnMetal
http://www.scalescale.com/the-making-of-onmetal/
3 comments
Still want to know how they're mitigating firmware attacks :)
I'd like us (Rackspace) to publish a full whitepaper about what we have done, but I'll break down things into two topical areas:
1) Requiring signing of all firmwares, and putting those firmware private keys in control of Rackspace whenever possible.
2) Disabling systems of integration between the BMC and Operating system -- for example we completely disable the HECI bus, removing a major surface area for the operating system to affect the BMC.
1) Requiring signing of all firmwares, and putting those firmware private keys in control of Rackspace whenever possible.
2) Disabling systems of integration between the BMC and Operating system -- for example we completely disable the HECI bus, removing a major surface area for the operating system to affect the BMC.
Thanks for the reply :)
I suspect an ideal state to be in would be that there was no firmware flashing at all, the various bits of hardware would have some version of the firmware in ROM and could load a replacement firmware into RAM, but never be able to store that in a PROM, thus guaranteeing that no malicious code could ever persist between tenants. Probably a lot harder to arrange with hardware people though.
I guess my concern with signed firmware is that it's increasing the attack surface of the firmware by adding in crypto code. Identifying malicious code is going to be hard enough to start with, let alone hunting down its attack vector, let alone getting a decent fix from some vendor in a useful timeframe!
I suspect an ideal state to be in would be that there was no firmware flashing at all, the various bits of hardware would have some version of the firmware in ROM and could load a replacement firmware into RAM, but never be able to store that in a PROM, thus guaranteeing that no malicious code could ever persist between tenants. Probably a lot harder to arrange with hardware people though.
I guess my concern with signed firmware is that it's increasing the attack surface of the firmware by adding in crypto code. Identifying malicious code is going to be hard enough to start with, let alone hunting down its attack vector, let alone getting a decent fix from some vendor in a useful timeframe!
was firmware signing a big factor in the decision to go with OCP hardware?
thanks for telling the story. it is encouraging for us as we are bringing up ironic support ourselves.
thanks for telling the story. it is encouraging for us as we are bringing up ironic support ourselves.
Strictly speaking, you can get traditional vendors to do firmware signing -- but getting them to put your public key in there will be more difficult, with volume most of the big vendors will be... accommodating.
Dell's 12th generation PowerEdge for example has a pretty good baseline outlined here:
http://en.community.dell.com/cfs-file.ashx/__key/telligent-e...
But that only covers the BIOS really, not things like firmwares in different PCI cards. But its a start.
Dell's 12th generation PowerEdge for example has a pretty good baseline outlined here:
http://en.community.dell.com/cfs-file.ashx/__key/telligent-e...
But that only covers the BIOS really, not things like firmwares in different PCI cards. But its a start.
Can you guys do a DB machine type with more RAM? 128Gb isn't enough. :)
We've gotten this request a few times, can you elaborate on why you need so much RAM? How much is enough?
So that most of our hot data fits in RAM? I would expect the type of machine you guys are selling to come with 256Gb standard, to be honest (and the cost of another 128Gb of RAM is negligible -- I'd pay a couple more $ per day or whatever for it).
[deleted]
OnMetal Compute v1 - comes out as $560 per month which is not that expensive at all for a 10 cores instance!