зеркало из https://github.com/microsoft/CCF.git
Remove SGX mentions from documentation (#6625)
This commit is contained in:
Amaury Chamayou
GitHub
Родитель
4f5d2553af
Коммит
ff3935439e
|
|
@ -27,7 +27,4 @@ Programming Model
|
|||
|
||||
To ensure session consistency all commands that originate from the same connection are executed on the same thread.
|
||||
It is strongly advised that during the execution of a command the application does not mutate any global state outside of the key-value store.
|
||||
Any inter-command communication must be performed via the key-value store, to ensure that CCF can rollback commands or change the primary as required.
|
||||
|
||||
If an application has global state that exists outside the key-value store, CCF offers several concurrency control primitives (via Open Enclave) to protect memory that could be accessed concurrently by multiple threads.
|
||||
It is recommended that these primitives are used rather than other primitives, such as mutexes, which may result in an OCALL.
|
||||
Any inter-command communication must be performed via the key-value store, to ensure that CCF can rollback commands or change the primary as required.
|
||||
|
|
@ -4,11 +4,9 @@ TLS Internals
|
|||
Overview
|
||||
~~~~~~~~
|
||||
|
||||
In CCF, the :term:`TLS` layer is implemented using OpenSSL 1.1.1 from :term:`Open Enclave` (OE). However, the original implementation was using OE's MbedTLS library, which the current implementation replaced. During the transition period, the OpenSSL implementation had to emulate the previous MbedTLS one and the remaining code isn't particularly suited to OpenSSL.
|
||||
In CCF, the :term:`TLS` layer is implemented using OpenSSL 1.1.1 or 3.1. However, the original implementation was using OE's MbedTLS library, which the current implementation replaced. During the transition period, the OpenSSL implementation had to emulate the previous MbedTLS one and the remaining code isn't particularly suited to OpenSSL.
|
||||
|
||||
In addition, we'll soon be adding :term:`QUIC` support to CCF, which has its own usage of TLS (supporting OpenSSL, but from its own tree).
|
||||
|
||||
This document is an attempt to describe how that works, so that we can plan a suited implementation for both TCP-based and QUIC-based endpoints using TLS.
|
||||
This document is an attempt to describe how that works, to faciliate further changes.
|
||||
|
||||
Enclave Connections
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -63,13 +61,9 @@ The main reasons why we moved to OpenSSL are:
|
|||
|
||||
- We already use OpenSSL for our crypto library ('src/crypto').
|
||||
- We wanted TLS 1.3 support and MbedTLS doesn't have it.
|
||||
- We want to support QUIC, that doesn't work with MbedTLS.
|
||||
- We wanted to support QUIC, which doesn't work with MbedTLS.
|
||||
|
||||
By now we have removed any traces of MbedTLS, but we are still using OE's OpenSSL library, which doesn't have QUIC support.
|
||||
|
||||
To implement the last point above, we need to build QUIC with its own OpenSSL and use that as our library for the remaining crypto, but OE has its own modifications to OpenSSL as well, and we can't have both.
|
||||
|
||||
So, for now, the only way to have QUIC support is in 'virtual' mode, retaining OE's OpenSSL for 'sgx' mode. Once we have other types of enclaves that don't require Open Enclave we can use QUIC's version, too.
|
||||
By now we have removed any traces of MbedTLS, but we are still using a version of OpenSSL which doesn't have QUIC support.
|
||||
|
||||
MbedTLS vs OpenSSL
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Identity, status and attestations (endorsed quotes) of the nodes hosting the net
|
|||
``nodes.code_ids``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Versions of the code allowed to join the current network on :doc:`SGX <../operations/platforms/sgx>`.
|
||||
DEPRECATED. Previously contained versions of the code allowed to join the current network on SGX hardware.
|
||||
|
||||
**Key** MRENCLAVE, represented as a base64 hex-encoded string (length: 64).
|
||||
|
||||
|
|
|
|||
|
|
@ -118,23 +118,23 @@ The ``ledger_code.py`` command line utility can be used to display the history o
|
|||
.. code-block:: bash
|
||||
|
||||
$ ledger_code.py -s /path/to/ledger/dir
|
||||
2.1 Introduced : [('OE_SGX_v1', '3258fb')]
|
||||
2.103 Introduced : [('OE_SGX_v1', '048b8c')]
|
||||
3.175 Removed : [('OE_SGX_v1', '3258fb')]
|
||||
2.1 Introduced : [('AMD_SEV_SNP_v1', '3258fb')]
|
||||
2.103 Introduced : [('AMD_SEV_SNP_v1', '048b8c')]
|
||||
3.175 Removed : [('AMD_SEV_SNP_v1', '3258fb')]
|
||||
|
||||
$ ledger_code.py -vs /path/to/ledger/dir
|
||||
2.1: {('OE_SGX_v1', '3258fb'): ['9b013f']}
|
||||
2.3: {('OE_SGX_v1', '3258fb'): ['9b013f', 'beb114']}
|
||||
2.5: {('OE_SGX_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4']}
|
||||
2.103: {('OE_SGX_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58']}
|
||||
2.119: {('OE_SGX_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a']}
|
||||
2.146: {('OE_SGX_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
2.152: {('OE_SGX_v1', '3258fb'): ['beb114', '6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.156: {('OE_SGX_v1', '3258fb'): ['beb114', '6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.165: {('OE_SGX_v1', '3258fb'): ['6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.168: {('OE_SGX_v1', '3258fb'): ['6ff2f4'], ('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.175: {('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
4.179: {('OE_SGX_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
2.1: {('AMD_SEV_SNP_v1', '3258fb'): ['9b013f']}
|
||||
2.3: {('AMD_SEV_SNP_v1', '3258fb'): ['9b013f', 'beb114']}
|
||||
2.5: {('AMD_SEV_SNP_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4']}
|
||||
2.103: {('AMD_SEV_SNP_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58']}
|
||||
2.119: {('AMD_SEV_SNP_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a']}
|
||||
2.146: {('AMD_SEV_SNP_v1', '3258fb'): ['9b013f', 'beb114', '6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
2.152: {('AMD_SEV_SNP_v1', '3258fb'): ['beb114', '6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.156: {('AMD_SEV_SNP_v1', '3258fb'): ['beb114', '6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.165: {('AMD_SEV_SNP_v1', '3258fb'): ['6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.168: {('AMD_SEV_SNP_v1', '3258fb'): ['6ff2f4'], ('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
3.175: {('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
4.179: {('AMD_SEV_SNP_v1', '048b8c'): ['3ebd58', '53cb2a', '1d1396']}
|
||||
|
||||
As with ``read_ledger.py``, non-committed ledger files are ignored, unless the ``--uncommitted`` command line argument is specified.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ The dependencies required to build and run CCF apps can be conveniently installe
|
|||
|
||||
.. tab:: Virtual
|
||||
|
||||
.. warning:: The `virtual` version of CCF can also be run on hardware that does not support SGX/SNP. Virtual mode does not provide any security guarantees and should be used for development purposes only.
|
||||
.. warning:: The `virtual` version of CCF can also be run on hardware that does not support SEV-SNP. Virtual mode does not provide any security guarantees and should be used for development purposes only.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -34,37 +34,7 @@ Installation from .deb
|
|||
|
||||
Alternatively, CCF releases are available on the `GitHub repository release page <https://github.com/microsoft/CCF/releases>`_.
|
||||
|
||||
The CCF Debian package (``ccf_<platform>_<version>_amd64.deb``) contains the libraries and utilities to start a CCF service and build CCF applications. CCF can be installed as follows, for the ``SGX``, ``SNP`` and ``Virtual`` platforms:
|
||||
|
||||
.. tab:: SGX
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Set CCF_VERSION to most recent LTS release
|
||||
$ export CCF_VERSION=$(curl -ILs -o /dev/null -w %{url_effective} https://github.com/microsoft/CCF/releases/latest | sed 's/^.*ccf-//')
|
||||
# Alternatively, set this manually, e.g.:
|
||||
# export CCF_VERSION=4.0.0
|
||||
$ wget https://github.com/microsoft/CCF/releases/download/ccf-${CCF_VERSION}/ccf_sgx_${CCF_VERSION}_amd64.deb
|
||||
$ sudo apt install ./ccf_sgx_${CCF_VERSION}_amd64.deb
|
||||
|
||||
.. tip:: A separate `unsafe` package (``ccf_sgx_unsafe_<version>_amd64.deb``) with extremely verbose logging is also provided for troubleshooting purposes. Its version always ends in ``unsafe`` to make it easily distinguishable. The extent of the logging in these packages mean that they cannot be relied upon to offer confidentiality and integrity guarantees. They should never be used for production purposes.
|
||||
|
||||
Assuming that CCF was installed under ``/opt``, the following commands can be run to verify that CCF was installed successfully:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/ccf_sgx/bin/cchost --version
|
||||
CCF host: ccf-<version>
|
||||
Platform: SGX
|
||||
|
||||
$ /opt/ccf_sgx/bin/sandbox.sh
|
||||
No package/app specified. Defaulting to installed JS logging app
|
||||
Setting up Python environment...
|
||||
Python environment successfully setup
|
||||
[16:10:16.552] Starting 1 CCF node...
|
||||
[16:10:23.349] Started CCF network with the following nodes:
|
||||
[16:10:23.350] Node [0] = https://127.0.0.1:8000
|
||||
...
|
||||
The CCF Debian package (``ccf_<platform>_<version>_amd64.deb``) contains the libraries and utilities to start a CCF service and build CCF applications. CCF can be installed as follows, for the ``SNP`` and ``Virtual`` platforms:
|
||||
|
||||
.. tab:: SNP
|
||||
|
||||
|
|
@ -142,12 +112,6 @@ Uninstall
|
|||
|
||||
To remove an installation of CCF, run:
|
||||
|
||||
.. tab:: SGX
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt remove ccf_sgx
|
||||
|
||||
.. tab:: SNP
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
@ -163,28 +127,4 @@ To remove an installation of CCF, run:
|
|||
From Source
|
||||
-----------
|
||||
|
||||
To build and install CCF from source, please see :doc:`/contribute/build_ccf`.
|
||||
|
||||
In Azure
|
||||
--------
|
||||
|
||||
CCF can be installed on an Azure Virtual Machine by running a single script:
|
||||
|
||||
.. tab:: SGX
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/ccf_sgx/getting_started/azure_vm/install_ccf_on_azure_vm.sh
|
||||
|
||||
.. tab:: SNP
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/ccf_snp/getting_started/azure_vm/install_ccf_on_azure_vm.sh
|
||||
|
||||
.. tab:: Virtual
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/ccf_virtual/getting_started/azure_vm/install_ccf_on_azure_vm.sh
|
||||
|
||||
To build and install CCF from source, please see :doc:`/contribute/build_ccf`.
|
||||
|
|
@ -26,9 +26,7 @@ These logging functions do several things:
|
|||
- Variable substitution. See `libfmt <https://fmt.dev/latest/>`_ for more details of the formatting syntax used in C++
|
||||
- Declare the severity of the entry. CCF defines 5 levels (``trace``, ``debug``, ``info``, ``fail``, and ``fatal``), and production nodes will generally ignore entries below ``info``
|
||||
- Prefix formatted metadata. The produced log line will include a timestamp, the name and line number where the line was produced, and an ``[app]`` tag
|
||||
- Write without an ECALL. The final write must be handled by the host, so writing directly from the enclave would require an expensive ECALL. Instead these macros will queue writes to a ringbuffer for the host to process, so diagnostic logging should not cause significant performance drops
|
||||
|
||||
The most-verbose lines which are emitted may be restricted at build-time, if required for security on that platform. On SGX, the ``CCF_APP_TRACE`` and ``CCF_APP_DEBUG`` macros are disabled at compile-time, to avoid leaking confidential information during execution. To enable these, define ``VERBOSE_LOGGING`` before including ``logger.h`` in your application code. The unsafe build variants of CCF include verbose logging of the framework itself, but this can be used independently of verbose logging in the application code.
|
||||
- Queue writes to a ringbuffer for the host to process, so diagnostic logging should not cause significant performance drops
|
||||
|
||||
.. note:: The app's logging entries will be interleaved (line-by-line) with the framework's logging messages. Filter for entries containing ``[app]`` to extract only application log lines.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,25 +9,28 @@ First, checkout the CCF repository:
|
|||
|
||||
$ git clone git@github.com:microsoft/CCF.git
|
||||
|
||||
To build CCF from source on a SGX-enabled machine, run the following:
|
||||
To build CCF from source, run the following:
|
||||
|
||||
.. code-block:: bash
|
||||
.. tab:: SNP
|
||||
|
||||
$ cd CCF
|
||||
$ mkdir build
|
||||
$ cd build
|
||||
$ cmake -GNinja ..
|
||||
$ ninja
|
||||
.. code-block:: bash
|
||||
|
||||
Alternatively, on a non-SGX machine, you can build a `virtual` instance of CCF:
|
||||
$ cd CCF
|
||||
$ mkdir build
|
||||
$ cd build
|
||||
$ cmake -GNinja -DCOMPILE_TARGET=snp ..
|
||||
$ ninja
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd CCF
|
||||
$ mkdir build
|
||||
$ cd build
|
||||
$ cmake -GNinja -DCOMPILE_TARGET=virtual ..
|
||||
$ ninja
|
||||
.. tab:: Virtual
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd CCF
|
||||
$ mkdir build
|
||||
$ cd build
|
||||
$ cmake -GNinja -DCOMPILE_TARGET=virtual ..
|
||||
$ ninja
|
||||
|
||||
.. note:::
|
||||
|
||||
|
|
@ -50,7 +53,7 @@ The most common build switches include:
|
|||
|
||||
* **BUILD_TESTS**: Boolean. Build all tests for CCF. Default to ON.
|
||||
* **SAN**: Boolean. Build unit tests with Address and Undefined behaviour sanitizers enabled. Default to OFF.
|
||||
* **COMPILE_TARGET**: String. Target compilation platform. Defaults to ``sgx``. Supported values are ``sgx``, ``snp``, or ``virtual``.
|
||||
* **COMPILE_TARGET**: String. Target compilation platform. Defaults to ``snp``. Supported values are ``snp``, or ``virtual``.
|
||||
|
||||
Run Tests
|
||||
---------
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ They can be pulled by unauthenticated users:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ docker pull ghcr.io/microsoft/ccf/ci/(default|sgx):build-*
|
||||
$ docker pull ghcr.io/microsoft/ccf/ci/default:build-*
|
||||
|
||||
Pushing a git tag of the form ``build/*`` will trigger the :ccf_repo:`.github/workflows/ci-containers-ghcr.yml` workflow that builds and pushes a new ``ghcr.io/microsoft/ccf/ci/(default|sgx):build-*`` image.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Then, to quickly set up the dependencies necessary to build CCF itself and CCF a
|
|||
|
||||
.. tab:: Virtual
|
||||
|
||||
.. warning:: The `virtual` version of CCF can also be run on hardware that does not support SGX/SNP. Virtual mode does not provide any security guarantees and should be used for development purposes only.
|
||||
.. warning:: The `virtual` version of CCF can also be run on hardware that does not support SEV-SNP. Virtual mode does not provide any security guarantees and should be used for development purposes only.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -34,16 +34,13 @@ The quickest way to get started building CCF applications is to use the CCF buil
|
|||
.. code-block:: bash
|
||||
|
||||
$ export VERSION="4.0.0"
|
||||
$ export PLATFORM="sgx" # One of sgx, snp or virtual
|
||||
$ export PLATFORM="snp" # snp or virtual
|
||||
$ docker pull mcr.microsoft.com/ccf/app/dev:$VERSION-$PLATFORM
|
||||
|
||||
The container contains the latest release of CCF along with a complete build toolchain, and startup scripts.
|
||||
|
||||
If your hardware does support SGX, and has the appropriate driver installed and loaded, then you will only need to expose the device to the container by passing ``--device /dev/sgx_enclave:/dev/sgx_enclave --device /dev/sgx_provision:/dev/sgx_provision -v /dev/sgx:/dev/sgx`` when you start it. It can be run on hardware that does not support SGX, in which case you will want to use the virtual binaries, or build in `virtual mode`.
|
||||
|
||||
.. note::
|
||||
|
||||
- When running the build container on SGX-enabled hardware, pass the ``--device /dev/sgx_enclave:/dev/sgx_enclave --device /dev/sgx_provision:/dev/sgx_provision -v /dev/sgx:/dev/sgx`` options to use SGX in the container.
|
||||
- `virtual` mode provides no security guarantee. It is only useful for development and prototyping.
|
||||
|
||||
Visual Studio Code Setup
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
Create Azure SGX VM
|
||||
===================
|
||||
|
||||
:term:`Azure Confidential Compute` (ACC) offers SGX-enabled `DC`_-series VMs, which can be deployed like other Azure SKUs.
|
||||
Note that `DC`_ SKUs can only be configured as `Gen2`_ VMs, and so only `Gen2`_ compatible VM images can be used.
|
||||
|
||||
.. note:: If you use `Visual Studio Code <https://code.visualstudio.com/>`_, you can install and set up the `Remote - SSH <https://code.visualstudio.com/docs/remote/ssh-tutorial>`_ extension to connect to your SGX-enabled VM.
|
||||
|
||||
|
||||
.. _`DC`: https://docs.microsoft.com/en-us/azure/virtual-machines/dcv2-series
|
||||
.. _`Gen2`: https://docs.microsoft.com/en-us/azure/virtual-machines/generation-2
|
||||
|
|
@ -15,13 +15,6 @@ The CCF team welcome contributions to any part of the framework, including this
|
|||
|
||||
---
|
||||
|
||||
:fa:`cloud` :doc:`create_vm`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Create a SGX-enabled Azure Virtual Machine.
|
||||
|
||||
---
|
||||
|
||||
:fa:`laptop-code` :doc:`build_setup`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -53,7 +46,6 @@ The CCF team welcome contributions to any part of the framework, including this
|
|||
:hidden:
|
||||
|
||||
onboarding
|
||||
create_vm
|
||||
build_setup
|
||||
build_ccf
|
||||
release_ccf
|
||||
|
|
|
|||
|
|
@ -10,11 +10,6 @@ Start by reading :doc:`/overview/what_is_ccf`.
|
|||
|
||||
If you encounter any terms or acronyms that you do not know, check the :doc:`/overview/glossary`. If the word you are looking for is not defined, create an `issue <https://github.com/microsoft/CCF/issues/new/choose>`_.
|
||||
|
||||
Create an SGX VM if necessary
|
||||
-----------------------------
|
||||
|
||||
If you intend to make changes that need to work on Intel SGX, you will want an :doc:`SGX VM </contribute/create_vm>` to check you didn't introduce instructions that are illegal in enclave, and to evaluate the performance impact of your change.
|
||||
|
||||
Build CCF
|
||||
---------
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ CCF can run on several hardware platforms/trusted execution environments, which
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
sgx
|
||||
snp
|
||||
virtual
|
||||
|
||||
|
|
|
|||
|
|
@ -1,37 +0,0 @@
|
|||
Intel SGX
|
||||
=========
|
||||
|
||||
How to use the Intel SGX platform
|
||||
---------------------------------
|
||||
|
||||
CCF must run on an Intel CPU which supports SGX.
|
||||
|
||||
To use SGX, in the :ref:`operations/configuration:``enclave``` configuration section, the enclave ``platform`` should be set to ``SGX``, and ``type`` to ``Release`` or ``Debug``, depending on the enclave build type.
|
||||
|
||||
Attestation
|
||||
-----------
|
||||
|
||||
SGX attestations provide a measurement of the code loaded into the enclave, which CCF stores in the :ref:`audit/builtin_maps:``nodes.code_ids``` table. New nodes joining a network will provide their measurement and the primary will perform an identity check against the table entries.
|
||||
|
||||
The first node in a new network will add its code id to the table. Members can then manage which code ids are present in the table with the ``add_node_code`` and ``remove_node_code`` actions.
|
||||
|
||||
Once the proposal has been accepted, nodes running the new code are authorised to join the network. Nodes running older versions of the code can then be retired and stopped.
|
||||
|
||||
.. note:: The identity of the code (``mrenclave``) can be found by running the ``oesign`` utility provided by :term:`Open Enclave` :
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/openenclave/bin/oesign dump -e enclave_library
|
||||
=== Entry point:
|
||||
name=_start
|
||||
address=000000000097fa38
|
||||
|
||||
=== SGX Enclave Properties:
|
||||
product_id=1
|
||||
security_version=1
|
||||
debug=1
|
||||
xfrm=0
|
||||
num_heap_pages=50000
|
||||
num_stack_pages=1024
|
||||
num_tcs=8
|
||||
mrenclave=3175971c02d00c1a8f9dd23ca89e64955c5caa94e24f4a3a0579dcfb2e6aebf9
|
||||
|
|
@ -37,13 +37,6 @@ C++ Apps
|
|||
|
||||
The ``ghcr.io/microsoft/ccf/app/run/*`` containers can be run to deploy C++ apps. They contain the ``cchost`` binary and the dependencies required to spin up a CCF node.
|
||||
|
||||
.. tab:: SGX
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ export VERSION="5.0.0-rc0"
|
||||
$ docker pull ghcr.io/microsoft/ccf/app/run/sgx:ccf-$VERSION
|
||||
|
||||
.. tab:: SNP
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
@ -64,13 +57,6 @@ JavaScript/TypeScript Apps
|
|||
|
||||
The ``ghcr.io/microsoft/ccf/app/run-js/*`` containers can be run to deploy JavaScript/TypeScripts apps. They contain the ``cchost`` binary, the ``libjs_generic`` native application to run JavaScript/TypeScript apps, and the dependencies required to spin up a CCF node.
|
||||
|
||||
.. tab:: SGX
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ export VERSION="5.0.0-rc0"
|
||||
$ docker pull ghcr.io/microsoft/ccf/app/run-js/sgx:ccf-$VERSION
|
||||
|
||||
.. tab:: SNP
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ The joining node takes the certificate of the existing network to join via ``ser
|
|||
|
||||
The join configuration option should be set in the :ref:`operations/configuration:``command.join``` section of the JSON configuration.
|
||||
|
||||
A new node can only join an existing CCF network if its SGX quote is valid [#remote_attestation]_. and runs an enclave application that is :ref:`trusted by the consortium <governance/common_member_operations:Updating Code Version>`.
|
||||
A new node can only join an existing CCF network if its hardware attestation is valid [#remote_attestation]_. and runs an enclave application that is :ref:`trusted by the consortium <governance/common_member_operations:Updating Code Version>`.
|
||||
|
||||
If the network has not yet been opened by members (see :ref:`governance/open_network:Opening the Network`), the joining node becomes part of the network immediately. Otherwise, if the network has already been opened to users, members need to trust the joining node before it can become part of the network and participate in the consensus (see :ref:`governance/common_member_operations:Trusting a New Node`).
|
||||
|
||||
|
|
|
|||
|
|
@ -100,38 +100,4 @@ Returned when a node tries to join a network with too old a snapshot, or no snap
|
|||
See :ref:`this page <operations/ledger_snapshot:Join or Recover From Snapshot>` for more information.
|
||||
|
||||
**Resolution:** This can be resolved by trying to join again with a fresh snapshot.
|
||||
The seqno of the snapshot a node started from is available as ``startup_seqno`` in :http:GET:`/node/state`.
|
||||
|
||||
Node Startup Issues
|
||||
-------------------
|
||||
|
||||
``OE_SERVICE_UNAVAILABLE``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block::
|
||||
|
||||
# Complete node logs on startup
|
||||
2022-01-01T12:00:00.000000Z 100 [info ] ../src/host/main.cpp:519 | Initialising enclave: enclave_create_node
|
||||
[init ../../../psw/ae/aesm_service/source/core/ipc/UnixCommunicationSocket.cpp:225] Failed to connect to socket /var/run/aesmd/aesm.socket
|
||||
2022-01-01T12:00:00.000000Z [(H)ERROR] tid(0x7f277c35b740) | SGX AESM service unavailable (oe_result_t=OE_SERVICE_UNAVAILABLE) [/source/openenclave/host/sgx/sgxquote.c:_load_quote_ex_library_once:479]
|
||||
2022-01-01T12:00:00.000000Z [(H)ERROR] tid(0x7f277c35b740) | Failed to load SGX quote-ex library
|
||||
(oe_result_t=OE_SERVICE_UNAVAILABLE) [/source/openenclave/host/sgx/sgxquote.c:oe_sgx_qe_get_target_info:688]
|
||||
2022-01-01T12:00:00.000000Z [(H)ERROR] tid(0x7f277c35b740) | :OE_SERVICE_UNAVAILABLE [/source/openenclave/host/sgx/quote.c:sgx_get_qetarget_info:37]
|
||||
|
||||
This may occur on SGX deployments where the ``SGX_AESM_ADDR`` environment variable is set. By default, this variable is automatically set when installing CCF dependencies (specifically, Open Enclave) and indicates that out-of-process attestation quote generation should be used (`using the AESM service <https://github.com/openenclave/openenclave/blob/753e3227b9721851d363f028e37e5431f2311ca3/docs/GettingStartedDocs/Contributors/SGX1FLCGettingStarted.md#determine-call-path-for-sgx-quote-generation-in-attestation-sample>`_).
|
||||
|
||||
While CCF supports out-of-process attestation, the AESM service is not installed as part of the CCF dependencies. For local deployments, it is expected that operators use in-process quote generation.
|
||||
|
||||
**Resolution:** Unset the ``SGX_AESM_ADDR`` environment variable: ``$ unset SGX_AESM_ADDR``.
|
||||
|
||||
Info Messages
|
||||
-------------
|
||||
|
||||
``Ignoring signal: 13``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Signal 13 (`SIGPIPE`) is emitted on writes to closed fds. It is superfluous in programs that handle write errors, such as CCF, and is therefore ignored. This message does not indicate a malfunction.
|
||||
|
||||
Most CCF releases set the `SIG_IGN` handler, but a bug introduced in Open Enclave `0.18.0 <https://github.com/openenclave/openenclave/releases/tag/v0.18.0>`_ caused the process to crash rather than ignore the signal. CCF installed an alternative handler as a workaround in `2.0.2 <https://github.com/microsoft/CCF/releases/tag/ccf-2.0.2>`_ , which produces this log line.
|
||||
|
||||
The issue was fixed upstream in Open Enclave `0.18.1 <https://github.com/openenclave/openenclave/releases/tag/v0.18.1>`_ (see `#4542 <https://github.com/openenclave/openenclave/issues/4542>`_). This log line is now redundant and will be removed from later releases.
|
||||
The seqno of the snapshot a node started from is available as ``startup_seqno`` in :http:GET:`/node/state`.
|
||||
|
|
@ -16,8 +16,4 @@ However, this mode does not provide any security guarantees (e.g. no memory encr
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
CCF itself can run on prem as well as in Azure.
|
||||
However, for the :term:`TEE` security guarantees to be trusted by clients and operators, the deployment environment should have access to the endorsements of the TEE attestation reports.
|
||||
|
||||
While Azure caches these endorsements transparently, on-prem CCF deployments require the development of a specific infrastructure to store and serve the endorsements.
|
||||
The procedure to follow is described `here <https://github.com/openenclave/openenclave/tree/master/docs/GettingStartedDocs/Contributors/NonAccMachineSGXLinuxGettingStarted.md>`_.
|
||||
Note that this setup is not tested by the CCF team. Support can be obtained from the :term:`Open Enclave` project.
|
||||
However, for the :term:`TEE` security guarantees to be trusted by clients and operators, the deployment environment should have access to the endorsements of the TEE attestation reports.
|
||||
|
|
@ -5,9 +5,6 @@ Glossary
|
|||
Azure Confidential Compute
|
||||
`Azure Confidential Compute <https://azure.microsoft.com/en-us/solutions/confidential-compute/>`_ protects the confidentiality and integrity of your data and code while it's processed in the public cloud.
|
||||
|
||||
Azure DCAP
|
||||
Intel SGX Data Centre Attestation Primitives which allows SGX attestation to be used within Microsoft Azure.
|
||||
|
||||
Constitution
|
||||
JavaScript module that defines possible governance actions, and how members' proposals are validated, resolved and applied to the service.
|
||||
|
||||
|
|
@ -21,12 +18,6 @@ Glossary
|
|||
Enclave
|
||||
`Trusted Execution Environments <https://en.wikipedia.org/wiki/Trusted_execution_environment>`_, allowing fully encrypted and auditable execution without direct access from the host machine.
|
||||
|
||||
FLC
|
||||
`Flexible Launch Control <https://github.com/intel/linux-sgx/blob/master/psw/ae/ref_le/ref_le.md#flexible-launch-control>`_ is a feature of the Intel :term:`SGX` architecture.
|
||||
|
||||
Intel SGX PSW
|
||||
Intel SGX Platform SoftWare which manages SGX enclaves loading as well as communication with architectural enclaves. More details `here <https://github.com/intel/linux-sgx>`_.
|
||||
|
||||
Members
|
||||
Constitute the consortium governing a CCF network. Their public identity should be registered in CCF.
|
||||
|
||||
|
|
@ -41,9 +32,6 @@ Glossary
|
|||
|
||||
Omission Fault
|
||||
Type of failure where consensus messages exchanged between nodes are lost due to unreliable network. This may cause one or more nodes to be isolated from the rest of the network.
|
||||
|
||||
Open Enclave
|
||||
`Open Enclave SDK <https://openenclave.io/sdk>`_ is an SDK for building enclave applications in C and C++.
|
||||
|
||||
Operators
|
||||
Are in charge of operating a CCF network (e.g. adding or removing nodes). Their identities are not registered in CCF.
|
||||
|
|
@ -66,9 +54,6 @@ Glossary
|
|||
SEV-SNP
|
||||
`AMD Secure Encrypted Virtualisation - Secure Nested Paging <https://www.amd.com/en/processors/amd-secure-encrypted-virtualization>`_ is a trusted execution environment platform. It is a technology used to isolate virtual machines from the hypervisor with strong memory integrity protection.
|
||||
|
||||
SGX
|
||||
`Intel Software Guard Extensions <https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/overview.html>`_ is a trusted execution environment platform. It is a set of instructions that increases the security of application code and data, giving them more protection from disclosure or modification. Developers can partition sensitive information into enclaves, which are areas of execution in memory with more security protection.
|
||||
|
||||
TCP
|
||||
`Transmission Control Protocol <https://en.wikipedia.org/wiki/Transmission_Control_Protocol>`_ is a network protocol over IP that provides sessions and ordered streams, which we use to connect between nodes and external clients.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The following diagram shows a basic CCF network made of 3 nodes. All nodes run t
|
|||
Network and Nodes
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
A CCF network consists of several nodes, each running on top of a Trusted Execution Environment (:term:`TEE`), such as Intel :term:`SGX`. A CCF network is decentralised and highly-available.
|
||||
A CCF network consists of several nodes, each running on top of a Trusted Execution Environment (:term:`TEE`), such as AMD :term:`SEV-SNP`. A CCF network is decentralised and highly-available.
|
||||
|
||||
Nodes are run and maintained by :term:`Operators`. However, nodes must be trusted by the consortium of members before participating in a CCF network.
|
||||
|
||||
|
|
|
|||
|
|
@ -295,7 +295,7 @@
|
|||
"info": {
|
||||
"description": "This CCF sample app implements a simple logging application, securely recording messages at client-specified IDs. It demonstrates most of the features available to CCF apps.",
|
||||
"title": "CCF Sample Logging App",
|
||||
"version": "2.5.0"
|
||||
"version": "2.6.0"
|
||||
},
|
||||
"openapi": "3.0.0",
|
||||
"paths": {
|
||||
|
|
|
|||
|
|
@ -19,13 +19,6 @@ This section describes how :term:`Users` can issue transactions to CCF applicati
|
|||
|
||||
---
|
||||
|
||||
:fa:`search` :doc:`verify_quote`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Checking the quote of a CCF node to confirm it is part of a valid network and running in Enclave.
|
||||
|
||||
---
|
||||
|
||||
:fa:`terminal` :doc:`rpc_api`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -37,5 +30,4 @@ This section describes how :term:`Users` can issue transactions to CCF applicati
|
|||
|
||||
issue_commands
|
||||
verify_tx
|
||||
verify_quote
|
||||
rpc_api
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
Verifying Quote
|
||||
===============
|
||||
|
||||
A client can verify the validity of the SGX quote of the CCF node that it connects to. This can be done using the ``verify_quote.sh`` script installed as part of the CCF install or ``ccf`` Python package.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ verify_quote.sh https://<ccf-node-address> [--mrenclave <mrenclave_hex>] [CURL_OPTIONS]
|
||||
Retrieved 1 accepted code versions from CCF service.
|
||||
Node quote successfully retrieved. Verifying quote...
|
||||
mrenclave: 3175971c02d00c1a8f9dd23ca89e64955c5caa94e24f4a3a0579dcfb2e6aebf9
|
||||
Quote verification successful.
|
||||
|
||||
The script verifies the target CCF node's SGX quote by:
|
||||
|
||||
1. Retrieving the node's SGX quote via the :http:GET:`/node/quotes/self` endpoint.
|
||||
2. Verifying that the cryptographic hash of the node's identity public key (as presented in the node's certificate in the TLS session) matches the quote's report data.
|
||||
3. Verifying that the quote's measurement (``MRENCLAVE``) matches one of the trusted enclave measurements.
|
||||
|
||||
A specific trusted SGX enclave measurement can be specified ``--mrenclave <mrenclave_hex>`` (e.g. using the value returned by the Open Enclave ``oesign dump`` utility) as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ verify_quote.sh https://<ccf-node-address> --mrenclave 3175971c02d00c1a8f9dd23ca89e64955c5caa94e24f4a3a0579dcfb2e6aebf9 [CURL_OPTIONS]
|
||||
Node quote successfully retrieved. Verifying quote...
|
||||
mrenclave: 3175971c02d00c1a8f9dd23ca89e64955c5caa94e24f4a3a0579dcfb2e6aebf9
|
||||
Quote verification successful.
|
||||
|
||||
If no code measurement is specified, the ``verify_quote.sh`` script automatically verifies it against the code versions currently trusted by the CCF service, as returned by the :http:GET:`/node/code` endpoint.
|
||||
|
||||
.. note:: The ``verify_quote.sh`` script uses the ``oeverify`` CLI included in the Open Enclave ``hostverify`` package available on the `Open Enclave release page <https://github.com/openenclave/openenclave/releases>`_.
|
||||
|
||||
Alternatively, the SGX quotes of all currently trusted nodes can be retrieved via the :http:GET:`/node/quotes` endpoint:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ curl https://<ccf-node-address>/node/quotes --cacert service_cert.pem
|
||||
{"quotes": [
|
||||
{"mrenclave":"<measurement_hash>, "node_id":<node_id>, "raw":"<hex_encoded_raw_quote>"},
|
||||
{"mrenclave":"<measurement_hash>, "node_id":<node_id>, "raw":"<hex_encoded_raw_quote>"}]}
|
||||
|
|
@ -470,7 +470,7 @@ namespace loggingapp
|
|||
"recording messages at client-specified IDs. It demonstrates most of "
|
||||
"the features available to CCF apps.";
|
||||
|
||||
openapi_info.document_version = "2.5.0";
|
||||
openapi_info.document_version = "2.6.0";
|
||||
|
||||
index_per_public_key = std::make_shared<RecordsIndexingStrategy>(
|
||||
PUBLIC_RECORDS, context, 10000, 20);
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче