pith. sign in

arxiv: 1907.07627 · v1 · pith:JAF5V35Qnew · submitted 2019-07-13 · 💻 cs.DC · cs.CR

A Secure Cloud with Minimal Provider Trust

Amin Mosayyebzadeh , Gerardo Ravago , Apoorve Mohan , Ali Raza , Sahil Tikale , Nabil Schear , Trammell Hudson , Jason Hennessey
show 7 more authors
Naved Ansari Kyle Hogan Charles Munson Larry Rudolph Gene Cooperman Peter Desnoyers Orran Krieger
This is my paper

Pith reviewed 2026-05-24 21:37 UTC · model grok-4.3

classification 💻 cs.DC cs.CR
keywords bare metal cloudcloud securityattestationminimal provider trusttenant isolationsecure provisioning
0
0 comments X

The pith

Bolted architecture lets tenants isolate bare-metal servers and attest firmware before network access in clouds.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents Bolted as a bare metal cloud architecture designed to offer security-sensitive customers the same security level as private data centers. Tenants can allocate resources elastically while protected from other tenants through server isolation during provisioning. Communication is only enabled after the tenant attests the critical firmware and software. This allows tenants to manage their own security, price, and performance choices. A prototype implementation shows the approach scales with minimal overhead.

Core claim

Bolted is a new architecture for a bare metal cloud that provides security-sensitive customers the same level of security and control as in their own private data centers by isolating bare metal servers upon provisioning and only allowing communication once critical firmware and software are attested to the tenant.

What carries the argument

The provisioning mechanism that isolates a bare metal server to a tenant and enforces attestation of firmware and software prior to enabling communication with other servers.

If this is right

  • Tenants are protected from previous, current, and future tenants in the cloud.
  • Tenants control the tradeoffs between security, price, and performance rather than the provider.
  • The system achieves scalable end-to-end security with small overhead compared to less secure alternatives.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • This model reduces the need for organizations to maintain separate private data centers for sensitive workloads.
  • It could influence how cloud providers design multi-tenant isolation mechanisms.
  • Extensions might include support for dynamic attestation during runtime.

Load-bearing premise

The cloud provider will correctly isolate the bare metal server initially and will not bypass or interfere with the attestation process afterward.

What would settle it

If it can be shown that the provider is able to allow communication between servers before attestation completes or bypass the isolation, the security claims would not hold.

Figures

Figures reproduced from arXiv: 1907.07627 by Ali Raza, Amin Mosayyebzadeh, Apoorve Mohan, Charles Munson, Gene Cooperman, Gerardo Ravago, Jason Hennessey, Kyle Hogan, Larry Rudolph, Nabil Schear, Naved Ansari, Orran Krieger, Peter Desnoyers, Sahil Tikale, Trammell Hudson.

Figure 1
Figure 1. Figure 1: Bolted’s architecture: Blue arrows show state [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Performance with and without Bolted for systems [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Scaling Results [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
read the original abstract

Bolted is a new architecture for a bare metal cloud with the goal of providing security-sensitive customers of a cloud the same level of security and control that they can obtain in their own private data centers. It allows tenants to elastically allocate secure resources within a cloud while being protected from other previous, current, and future tenants of the cloud. The provisioning of a new server to a tenant isolates a bare metal server, only allowing it to communicate with other tenant's servers once its critical firmware and software have been attested to the tenant. Tenants, rather than the provider, control the tradeoffs between security, price, and performance. A prototype demonstrates scalable end-to-end security with small overhead compared to a less secure alternative.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper proposes Bolted, an architecture for bare-metal clouds in which tenants elastically allocate isolated servers that are attested for firmware and software before being allowed to communicate with other tenant resources. The design aims to give tenants the same security and control as a private data center while letting them manage security-price-performance trade-offs; a prototype is reported to achieve scalable end-to-end security with modest overhead relative to a less-secure baseline.

Significance. If the security properties hold, the work would meaningfully reduce the trust placed in cloud providers for sensitive workloads and demonstrate a practical path for attested bare-metal multi-tenancy. The existence of a working prototype is a concrete strength that supports feasibility claims.

major comments (2)
  1. [Abstract, §3] Abstract and §3 (architecture description): the provisioning sequence states that the provider first isolates the bare-metal server and only afterward allows attestation by the tenant. Because isolation is a prerequisite for the subsequent attestation step, a provider that supplies a non-isolated server or one whose network configuration can be altered after hand-off can violate the claimed protection from other tenants before any tenant-controlled attestation occurs. This dependency appears load-bearing for the central 'minimal provider trust' claim.
  2. [§4] §4 (attestation and isolation mechanisms): no mechanism is described that would allow a tenant to verify that the initial network isolation was performed correctly by the provider, independent of the provider's firmware or hypervisor. Without such a check, the attestation of firmware and software cannot retroactively enforce isolation that was never established.
minor comments (1)
  1. [Abstract] The abstract refers to 'other tenant's servers' (possessive) where 'other tenants' servers' is intended; this should be corrected for clarity.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments highlighting potential ambiguities in the trust model and verification steps. We address each major comment below and will revise the manuscript to improve clarity on these points.

read point-by-point responses

  1. Referee: [Abstract, §3] Abstract and §3 (architecture description): the provisioning sequence states that the provider first isolates the bare-metal server and only afterward allows attestation by the tenant. Because isolation is a prerequisite for the subsequent attestation step, a provider that supplies a non-isolated server or one whose network configuration can be altered after hand-off can violate the claimed protection from other tenants before any tenant-controlled attestation occurs. This dependency appears load-bearing for the central 'minimal provider trust' claim.

    Authors: We agree that the initial isolation step is performed by the provider and precedes tenant attestation; this sequence is required for practical allocation of bare-metal resources. The architecture's minimal-trust claim rests on the assumption that the provider correctly executes the documented isolation protocol at provisioning time, after which tenant-controlled attestation and ongoing monitoring limit further provider actions. We will revise §3 to explicitly enumerate the trust assumptions for the initial isolation step, including the hardware mechanisms used and the consequences if isolation is not performed as specified. revision: yes

  2. Referee: [§4] §4 (attestation and isolation mechanisms): no mechanism is described that would allow a tenant to verify that the initial network isolation was performed correctly by the provider, independent of the provider's firmware or hypervisor. Without such a check, the attestation of firmware and software cannot retroactively enforce isolation that was never established.

    Authors: The current manuscript does not describe an independent tenant-side verification of the provider's initial network isolation that operates outside the attested firmware and hypervisor. Attestation occurs after isolation and confirms the resulting system state, but it cannot retroactively prove that isolation was correctly established if the provider's configuration step was faulty. We will revise §4 to add an explicit discussion of this limitation in the trust model and, where possible, describe any hardware-level isolation primitives that could be attested as part of the firmware state. revision: yes

Circularity Check

0 steps flagged

Architectural proposal; no derivations or equations present

full rationale

The paper presents a system architecture (Bolted) for bare-metal cloud isolation and attestation. No equations, fitted parameters, predictions, or first-principles derivations appear in the provided abstract or description. The content is an engineering design proposal whose claims rest on the described mechanisms rather than any mathematical reduction to inputs. No self-citation chains, ansatzes, or renamings of known results are invoked in a load-bearing way. The architecture is therefore self-contained against the circularity criteria; the reader's score of 0.0 is confirmed.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review yields no visible free parameters, axioms, or invented entities; no technical details on modeling choices or new constructs are supplied.

pith-pipeline@v0.9.0 · 5698 in / 1019 out tokens · 21577 ms · 2026-05-24T21:37:56.745363+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

52 extracted references · 52 canonical work pages · 2 internal anchors

  1. [1]

    https://github.com/CCI-MOC/hil

    hil: Hardware Isolation Layer, formerly Hardware as a Service. https://github.com/CCI-MOC/hil

    work page

  2. [2]

    https://github.com/CCI-MOC/M2

    Malleable Metal as a Service (M2). https://github.com/CCI-MOC/M2

    work page

  3. [3]

    https://github.com/corna/mecleaner

    me cleaner: T ool for partial deblobbing of intel me/txe firmware images. https://github.com/corna/mecleaner

    work page

  4. [4]

    https://github.com/mit-ll/python-keylime

    python-keylime: Bootstrapping and Maintaining Trust in the Cloud. https://github.com/mit-ll/python-keylime

    work page

  5. [5]

    https: //trustedcomputinggroup.org/trusted-platform-module-tpm-summary/, Apr

    Trusted Platform Module (TPM) Summary. https: //trustedcomputinggroup.org/trusted-platform-module-tpm-summary/, Apr. 2008

    work page 2008

  6. [6]

    http://www.hypeorripe.com/2013/11/13/4-major- reasons-some-organizations-are-still-reluctant-to-move-to-the-cloud, 2013

    4 major reasons some organizations are still reluctant to move to the cloud|Logicalis. http://www.hypeorripe.com/2013/11/13/4-major- reasons-some-organizations-are-still-reluctant-to-move-to-the-cloud, 2013

    work page 2013

  7. [7]

    https://www.iarpa.gov/index.php/working-with-iarpa/requests-for- information/creating-a-classified-processing-enclave-in-the-public- cloud, 2017

    Creating a Classified Processing Enclave in the Public Cloud|IARP A. https://www.iarpa.gov/index.php/working-with-iarpa/requests-for- information/creating-a-classified-processing-enclave-in-the-public- cloud, 2017

    work page 2017

  8. [8]

    https://itmodernization.cio.gov/, 2017

    Report to the President on Federal IT Modernization - Introduction to the Report. https://itmodernization.cio.gov/, 2017

    work page 2017

  9. [9]

    S., H IBLER , M., S TOLLER , L., S TACK, T., AND LEPREAU , J

    ANDERSON , D. S., H IBLER , M., S TOLLER , L., S TACK, T., AND LEPREAU , J. Automatic online validation of network configuration in the emulab network testbed. InAutonomic Computing, 2006. ICAC’06. IEEE International Conference on(2006), IEEE, pp. 134–142

    work page 2006

  10. [10]

    Software Grand Exposure: SGX Cache Attacks Are Practical

    BRASSER , F., M ¨ULLER , U., D MITRIENKO , A., K OSTIAINEN , K., CAPKUN , S., AND SADEGHI , A. Software grand exposure: SGX cache attacks are practical.CoRR abs/1702.07521(2017)

    work page internal anchor Pith review Pith/arXiv arXiv 2017

  11. [11]

    Getting Cyber Serious: Mastering the Challenges of Federal Cloud Computing

    BUCCI, S. Getting Cyber Serious: Mastering the Challenges of Federal Cloud Computing. The Heritage F oundation

    work page

  12. [12]

    Summary of attacks against BIOS and secure boot

    BULYGIN, Y ., LOUCAIDES , J., F URTAK, A., B AZHANIUK , O., AND MATROSOV, A. Summary of attacks against BIOS and secure boot. Defcon-22(2014)

    work page 2014

  13. [13]

    BIOS Chronomancy: Fixing the core root of trust for measurement

    B UTTERWORTH , J., K ALLENBERG , C., K OV AH, X., AND HERZOG , A. BIOS Chronomancy: Fixing the core root of trust for measurement. In Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security(New Y ork, NY , USA, 2013), CCS ’13, ACM, pp. 25–36

    work page 2013

  14. [14]

    Metal as a service

    C ANONICAL . Metal as a service. urlhttps://maas.ubuntu.com/

    work page

  15. [15]

    A Trusted Cloud Solution from HyTrust, VMware, and Intel

    CORPORATION , I. A Trusted Cloud Solution from HyTrust, VMware, and Intel. https://www.intel.com/content/www/us/en/cloud- computing/path-to-secure-compliant-trusted-cloud-brief.html, 2016

    work page 2016

  16. [16]

    Sanctum: Minimal hardware extensions for strong software isolation

    COSTAN, V ., LEBEDEV, I., AND DEV ADAS, S. Sanctum: Minimal hardware extensions for strong software isolation. InUSENIX Security (2016), vol. 16, pp. 857–874

    work page 2016

  17. [17]

    DER VEEN ET AL ., D. V . Openstack ironic wiki. url- https://wiki.openstack.org/wiki/Ironic

    work page

  18. [18]

    How to hack a turned - off computer, or running unsigned code in intel management engine

    ERMOLOV, M., AND GORYACHY, M. How to hack a turned - off computer, or running unsigned code in intel management engine. https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy- How-T o-Hack-A-Turned-Off-Computer-Or-Running-Unsigned- Code-In-Intel-Management-Engine.pdf, Dec 2017

    work page 2017

  19. [19]

    tgt: Framework for storage target drivers

    FUJITA, T., AND CHRISTIE , M. tgt: Framework for storage target drivers. InProceedings of the Linux Symposium(2006), vol. 1, Citeseer, pp. 303–312

    work page 2006

  20. [20]

    Rootkit threats.Network Security 2006, 1 (2006), 18–19

    HEASMAN , J. Rootkit threats.Network Security 2006, 1 (2006), 18–19

    work page 2006

  21. [21]

    U., H ILL, C., DESNOYERS , P., AND KRIEGER , O

    HENNESSEY, J., T IKALE , S., T URK, A., K AYNAR, E. U., H ILL, C., DESNOYERS , P., AND KRIEGER , O. HIL: Designing an exokernel for the data center. InProceedings of the 7th ACM Symposium on Cloud Computing (SoCC’16)(Santa Clara, CA, Oct. 2016)

    work page 2016

  22. [22]

    heads: A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops and servers

    HUDSON , T. heads: A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops and servers. https://github.com/osresearch/heads

    work page

  23. [23]

    Heads W ebpage

    H UDSON , T. Heads W ebpage. https://trmm.net/Heads

    work page

  24. [24]

    ThunderStrike 2: Sith Strike

    HUDSON , T., K OV AH, X., AND KALLENBERG , C. ThunderStrike 2: Sith Strike. Black Hat USA Briefings(2015)

    work page 2015

  25. [25]

    Thunderstrike: EFI firmware bootkits for Apple Macbooks

    HUDSON , T., AND RUDOLPH , L. Thunderstrike: EFI firmware bootkits for Apple Macbooks. In Proceedings of the 8th ACM International Systems and Storage Conference(2015), ACM, p. 15

    work page 2015

  26. [26]

    802.1q-2014 - bridges and bridged networks

    IEEE. 802.1q-2014 - bridges and bridged networks. http://www.ieee802.org/1/pages/802.1Q-2014.html

    work page 2014

  27. [27]

    INC., A. W. S. Amazon EC2 Bare Metal Instances with Direct Access to Hardware. https://aws.amazon.com/blogs/aws/new-amazon-ec2- bare-metal-instances-with-direct-access-to-hardware/, 2017

    work page 2017

  28. [28]

    Bare-metal AgileSER VER

    INTERNAP . Bare-metal AgileSER VER. http://www.internap.com/bare- metal/, 2015

    work page 2015

  29. [29]

    T., AND CHEN, P

    KING, S. T., AND CHEN, P. M. Subvirt: Implementing malware with virtual machines. InSecurity and Privacy, 2006 IEEE Symposium on (2006), IEEE, pp. 14–pp

    work page 2006

  30. [30]

    Destroying your hard drive is the only way to stop this super-advanced malware

    KIRK, J. Destroying your hard drive is the only way to stop this super-advanced malware. https://www.pcworld.com/article/2884952/ equation-cyberspies-use-unrivaled-nsastyle-techniques-to-hit-iran- russia.html, Feb 2015

    work page arXiv 2015

  31. [31]

    Spectre attacks: Exploiting speculative execution.ArXiv e-prints(Jan

    KOCHER , P., G ENKIN , D., G RUSS, D., H AAS, W., H AMBURG , M., L IPP, M., M ANGARD , S., P RESCHER , T., S CHWARZ, M., AND YAROM, Y . Spectre attacks: Exploiting speculative execution.ArXiv e-prints(Jan. 2018)

    work page 2018

  32. [32]

    Tpm and intel ptt overview

    KROIZER , A. Tpm and intel ptt overview. http://tce.webee. eedev.technion.ac.il/wp-content/uploads/sites/8/2016/01/AKTPM- overview-technion.pdf, Sep 2015

    work page 2016

  33. [33]

    Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing

    LEE, S., S HIH, M., G ERA, P., K IM, T., K IM, H., AND PEINADO , M. Inferring fine-grained control flow inside SGX enclaves with branch shadowing. CoRR abs/1611.06952(2016)

    work page internal anchor Pith review Pith/arXiv arXiv 2016

  34. [34]

    Meltdown

    LIPP, M., S CHWARZ, M., G RUSS, D., P RESCHER , T., H AAS, W., M ANGARD , S., K OCHER , P., G ENKIN , D., Y AROM, Y ., AND HAMBURG , M. Meltdown. ArXiv e-prints(Jan. 2018)

    work page 2018

  35. [35]

    LIU, F., YAROM, Y ., GE, Q., H EISER , G., AND LEE, R. B. Last-level cache side-channel attacks are practical. In2015 IEEE Symposium on Security and Privacy(May 2015), pp. 605–622

    work page 2015

  36. [36]

    S., T IKALE , S., H EN- NESEY, J., K AYNAR, U., C OOPERMAN , G., D ESNOYERS , P., AND KRIEGER , O

    MOHAN, A., T URK, A., G UDIMETLA , R. S., T IKALE , S., H EN- NESEY, J., K AYNAR, U., C OOPERMAN , G., D ESNOYERS , P., AND KRIEGER , O. M2: Malleable Metal as a Service. In 2018 IEEE International Conference on Cloud Engineering (IC2E)(April 2018), pp. 61–71

    work page 2018

  37. [37]

    A penetration tester’s guide to ipmi and bmcs

    MOORE, H. A penetration tester’s guide to ipmi and bmcs. https: //blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/, Aug 2017

    work page 2013

  38. [38]

    Bypassing IOMMU protection against I/O attacks

    MORGAN , B., A LATA, E., N ICOMETTE , V ., AND KANICHE , M. Bypassing IOMMU protection against I/O attacks. In2016 Seventh Latin-American Symposium on Dependable Computing (LADC)(Oct 2016), pp. 145–150

    work page 2016

  39. [39]

    NEWMAN , L. H. Intel chip flaws leave millions of devices exposed. https://www.wired.com/story/intel-management-engine- vulnerabilities-pcs-servers-iot/, Nov 2017

    work page 2017

  40. [40]

    spectre-attack-sgx

    O’KEEFFE , D., M UTHUKUMARAN , D., A UBLIN , P.-L., K EL- BERT, F., P RIEBE , C., L IND, J., Z HU, H., AND PIETZUCH , P. spectre-attack-sgx. https://github.com/lsds/spectre-attack-sgx

    work page

  41. [41]

    The promise of the cloud delivered on bare metal

    PACKET. The promise of the cloud delivered on bare metal. https://www.packet.net, 2017

    work page 2017

  42. [42]

    T., AND WILSON , S

    PAQUETTE , S., J AEGER , P. T., AND WILSON , S. C. Identifying the security risks associated with governmental use of cloud computing. Government Information Quarterly 27, 3 (July 2010), 245–253

    work page 2010

  43. [43]

    Rackspace Cloud Big Data OnMetal

    RACKSPACE. Rackspace Cloud Big Data OnMetal. http://go.rackspace.com/baremetalbigdata/, 2015

    work page 2015

  44. [44]

    Flip Feng Shui: Hammering a needle in the software stack

    RAZA VI, K., G RAS, B., B OSMAN , E., P RENEEL , B., G IUFFRIDA , C., AND BOS, H. Flip Feng Shui: Hammering a needle in the software stack

    work page

  45. [45]

    Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds

    RISTENPART, T., T ROMER, E., S HACHAM , H., AND SA V AGE, S. Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds. InProceedings of the 16th ACM conference on Computer and communications security(2009), ACM, pp. 199–212

    work page 2009

  46. [46]

    Intel x86 considered harmful, 2015

    RUTKOWSKA , J. Intel x86 considered harmful, 2015. https://blog.invisiblethings.org/papers/2015/x86harmful.pdf

    work page 2015

  47. [47]

    T., M OYER, T

    SCHEAR , N., C ABLE, II, P. T., M OYER, T. M., R ICHARD , B., AND RUDD, R. Bootstrapping and maintaining trust in the cloud. InProceed- ings of the 32Nd Annual Conference on Computer Security Applications (New Y ork, NY , USA, 2016), ACSAC ’16, ACM, pp. 65–77

    work page 2016

  48. [48]

    Big data solutions

    SOFTLAYER. Big data solutions. http://www.softlayer.com/big-data, 2015

    work page 2015

  49. [49]

    M., AND LINTENHOFER , D.-I

    WAGNER, H., Z ACH, D.-I. M., AND LINTENHOFER , D.-I. F. M. A.-P. BIOS-rootkit LightEater

    work page

  50. [50]

    A., B RANDT, S

    WEIL, S. A., B RANDT, S. A., M ILLER , E. L., L ONG, D. D., AND MALTZAHN, C. Ceph: A scalable, high-performance distributed file system. In Proceedings of the 7th symposium on Operating systems design and implementation(2006), USENIX Association, pp. 307–320

    work page 2006

  51. [51]

    Attacking intel trusted execution technology.Black Hat DC(2009)

    WOJTCZUK , R., AND RUTKOWSKA , J. Attacking intel trusted execution technology.Black Hat DC(2009)

    work page 2009

  52. [52]

    Controlled-channel attacks: Deterministic side channels for untrusted operating systems

    XU, Y ., CUI, W., AND PEINADO , M. Controlled-channel attacks: Deterministic side channels for untrusted operating systems. InProceed- ings of the 36th IEEE Symposium on Security and Privacy (Oakland) (May 2015), IEEE Institute of Electrical and Electronics Engineers

    work page 2015