# On convergence of an unconditional stable numerical scheme for Q-tensor flow
based on invariant quardratization method

Yukun Yue
Department of Mathematical Sciences
Carnegie Mellon University
5000 Forbes Avenue, Pittsburgh, PA 15213, USA<EMAIL_ADDRESS>
###### Abstract.

We present convergence analysis towards a numerical scheme designed for
Q-tensor flows of nematic liquid crystals. This scheme is based on the
Invariant Energy Quadratization method, which introduces an auxiliary variable
to replace the original energy functional. In this work, we have shown that
given an initial value with $H^{2}$ regularity, we can obtain a uniform
$H^{2}$ estimate on the numerical solutions for Q-tensor flows and then deduce
the convergence to a strong solution of the parabolic-type Q-tensor equation.
We have also shown that the limit of the auxiliary variable is equivalent to
the original energy functional term in the strong sense.

##  1\. Introduction

Liquid crystal is an intermediate phase of matter between solid and liquid,
which can be depicted as calamitic (rod-like) molecules in a microscopic
sense[5]. This paper will focus on the Q-tensor model for nematic liquid
crystals, established by Landau-de Gennes’s theory[6, 17]. In this framework,
the director field of liquid crystal, denoted by $n$, is determined through a
symmetric, trace-free $d\times d$ matrix $Q$ known as a Q-tensor order
parameter[15]. This matrix is assumed to minimize the Landau-de Gennes free
energy

(1.1) $E_{LG}(Q)=\frac{L}{2}\|\nabla
Q\|_{L^{2}}^{2}+\int_{\Omega}\mathcal{F}_{B}(Q).$

Here $L>0$, $\Omega\in\mathbb{R}^{d}$ with $d=2$ or $3$ represents the spatial
region where the liquid crystal molecules immerse and $\partial\Omega\in
C^{2}$. $\mathcal{F}_{B}$ denotes a bulk potential given by a truncated Taylor
series of the thermotropic energy at $Q=0$[20], given by
$\mathcal{F}_{B}(Q)=\frac{a}{2}\operatorname{\text{tr}}(Q^{2})-\frac{b}{3}\operatorname{\text{tr}}(Q^{3})+\frac{c}{4}\left(\operatorname{\text{tr}}(Q^{2})\right)^{2}$,
where $a,b,$ and $c$ are constants and $c>0$. Modeled by calculating the
gradient flow[3, 17] of Landau-de Gennes free energy, the following equation
will describe the non-equilibrium situation satisfied by the Q-tensor,

(1.2) $Q_{t}=-\frac{\delta E_{LG}}{\delta Q}=M\left[L\Delta
Q-\left(aQ-b\left(Q^{2}-\frac{1}{3}\operatorname{\text{tr}}(Q^{2})I\right)+c\operatorname{\text{tr}}(Q^{2})Q\right)\right]\coloneqq
M\left(L\Delta Q-S(Q)\right).$

where $M>0$ is a constant. We prescribe $Q$ with Dirichlet or Neumann boundary
condition and denote the initial value as $Q_{0}\in H^{2}$.

Abundance analysis results have been established for this Q-tensor flow model
and the related hydrodynamics models. See [1, 2, 4, 10, 11, 19, 27] and the
reference within. Various numerical approaches have also been made[13, 16, 18,
22, 23, 32, 33]. A typical problem in designing a stable and efficient
numerical scheme for problem (1.2) is the high non-linearity of the functional
derivative of the bulk potential term. The Invariant Energy
Quadratization(IEQ) method, which is recently developed, is a powerful tool
for dealing with such difficulty and constructing linear energy-stable
schemes. It has been widely used in treating gradient flow type problems. See
[12, 14, 28, 29, 30, 31] for more applications.

This method introduces an auxiliary variable replacing the original bulk
potential. Specifically, we define

(1.3)
$r(Q)=\sqrt{2\left(\frac{a}{2}\operatorname{\text{tr}}(Q^{2})-\frac{b}{3}\operatorname{\text{tr}}(Q^{3})+\frac{c}{4}\left(\operatorname{\text{tr}}(Q^{2})\right)^{2}\right)+A_{0}},$

where $A_{0}>0$ is a large enough constant to ensure $r(Q)$ to be positive for
any symmetric, trace-free tensor $Q$. This is well-defined since the bulk
potential term $\mathcal{F}_{B}$ is bounded from below when $c>0$[32, Theorem
2.1]. It follows that

(1.4) $P(Q)\coloneqq\frac{\delta r(Q)}{\delta
Q}=\frac{S(Q)}{r(Q)}=\frac{aQ-b\left(Q^{2}-\frac{1}{3}\operatorname{\text{tr}}(Q^{2})I\right)+c\operatorname{\text{tr}}(Q^{2})Q}{\sqrt{2\left(\frac{a}{2}\operatorname{\text{tr}}(Q^{2})-\frac{b}{3}\operatorname{\text{tr}}(Q^{3})+\frac{c}{4}\left(\operatorname{\text{tr}}(Q^{2})\right)^{2}\right)+A_{0}}},$

and $P(Q)$ is symmetric, trace-free. Then we can reformulate the equation
(1.2) as a system for $(Q,r)$ satisfying

(1.5a) $Q_{t}=M(L\Delta Q-rP(Q))$ (1.5b) $r_{t}=P(Q):Q_{t}$

subject to the same boundary and initial condition as (1.2).

In [9], we have constructed a fully discrete energy-stable scheme based on the
IEQ formulation for this system and proved the convergence of the numerical
solution to the weak solution of (1.5). In this work, we will construct a
semi-discrete numerical scheme solving the system (1.5), following the idea we
raised in [9]. Let $(Q,r)$ denote the weak limit obtained by the convergence
of numerical solutions. We will show a uniform $H^{2}$ bound for the Q-tensor
given a regular enough initial condition and then deduce that $Q$ is a strong
solution for system (1.2). It will be done by showing the equivalence of $r$
and $r(Q)$ in the $L^{2}$ sense. To the best of our knowledge, this is the
first work to show such equivalence by explicitly computing the difference
between the auxiliary variable and the energy quadratization in a discrete
sense. The technique we use here can be applied to study other numerical
schemes regarding different problems based on the IEQ method, for example, the
hydrodynamical liquid system problem.

##  2\. Numerical Scheme

Before starting the following analysis, we will introduce some important
notations and definitions that appeared in this paper here. We denote the norm
of Banach space $X$ as $\|\cdot\|_{X}$ and use $\|\cdot\|$ to denote the
$L^{2}$ norm. The inner product on $L^{2}$ will be denoted as
$\langle\cdot,\cdot\rangle$. We use $A:B$ to denote the Frobenius norm for two
matrix-valued functions. If there is no specific illustration, we will assume
a tensor product term to be trace-free and symmetric when we refer it to a
Q-tensor. We list the lemmas frequently used in the following analysis:
Lipschitz continuity of $P(Q)$[9, Theorem 4.1], Agmon’s inequality[25, Chapter
II, section 1.4], Sobolev’s inequality[7], and Aubin-Lions lemma[24]. We say
$Q$ is a strong solution for (1.2) if $Q\in
L^{2}\left([0,T];H^{3}(\Omega)\bigcap H^{1}_{0}(\Omega)\right)\cap
L^{\infty}\left([0,T];H^{2}(\Omega)\right)\bigcap
H^{1}\left([0,T];H^{1}(\Omega)\right)$ and (1.2) holds in
$L^{2}([0,T]\times\Omega)$.

We propose the following numerical scheme to solve (1.5):

(2.1) $\displaystyle\frac{Q^{n+1}-Q^{n}}{\Delta t}$ $\displaystyle=MH^{n+1},$
(2.2) $\displaystyle r^{n+1}-r^{n}$ $\displaystyle=P(Q^{n}):(Q^{n+1}-Q^{n}),$

where $H^{n+1}=L\Delta Q^{n+1}-r^{n+1}P(Q^{n})$ subject to boundary condition
$Q^{n}|_{\partial\Omega}=0$ or $\partial_{n}Q^{n}|_{\partial\Omega}=0$

Firstly, we will state solvability of this numerical scheme. This can be
summarized as the following lemma.

######  Lemma 2.1.

The scheme (2.1)-(2.2) is well-defined. Specifically, given $Q^{0}\in
H^{2}(\Omega)$ satisfying Dirichlet or Neumann boundary condition, for each
$n>1$, we have $Q^{n}\in H^{2}(\Omega)$. Furthermore, for $n\geq 1$, we have
$r^{n}\in H^{1}(\Omega)$.

###### Proof.

Assume the lemma holds for $Q^{n}$, we will prove the lemma holds for
$Q^{n+1}$ as well. Substituting $r^{n+1}$ by (2.2) into $H^{n+1}$ and
$\eqref{eq:DtQ}$, we obtain

(2.3) $Q^{n+1}-ML\Delta Q^{n+1}\Delta t+(P(Q^{n}):Q^{n+1})P(Q^{n})\Delta
t=Q^{n}-r^{n}P(Q^{n})\Delta t+(P(Q^{n}):Q^{n})P(Q^{n})\Delta t$

We define bilinear operator $T:H^{1}(\Omega)\times H^{1}(\Omega)\to\mathbb{R}$
as

(2.4) $T(A,B)=\langle A,B\rangle+ML\langle\nabla A,\nabla B\rangle\,\Delta
t+\langle P(Q^{n}),A\rangle\,\langle P(Q^{n}),B\rangle\,\Delta t.$

This operator is clearly bounded. For its ellipticity, taking $B=A$ and we
yield

(2.5) $\lvert T(A,A)\rvert=\|A\|^{2}+ML\|\nabla A\|^{2}+\lvert\langle
P(Q^{n}),A\rangle\rvert^{2}>C\|A\|_{H^{1}}^{2},$

for some constant $C>0$ related to $M,L,\Delta t$. Here we have shown that $T$
is an elliptic operator. By standard regularity results for elliptic
problems[7, 8], there exists unique $Q^{n+1}\in H^{2}(\Omega)$ solving
(2.1)-(2.2). The regularity of $r^{n}$ will immediately follow from the
regularity of $Q^{n}$ and (2.2) by standard induction argument. ∎

Next, we will refer to the following results on trace-free and symmetric
properties preserved by our numerical scheme and the discrete energy
stability. Their proof follows in the same way as [9, Proposition 4.4] and [9,
Theorem 4.6], respectively.

######  Lemma 2.2.

If $Q^{n}$ is symmetric and trace-free, then $Q^{n+1}$ computed by (2.1) is
also symmetric and trace-free.

######  Lemma 2.3.

Define the discrete energy $E^{n}=\frac{L}{2}\|\nabla
Q^{n}\|^{2}+\frac{1}{2}\|r^{n}\|^{2}$, then

(2.6) $E^{n+1}-E^{n}\leq-M\|H^{n+1}\|^{2}\Delta t.$

In addition, it follows that for any $N>0$,
$\sum_{n=0}^{N}\|H^{n+1}\|^{2}\,\Delta t\leq 2E_{0}$.

To the end of this section, we will show the following estimate for $Q^{n}$:

######  Lemma 2.4.

If $Q^{0}\in H^{2}(\Omega)$, then $\sum_{k=1}^{N}\|\Delta Q^{k}\|^{2}\,\Delta
t\leq M$, for some constant $M>0$

###### Proof.

Using definition of $H^{n+1}$, we have

(2.7) $\displaystyle\|\Delta
Q^{k+1}\|^{2}=\|\frac{1}{L}\left(H^{k+1}+r^{k+1}P(Q^{k})\right)\|^{2}\leq
C\left(\|H^{k+1}\|^{2}+\|P(Q^{k})\|_{L^{\infty}}^{2}\|r^{k+1}\|^{2}\right).$

It follows from Lemma 2.3, Agmon’s inequality and Lipschitz continuity of
$P(Q)$ that

(2.8) $\displaystyle\|\Delta Q^{k+1}\|^{2}$ $\displaystyle\leq
C\left(\|H^{k+1}\|^{2}+\|\Delta Q^{k}\|+1\right)\leq
C\left(1+\|H^{k+1}\|^{2}\right)+\frac{1}{2}\|\Delta Q^{k}\|^{2}.$

Multiplying $\Delta t$ on both sides and summing from $k=0$ to $k=N-1$, we
have

(2.9) $\frac{1}{2}\|\Delta Q^{N}\|^{2}\Delta
t+\frac{1}{2}\sum_{k=1}^{N}\|\Delta Q^{k}\|^{2}\Delta t\leq\frac{1}{2}\|\Delta
Q^{0}\|^{2}\Delta t+\sum_{k=1}^{N}C\left(1+\|H^{k+1}\|^{2}\right)\Delta t,$

which is bounded uniformly in $\Delta t$ thanks to the discrete energy
estimate given in Lemma 2.3.

∎

##  3\. Convergence Analysis

###  3.1. Higher order energy inequality

Regarding the existence and regularity of results on Q-tensor models, one
common condition necessary to obtain a strong solution is the uniform $H^{2}$
bound of the Q-tensor in time. However, the derivation of this result highly
depends on the integrability of $r(Q)$. Specifically, $r(Q)$ is a quadratic
function concerning $Q$. Its regularity follows from properties of $Q$. It is
hard to be obtained in our reformulated system because it is not apparent to
conclude that $r^{k}=O(|Q^{k}|^{2})$. The only existing regularity we can use
is the $L^{2}$ integrability of $r^{k}$.

We will address this problem by explicitly estimating the difference between
the auxiliary variable $r^{k}$ and $r(Q^{k})$ for each $k\in\mathbb{N}$. By
Taylor expansion for matrix-valued functions[26],

(3.1)
$r(Q^{k+1})-r(Q^{k})=P(Q^{k}):(Q^{k+1}-Q^{k})+R_{k}=r^{k+1}-r^{k}+R_{k},$

where the remainder $R_{k}$ satisfies $\lvert R_{k}\rvert\leq C\lvert
Q^{k+1}-Q^{k}\rvert^{2}$ for some $C>0$ due to the Lipschitz continuity of
$P$. Then it follows from (3.1) that

(3.2) $\left(r^{k+1}-r(Q^{k+1})\right)-\left(r^{k}-r(Q^{k})\right)=R_{k}.$

Taking sum from $k=0$ to $k=n-1$ and using the fact that $r^{0}=r(Q^{0})$, it
gives

(3.3) $V_{n}\coloneqq\lvert
r^{n}-r(Q^{n})\rvert=\left\lvert\sum_{k=0}^{n-1}R_{k}\right\rvert\leq
C\sum_{k=0}^{n-1}\left\lvert Q^{k+1}-Q^{k}\right\rvert^{2}.$

Lemma 2.1 ensures us to take gradient of (2.2) to get

(3.4) $\nabla r^{k+1}-\nabla
r^{k}=\nabla\left(P(Q^{k}):(Q^{k+1}-Q^{k})\right)=R_{k}^{(1)}+P(Q^{k}):(\nabla
Q^{k+1}-\nabla Q^{k}),$

where $\lvert R_{k}^{(1)}\rvert=\lvert\nabla P(Q^{k})\rvert\,\lvert
Q^{k+1}-Q^{k}\rvert\leq C\lvert\nabla Q^{k}\rvert\,\lvert
Q^{k+1}-Q^{k}\rvert.$ Using chain rule, we have

(3.5) $\displaystyle\quad\,\,\nabla r(Q^{k+1})-\nabla r(Q^{k})$
$\displaystyle=P(Q^{k+1}):\nabla Q^{k+1}-P(Q^{k}):\nabla Q^{k}$
$\displaystyle=\left(P(Q^{k+1})-P(Q^{k})\right)\,\nabla
Q^{k+1}+P(Q^{k}):(\nabla Q^{k+1}-\nabla Q^{k})\coloneqq
R_{k}^{(2)}+P(Q^{k}):(\nabla Q^{k+1}-Q^{k}).$

Using Lipschitz continuity of $P$, we obtain $\lvert R_{k}^{(2)}\rvert\leq
C\lvert\nabla Q^{k+1}\rvert\lvert Q^{k+1}-Q^{k}\rvert$. Now we yield

(3.6) $\left(\nabla r^{k+1}-\nabla r(Q^{k+1})\right)-\left(\nabla r^{k}-\nabla
r(Q^{k})\right)=R_{k}^{(1)}-R_{k}^{(2)}.$

Taking sum over $k$ from $k=0$ to $k=n-1$, we have

(3.7) $D_{n}\coloneqq\lvert\nabla r^{n}-\nabla
r(Q^{n})\rvert=\left\lvert\sum_{k=0}^{n-1}(R_{k}^{(1)}-R_{k}^{(2)})\right\rvert\leq
C\sum_{k=0}^{n-1}\left[(\lvert\nabla Q^{k}\rvert+\lvert\nabla
Q^{k+1}\rvert)\,\lvert Q^{k+1}-Q^{k}\rvert\right].$

To obtain strong solution of the system, we need higher order energy estimate
for the discrete solution $Q^{n}$, more detailedly, we will try to deduce a
uniform $H^{2}$ bound of $Q^{n+1}$ which leads to

(3.8) $\displaystyle\frac{L}{2}\|\Delta Q^{n+1}\|^{2}-\frac{L}{2}\|\Delta
Q^{n}\|^{2}$ $\displaystyle\leq\langle L\Delta Q^{n+1},\Delta Q^{n+1}-\Delta
Q^{n}\rangle$ $\displaystyle=\langle H^{n+1}-r^{n+1}P(Q^{n}),\,\Delta
Q^{n+1}-\Delta Q^{n}\rangle$ $\displaystyle=-\frac{1}{M}\,\|\frac{\nabla
Q^{n+1}-\nabla Q^{n}}{\Delta t}\|^{2}\Delta
t+\langle\nabla\left(r^{n+1}P(Q^{n})\right),\,\frac{\nabla Q^{n+1}-\nabla
Q^{n}}{\Delta t}\rangle\,\Delta t$
$\displaystyle\leq-\frac{1}{2M}\|\frac{\nabla Q^{n+1}-\nabla Q^{n}}{\Delta
t}\|^{2}\Delta t+C\|\nabla\left(r^{n+1}P(Q^{n})\right)\|^{2}\Delta t.$

It intrigues us to provide the following estimate for
$\|\nabla(r^{n+1}P(Q^{n}))\|$.

######  Lemma 3.1.

For fixed $\Delta t>0$ and each $n\in[0,\lfloor\frac{T}{\Delta t}\rfloor]$, we
have for some constant $C>0$ such that

(3.9) $\|\nabla\left(r^{n+1}P(Q^{n})\right)\|^{2}\leq C+C(1+\|\Delta
Q^{n}\|^{2})(1+W_{n}+W_{n+1}+W_{n}^{2}\Delta t+W_{n+1}\Delta t)$

###### Proof.

We split this term by using (3.3) and (3.7) to approximate, that is,

(3.10) $\displaystyle\quad\,\,\|\nabla\left(r^{n+1}P(Q^{n})\right)\|^{2}$
$\displaystyle=\|\nabla r^{n+1}P(Q^{n})+(r^{n+1}-r^{n})\,\nabla
P(Q^{n})+r^{n}\nabla P(Q^{n})\|^{2}$ $\displaystyle=\|\nabla
r^{n+1}P(Q^{n})+P(Q^{n}):(Q^{n+1}-Q^{n})\,\nabla P(Q^{n})+r^{n}\nabla
P(Q^{n})\|^{2}$ $\displaystyle\leq C\Big{(}\|\nabla
r(Q^{n+1})\,P(Q^{n})\|^{2}+\|r(Q^{n})\,\nabla
P(Q^{n})\|^{2}+\|P(Q^{n}):(Q^{n+1}-Q^{n})\,\nabla P(Q^{n})\|^{2}$
$\displaystyle\quad\quad\quad\,\,+\|D_{n+1}\,P(Q^{n})\|^{2}+\|V_{n}\,\nabla
P(Q^{n})\|^{2}\Big{)}\coloneqq C\sum_{m=1}^{5}I_{m}.$

We will estimate $I_{1}$ to $I_{5}$ separately. For $I_{1}$, taking derivative
of $r$ and use Lipschitz continuity of $P(Q)$, we have

(3.11) $\displaystyle I_{1}=\int_{\Omega}\lvert\nabla
r(Q^{n+1})\rvert^{2}\,\lvert P(Q^{n})\rvert^{2}\,dx$
$\displaystyle\leq\int_{\Omega}\lvert P(Q^{n+1})\rvert^{2}\,\lvert\nabla
Q^{n+1}\rvert^{2}\,\lvert P(Q^{n})\rvert^{2}\,dx\leq
C\int_{\Omega}\lvert\nabla Q^{n+1}\rvert^{2}\lvert Q^{n+1}\rvert^{2}\,\lvert
Q^{n}\rvert^{2}\,dx.$

Then by Holder’s inequality and Sobolev’s inequality, we obtain

(3.12) $\displaystyle I_{1}\leq C\|\nabla
Q^{n+1}\|_{L^{6}}^{2}\,\|Q^{n+1}\|_{L^{6}}^{2}\,\|Q^{n}\|_{L^{6}}^{2}$
$\displaystyle\leq
C\|Q^{n+1}\|_{H^{2}}^{2}\,\|Q^{n+1}\|_{H^{1}}^{2}\,\|Q^{n}\|_{H^{1}}^{2}\leq
C(1+\|\Delta Q^{n+1}\|^{2})$

We will treat $I_{2}$ in similar ways. Lipschitz continuity and Holder’s
inequality leads to

(3.13) $\displaystyle I_{2}=\int_{\Omega}\lvert
r(Q^{n})\rvert^{2}\,\lvert\nabla P(Q^{n})\rvert^{2}\,dx$ $\displaystyle\leq
C\int_{\Omega}\lvert r(Q^{n})\rvert^{2}\,\lvert\nabla Q^{n}\rvert^{2}\,dx\leq
C\left(\int_{\Omega}\lvert
r(Q^{n})\rvert^{3}\,dx\right)^{\frac{2}{3}}\,\left(\int_{\Omega}\lvert\nabla
Q^{n}\rvert^{6}\,dx\right)^{\frac{1}{3}}.$

It then follows from definition of $r(Q^{n})$ and Sobolev’s embedding theorem
that

(3.14) $I_{2}\leq C(1+\|Q^{n}\|^{2}_{L^{6}})\,\|Q^{n}\|_{H^{2}}^{2}\leq
C\|Q^{n}\|^{2}_{H^{1}}\,\|Q^{n}\|_{H^{2}}^{2}\leq C(1+\|\Delta Q^{n}\|^{2}).$

To bound the term $I_{3}$, we notice that

(3.15) $\displaystyle I_{3}=\int_{\Omega}\lvert
P(Q^{n}):(Q^{n+1}-Q^{n})\rvert^{2}\,\lvert\nabla P(Q^{n})\rvert^{2}\,dx\leq
C\int_{\Omega}\lvert Q^{n}\rvert^{2}\,\lvert
Q^{n+1}-Q^{n}\rvert^{2}\,\lvert\nabla Q^{n}\rvert^{2}\,dx,$

and we can deduce

(3.16) $\displaystyle I_{3}\leq
C\|Q^{n}\|_{L^{6}}^{2}\,\|Q^{n+1}-Q^{n}\|_{L^{6}}^{2}\,\|\nabla
Q^{n}\|^{2}_{L^{6}}$ $\displaystyle\leq
C\|Q^{n}\|_{H^{1}}^{2}\|Q^{n}\|_{H^{2}}^{2}\left\|\frac{\nabla Q^{n+1}-\nabla
Q^{n}}{\Delta t}\right\|^{2}\,\Delta t^{2}$ $\displaystyle\leq C(1+\|\Delta
Q^{n}\|^{2})\,\Delta t\,\left[\sum_{k=0}^{n}\left\|\frac{\nabla Q^{k+1}-\nabla
Q^{k}}{\Delta t}\right\|^{2}\,\Delta t\right]$

The remaining problem is to control the error terms generated from
introduction of the auxiliary variable. For term $I_{4}$, we have

(3.17) $\displaystyle I_{4}=\int_{\Omega}\lvert D_{n+1}\rvert^{2}\,\lvert
P(Q^{n})\rvert^{2}\,dx\leq
C\int_{\Omega}\left[\sum_{k=0}^{n}\left(\lvert\nabla Q^{k}\rvert+\lvert\nabla
Q^{k+1}\rvert\right)\,\left\lvert Q^{k+1}-Q^{k}\right\rvert\right]^{2}\,\lvert
Q^{n}\rvert^{2}\,dx.$

Bounding $\lvert Q^{n}\rvert$ by $\|Q^{n}\|_{L^{\infty}}$ and using Cauchy-
Schwarz inequality, we will obtain

(3.18) $I_{4}\leq
C\|Q^{n}\|_{L^{\infty}}^{2}\sum_{k=0}^{n}\left[\left(\int_{\Omega}\lvert\nabla
Q^{k}\rvert^{4}\,dx\right)^{\frac{1}{2}}+\left(\int_{\Omega}\lvert\nabla
Q^{k+1}\rvert^{4}\,dx\right)^{\frac{1}{2}}\right]\left(\int_{\Omega}\lvert
Q^{k+1}-Q^{k}\rvert^{4}\,dx\right)^{\frac{1}{2}}.$

Agmon’s inequality and Sobolev’s inequality enable us to estimate $I_{4}$ by

(3.19) $\displaystyle I_{4}$ $\displaystyle\leq C(1+\|\Delta
Q^{n}\|)\,\sum_{k=0}^{n}\left(1+\|\Delta Q^{k}\|^{2}+\|\Delta
Q^{k+1}\|^{2}\right)\,\left\|\frac{\nabla Q^{k+1}-\nabla Q^{k}}{\Delta
t}\right\|^{2}\,\Delta t^{2}$ $\displaystyle\leq C(1+\|\Delta
Q^{n}\|^{2})\,\left[\sum_{k=0}^{n}\left\|\frac{\nabla Q^{k+1}-\nabla
Q^{k}}{\Delta t}\right\|^{2}\,\Delta t\right],$

where we have used Lemma 2.4 in the last inequality. Using Cauchy-Schwarz
inequality, we yield

(3.20) $\displaystyle I_{5}=\int_{\Omega}\lvert V_{n}\rvert^{2}\lvert\nabla
P(Q^{n})\rvert^{2}\,dx\leq C\int_{\Omega}\left[\sum_{k=0}^{n-1}\lvert
Q^{k+1}-Q^{k}\rvert^{2}\right]^{2}\,\lvert\nabla
Q^{n}\rvert^{2}\,dx\leq\frac{C}{\Delta
t}\sum_{k=0}^{n-1}\int_{\Omega}\lvert\nabla Q^{n}\rvert^{2}\lvert
Q^{k+1}-Q^{k}\rvert^{4}\,dx.$

Applying Holder’s inequality and Sobolev’s inequality, we get

(3.21) $\displaystyle I_{5}$ $\displaystyle\leq\frac{C}{\Delta
t}\sum_{k=0}^{n-1}\left(\int_{\Omega}\lvert\nabla
Q^{n}\rvert^{6}\,dx\right)^{\frac{1}{3}}\,\left(\int_{\Omega}\lvert
Q^{k+1}-Q^{k}\rvert^{6}\,dx\right)^{\frac{2}{3}}$
$\displaystyle\leq\frac{C}{\Delta
t}\sum_{k=0}^{n-1}\|Q^{n}\|_{H^{2}}^{2}\left\|\frac{\nabla Q^{k+1}-\nabla
Q^{k}}{\Delta t}\right\|^{4}\Delta t^{4}\leq C\Delta t(1+\|\Delta
Q^{n}\|^{2})\,\left(\sum_{k=0}^{n-1}\|\frac{\nabla Q^{k+1}-\nabla
Q^{k}}{\Delta t}\|\Delta t\right)^{2}$

Combining theses estimates together, we have shown the lemma.

∎

The inner products that appeared in the formula are well-defined due to
regularity results given in Lemma 2.1. Then we immediately have the following
lemma, which provides the desired bound for the Q-tensor term.

######  Lemma 3.2.

We define

(3.22) $W_{n}\coloneqq\frac{L}{2}\,\|\Delta
Q^{n}\|^{2}+\frac{1}{2M}\sum_{k=0}^{n-1}\|\frac{\nabla Q^{k+1}-\nabla
Q^{k}}{\Delta t}\|^{2}\,\Delta t,$

with $n\geq 1$. Then for small enough $\Delta t$, there exists $C=C(W_{0},T)$
such that $W_{n}\leq C(W_{0},T)$ for any $n>1$.

###### Proof.

We will prove this lemma by induction. Firstly, noting that (3.8) is
equivalent to

(3.23) $\frac{W_{n+1}-W_{n}}{\Delta t}\leq
C\|\nabla\left(r^{n+1}P(Q^{n})\right)\|^{2}.$

We infer from Lemma 3.1 that

(3.24) $W_{n+1}-W_{n}\leq C\Delta t+C(1+\|\Delta Q^{n}\|^{2})\,\Delta
t\,(1+W_{n+1}+W_{n}+W_{n}^{2}\Delta t+W_{n+1}\Delta t).$

for every $n>0$. Assuming $W_{n}$ is bounded for all $n\leq N-1$, we will
prove that $W_{N}$ is also bounded by the same constant. We choose $\Delta
t\leq\max\limits_{n\leq N-1}\\{1,\frac{1}{W_{n}}\\}$. Later we will show that
such $\Delta t$ exists uniformly for all $n$. Summing (3.24) from $n=0$ to
$N-1$, we get

(3.25) $W_{N}\leq W_{0}+CT+C\Delta t\,\sum_{n=0}^{N-1}(1+\|\Delta
Q^{n}\|^{2})\,(W_{n+1}+W_{n})$

By applying discrete Gronwall’s inequality[21, Lemma 2.1] and using the energy
estimate Lemma 2.4, we conclude that

(3.26) $W_{n}\leq(W_{0}+CT)\,e^{C(M,T)},$

where $M$ is the constant (upper bound) given in Lemma 2.4. This is a uniform
bound for $W_{n}$ independent of $n$ which implies that $\frac{1}{W_{n}}$ is
lower bounded. So appropriate $\Delta t$ can always be found. Here we have
shown that $W_{n}\leq(W_{0}+CT)\,e^{C(M,T)}\coloneqq C(W_{0},T)$ for all
$n>0$. ∎

This is a uniform $H^{2}$ estimate for Q-tensor term and provides higher
regularity result of the derivative in discrete sense. To the end of this
part, we turn to investigate the relations between $\nabla H^{n+1}$ and
$\nabla\Delta Q^{n+1}$. Firstly, for each fixed $\Delta t$, $\nabla
H^{n+1}=\frac{\nabla Q^{n+1}-\nabla Q^{n}}{M\Delta t}\in H^{1}(\Omega)$. It
implies $L\nabla\Delta Q^{n+1}=\nabla H^{n+1}+\nabla(r^{n+1}P(Q^{n}))\in
L^{2}$ is well-defined. Then by Lemma 3.2 and Lemma 3.1, we can bound
$\|\nabla(r^{n+1}P(Q^{n}))\|$ by constant and so

(3.27) $\sum_{n=0}^{N}\|\nabla\Delta Q^{n+1}\|^{2}\,\Delta t\leq
C\left(\|H^{n+1}\|^{2}+\|\nabla(r^{n+1}P(Q^{n}))\|^{2}\right)\,\Delta t\leq
C(1+\|H^{n+1}\|^{2})\,\Delta t.$

This can be summarized as the following lemma.

######  Lemma 3.3.

The numerical solutions obtained from scheme (2.1)-(2.2) satisfies,
$\sum_{n=0}^{N}\|\nabla\Delta Q^{n+1}\|^{2}\,\Delta t<C$, for some constant
$C>0$ and $N=\lfloor\frac{T}{\Delta t}\rfloor$.

###  3.2. Convergence to Strong Solution

We construct linear interpolation numerical solution as

(3.28) $Q_{\Delta
t}(t)=\sum_{n=0}^{N-1}\left[\alpha_{n+1}(t)\,Q^{n}+\alpha_{n}(t)\,Q^{n+1}\right]\,\chi_{S_{n}},\quad\quad
r_{\Delta
t}(t)=\sum_{n=0}^{N-1}\left[\alpha_{n+1}(t)\,r^{n}+\alpha_{n}(t)\,r^{n+1}\right]\,\chi_{S_{n}},$

where $\alpha_{n}(t)=\frac{t-n\Delta t}{\Delta t}$,
$\alpha_{n+1}(t)=\frac{(n+1)\Delta t-t}{\Delta t}$, $S_{n}=[n\Delta
t,(n+1)\Delta t)$ and $\chi_{S_{n}}$ is the characteristic function on
$S_{n}$.

######  Theorem 3.4.

Given initial value $Q_{in}\in H^{2}(\Omega)$, for fixed $T>0$, there exists a
subsequence of numerical solution, denoted by $\\{Q_{\Delta t_{m}}\\}_{m}$
such that $Q_{\Delta t_{m}}\to Q$ in $L^{2}(0,T;H^{2}(\Omega))$ and $Q$ is a
strong solution for equation (1.2).

###### Proof.

We infer from Lemma 3.2 and 3.3 that

(3.29) $Q_{\Delta t}\in L^{\infty}(0,T;H^{2}(\Omega))\bigcap
L^{2}(0,T;H^{3}(\Omega)),\quad\quad\partial_{t}Q_{\Delta t}\in
L^{\infty}(0,T;L^{2}(\Omega))\bigcap L^{2}(0,T;H^{1}(\Omega)).$

The Sobolev’s embedding implies that $Q_{\Delta t}\in
L^{\infty}([0,T]\times\Omega)$ and Lipschitz continuity of $P(Q)$ leads to
$P(Q_{\Delta t})\in L^{\infty}([0,T]\times\Omega)$. Applying Aubin-Lions lemma
and Banach–Alaoglu theorem, we conclude that there exists a pair of
subsequence $\\{(Q_{\Delta t_{m}},r_{\Delta t_{m}})\\}_{m}$ and a pair of
functions $(Q,r)$ such that

(3.30) $Q\in L^{2}\left(0,T;H^{3}(\Omega)\right)\bigcap
L^{\infty}\left(0,T;H^{2}(\Omega)\right)\bigcap
H^{1}\left(0,T;H^{1}(\Omega)\right),\quad\quad r\in
L^{\infty}([0,T];L^{2}(\Omega)),$

and

(3.31) $\displaystyle Q_{\Delta t_{m}}\rightharpoonup
Q\quad\text{in}\,\,L^{2}\left(0,T;H^{3}(\Omega)\right)\bigcap
H^{1}(0,T;H^{1}(\Omega)),\quad\quad Q_{\Delta
t_{m}}\overset{\ast}{\rightharpoonup}Q\quad\text{in}\,\,L^{\infty}(0,T;H^{2}(\Omega))$
$\displaystyle Q_{\Delta t_{m}}\to
Q\quad\text{in}\,\,L^{2}(0,T;H^{2}(\Omega))\bigcap
C(0,T;H^{1}(\Omega)),\quad\quad r_{\Delta
t_{m}}\overset{\ast}{\rightharpoonup}r\quad\text{in
}L^{\infty}([0,T];L^{2}(\Omega))$

To see that $r=r(Q)$, we introduce $r(Q)_{\Delta
t}=\sum_{n=0}^{N-1}\left[\frac{(n+1)\Delta t-t}{\Delta
t}\,r(Q^{n})+\frac{t-n\Delta t}{\Delta t}\,r(Q^{n+1})\right]\,\chi_{S_{n}}$.
Noting that as long as $Q$ is uniformly bounded, $r(Q)$ will be Lipschitz
continuous where the Lipschitz constant is bounded by $C(W_{0},T)$ stated in
Lemma 3.2. Then for every $t\in[0,T]$, assume $t\in[(n-1)\Delta t,n\Delta t)$
for some $n\geq 1$, we have

(3.32) $\displaystyle\|r_{\Delta t_{m}}-r(Q)\|^{2}$ $\displaystyle\leq
2\|r_{\Delta t_{m}}-r(Q)_{\Delta t_{m}}\|^{2}+2\|r(Q)_{\Delta
t_{m}}-r(Q)\|^{2}$ $\displaystyle\leq C\max\limits_{1\leq n\leq
N}\left(\|r^{n-1}-r(Q^{n-1})\|^{2}+\|r^{n}-r(Q^{n})\|^{2}\right)+C\|Q-Q_{\Delta
t_{m}}\|^{2}$ $\displaystyle\leq C\left\|\sum_{k=0}^{N-1}\lvert
Q^{k+1}-Q^{k}\rvert^{2}\right\|^{2}+C\|Q-Q_{\Delta t_{m}}\|^{2}$
$\displaystyle\leq C\Delta t_{m}\,\left(\sum_{k=0}^{N-1}\left\|\frac{\nabla
Q^{k+1}-\nabla Q^{k}}{\Delta t_{m}}\right\|^{2}\,\Delta
t_{m}\right)^{2}+C\|Q-Q_{\Delta t_{m}}\|^{2}\to 0,$

as $m\to\infty$ where we have used Lemma 3.2. So we have shown that $r=r(Q)$
and $r_{\Delta t_{m}}\to r(Q)$ in $C([0,T];L^{2}(\Omega))$. By passing the
limit to infinity, we can see that $Q_{t}=M(L\Delta Q-rP(Q))$ and with
$rP(Q)=r(Q)P(Q)=S(Q)$, we obtain that $Q$ is a strong solution for equation
(1.2).

∎

## References

  * [1] H. Abels, G. Dolzmann, and Y. Liu.  Strong solutions for the beris-edwards model for nematic liquid crystals with homogeneous dirichlet boundary conditions.  Advances in Differential Equations, 21, 12 2013.
  * [2] H. Abels, G. Dolzmann, and Y. Liu.  Well-posedness of a fully coupled navier–stokes/q-tensor system with inhomogeneous boundary data.  SIAM Journal on Mathematical Analysis, 46(4):3050–3077, 2014.
  * [3] J. M. Ball.  Mathematics and liquid crystals.  Molecular Crystals and Liquid Crystals, 647(1):1–27, 2017.
  * [4] C. Cavaterra, E. Rocca, H. Wu, and X. Xu.  Global strong solutions of the full navier–stokes and $q$-tensor system for nematic liquid crystal flows in two dimensions.  SIAM Journal on Mathematical Analysis, 48(2):1368–1399, 2016.
  * [5] P. Collings and M. Hird.  Introduction to Liquid Crystals: Chemistry and Physics.  Liquid Crystals Book Series. CRC Press, 1997.
  * [6] P. de Gennes and J. Prost.  The Physics of Liquid Crystals.  International Series of Monographs on Physics. Clarendon Press, 1993.
  * [7] L. C. Evans.  Partial differential equations.  American Mathematical Society, Providence, R.I., 2010.
  * [8] P. Grisvard.  Elliptic Problems in Nonsmooth Domains.  Society for Industrial and Applied Mathematics, 2011.
  * [9] V. M. Gudibanda, F. Weber, and Y. Yue.  Convergence analysis of a fully discrete energy-stable numerical scheme for the q-tensor flow of liquid crystals.  SIAM Journal on Numerical Analysis, 60(4):2150–2181, 2022.
  * [10] F. Guillén-González and M. Ángeles RodrÍguez-Bellido.  Weak time regularity and uniqueness for a $q$-tensor model.  SIAM Journal on Mathematical Analysis, 46(5):3540–3567, 2014.
  * [11] G. Iyer, X. Xu, and A. Zarnescu.  Dynamic cubic instability in a 2d q-tensor model for liquid crystals.  Mathematical Models and Methods in Applied Sciences, 25:1477–1517, 06 2015.
  * [12] H. G. Lee, J. Shin, and J.-Y. Lee.  Energy quadratization runge–kutta scheme for the conservative allen–cahn equation with a nonlocal lagrange multiplier.  Applied Mathematics Letters, 132:108161, 2022.
  * [13] C. Liu and N. J. Walkington.  Approximation of liquid crystal flows.  SIAM Journal on Numerical Analysis, 37(3):725–741, 2000.
  * [14] Z. Liu and X. Li.  Efficient modified techniques of invariant energy quadratization approach for gradient flows.  Applied Mathematics Letters, 98:206–214, 2019.
  * [15] A. Majumdar and A. Zarnescu.  Landau–de gennes theory of nematic liquid crystals: the oseen–frank limit and beyond.  Archive for Rational Mechanics and Analysis, 196:227–280, 04 2010\.
  * [16] H. Mori, E. C. Gartland, J. R. Kelly, and P. J. Bos.  Multidimensional director modeling using the q tensor representation in a liquid crystal cell and its application to the cell with patterned electrodes.  Japanese Journal of Applied Physics, 38(Part 1, No. 1A):135–146, jan 1999.
  * [17] N. J. Mottram and C. J. P. Newton.  Introduction to q-tensor theory, 2014.
  * [18] R. H. Nochetto, S. W. Walker, and W. Zhang.  A finite element method for nematic liquid crystals with variable degree of orientation.  SIAM Journal on Numerical Analysis, 55(3):1357–1386, 2017.
  * [19] M. Paicu and A. Zarnescu.  Global existence and regularity for the full coupled navier–stokes and q-tensor system.  SIAM Journal on Mathematical Analysis, 43(5):2009–2049, 2011.
  * [20] N. Schopohl and T. J. Sluckin.  Defect core structure in nematic liquid crystals.  Phys. Rev. Lett., 59:2582–2584, Nov 1987.
  * [21] J. Shen.  On error estimates of the projection methods for the navier-stokes equations: Second-order schemes.  Math. Comput., 65:1039–1065, 07 1996.
  * [22] J. Shen, J. Xu, and J. Yang.  A new class of efficient and robust energy stable schemes for gradient flows.  SIAM Review, 61(3):474–506, 2019.
  * [23] W.-J. Shin, S.-Y. Cho, J.-B. Lee, S.-H. Yoon, and T.-Y. Won.  Implementation of q-tensor model in three-dimensional finite element method simulator.  Japanese Journal of Applied Physics, 47:5561–5566, 07 2008.
  * [24] J. Simon.  Compact sets in the space lp(o,t; b).  Annali di Matematica Pura ed Applicata, 146:65–96, 01 1986.
  * [25] R. Temam.  Infinite-Dimensional Dynamical Systems in Mechanics and Physics.  Applied Mathematical Sciences. Springer New York, 1997.
  * [26] H. W. Turnbull.  A matrix form of taylor’s theorem.  Proceedings of the Edinburgh Mathematical Society, 2(1):33–54, 1930.
  * [27] M. Wang, W. Wendong, and Z. Zhang.  From the q-tensor flow for the liquid crystal to the harmonic map flow.  Archive for Rational Mechanics and Analysis, 225, 08 2017.
  * [28] X. Yang.  Linear, first and second-order, unconditionally energy stable numerical schemes for the phase field model of homopolymer blends.  Journal of Computational Physics, 327:294–316, 2016.
  * [29] X. Yang and J. Zhao.  On linear and unconditionally energy stable algorithms for variable mobility cahn-hilliard type equation with logarithmic flory-huggins potential.  01 2017.
  * [30] X. Yang, J. Zhao, Q. Wang, and J. Shen.  Numerical approximations for a three-component cahn–hilliard phase-field model based on the invariant energy quadratization method.  Mathematical Models and Methods in Applied Sciences, 27(11):1993–2030, 2017.
  * [31] J. Zhao.  A revisit of the energy quadratization method with a relaxation technique.  Applied Mathematics Letters, 120:107331, 2021.
  * [32] J. Zhao, X. Yang, Y. Gong, and Q. Wang.  A novel linear second order unconditionally energy stable scheme for a hydrodynamic q-tensor model of liquid crystals.  Computer Methods in Applied Mechanics and Engineering, 318:803–825, 2017.
  * [33] J. Zhao, X. Yang, J. Li, and Q. Wang.  Energy stable numerical schemes for a hydrodynamic model of nematic liquid crystals.  SIAM Journal on Scientific Computing, 38(5):A3264–A3290, 2016.


# Parma: Confidential Containers via Attested Execution Policies

Matthew A. Johnson  Azure Research  Stavros Volos  Azure Research  Ken Gordon
Azure Research  Sean T. Allen  Azure Research  Christoph M. Wintersteiger
Azure Research  Sylvan Clebsch  Azure Research  John Starks  Azure Research
Manuel Costa  Azure Research

###### Abstract

Container-based technologies empower cloud tenants to develop highly portable
software and deploy services in the cloud at a rapid pace. Cloud privacy,
meanwhile, is important as a large number of container deployments operate on
privacy-sensitive data, but challenging due to the increasing frequency and
sophistication of attacks. State-of-the-art confidential container-based
designs leverage process-based trusted execution environments (TEEs), but face
security and compatibility issues that limits their practical deployment.

We propose Parma, an architecture that provides lift-and-shift deployment of
unmodified containers while providing strong security protection against a
powerful attacker who controls the untrusted host and hypervisor. Parma
leverages VM-level isolation to execute a container group within a unique VM-
based TEE. Besides container integrity and user data confidentiality and
integrity, Parma also offers container attestation and execution integrity
based on an attested execution policy. Parma execution policies provide an
inductive proof over all future states of the container group. This proof,
which is established during initialization, forms a root of trust that can be
used for secure operations within the container group without requiring any
modifications of the containerized workflow itself (aside from the inclusion
of the execution policy.)

We evaluate Parma on AMD SEV-SNP processors by running a diverse set of
workloads demonstrating that workflows exhibit 0–26% additional overhead in
performance over running outside the enclave, with a mean 13% overhead on
SPEC2017, while requiring no modifications to their program code. Adding
execution policies introduces less than 1% additional overhead. Furthermore,
we have deployed Parma as the underlying technology driving Confidential
Containers on Azure Container Instances.

##  1 Introduction

(a)

(b)

Figure 1:  Execution Policy. The execution policy is a component of the
utility VM that is attested at initialization time. It describes all of the
actions the user has explicitly allowed the guest agent to take within the
container group. In (a) we see an example of a successful mount action, in
which a layer of a container image has a dm-verity root hash which matches a
hash enumerated in the policy. When the hash does not match, as in (b), this
action is denied.

Since the launch of the large-scale Infrastructure-as-a-Service (IaaS)
offerings from Amazon (AWS in 2006), Microsoft (Azure in 2008), and Google
(GCP in 2008), there has been a continuous trend towards cloud computing,
which allows customers to leverage capability and cost advantages through
economies of scale. This was made possible through virtualization [9], whereby
virtual machines (VMs) allow the efficient use of large bare-metal compute
architectures (hosts) by using a hypervisor to coordinate sharing between
multiple tenants according to their expressed usage requirements. However,
while VMs provide a way for users to quickly obtain additional compute
capacity and maximize the utilization of existing hardware (and/or avoid the
cost of maintaining peak capacity by utilizing a public cloud), it is still
necessary to configure, deploy, manage, and maintain VMs using traditional
techniques.

In recent years, container-based technologies, such as Docker [19] and
Kubernetes [25] have arisen to address this orthogonal need, providing a
lightweight solution for creating a set of machine configurations, called
containers, which can be deployed onto hardware (virtualized or physical) as a
group via an automated process. Container technology provides multiple
separated user-space instances which are isolated from one another via kernel
software. Unlike VMs, containers run directly on the host system (sharing its
kernel) and as such do not need to emulate devices or maintain large disk
files. Further, containers defined according to the OCI Distribution
Specification [30] specify dependencies as _layers_ which can be shared
between different containers, making them amenable to caching and thus
speeding up deployment while reducing storage costs for multiple containers.
The success of containerization technology for on-premises systems has led to
major cloud providers developing their own Container-as-a-Service (CaaS)
offerings [1, 3, 22] which provide customers the ability to maintain and
deploy containers in the public cloud. In CaaS offerings, containers run in a
per-group utility VM (UVM) which provides hypervisor-level isolation between
containers running from different tenants on the same host. While the
container manager and container shim running on the host are responsible for
pulling images from the container registry, bringing up the utility VM, and
orchestrating container execution, an agent running within the utility VM (the
guest agent) coordinates the container workflow as directed by the host-side
container shim.

Cloud computing poses unique risks. Although VMs and VM-isolated container
groups provide strong isolation between tenants, they are deployed by the
cloud service provider (CSP) and coordinated by the CSP’s hypervisor. As such,
the host operating system (including the container manager and container shim)
and the hypervisor all lie within the Trusted Computing Base (TCB). Research
into confidential cloud computing attempts to reduce the attack surface by
leveraging specialized hardware-enforced Trusted Execution Environments (TEEs)
[8, 11, 13, 15, 20, 27, 29, 37, 38], which enable user workloads to be
protected inside _enclaves_ even if the host’s software is compromised or
controlled by a malicious entity. TEEs available from major CPU vendors can be
either process-based, such as Intel SGX [23] and ARM TrustZone [6], or VM-
based, such as AMD SEV-SNP [4, 26], Intel TDX [24] and ARM CCA [5, 28]. VM-
based TEEs offer hardware-level isolation of the VM, preventing the host
operating system and the hypervisor from having access to the VM’s memory and
registers.

With CaaS, container execution is orchestrated by a host-side shim that
communicates with the guest agent, which coordinates the activity of the
container group within the UVM. The UVM can be hardware-isolated within a TEE
enclave, but the container images are controlled by the host, as is the order
in which they are mounted, the container environment variables, the commands
that are sent to the containers via the bridge between the container shim and
the guest agent, and so forth. This means that a compromised host can overcome
the hardware isolation of the VM by injecting malicious containers. This risk
of attack, be it from malicious or compromised employees of the CSP or
external threats, limits the extent to which containerization can be used in
the cloud for sensitive workloads in industries like finance and healthcare.

The naive solution to this problem is to run the guest agent and container
shim within the same VM-based TEE. This removes the CSP from the TCB, but it
also removes the CSP’s ability to orchestrate and automate the container
workflow. In addition, the container owner is then in the TCB. The container
images are controlled by the container owner, as is the order in which they
are mounted, the container environment variables, and the commands that are
sent to the containers. The end-user of the confidential container (e.g., a
customer of a bank, a patient providing data to a doctor) must trust that the
container owner has and will run only the expected commands. This also leaves
image integrity and data confidentiality and integrity unsolved.

##### Our work.

We present Parma, an architecture that implements the confidential containers
abstraction on a state-of-the-art containerd [14] stack running on processors
with VM-based TEE support (i.e., AMD SEV-SNP processors). Parma provides a
lift-and-shift experience and the ability to run unmodified containers pulled
from (unmodified) container registries while providing strong security
guarantees: container attestation and integrity, meaning that only customer-
specified containers can run within the TCB and any means of container
tampering is detected by the TCB; and user data confidentiality and integrity,
meaning that only the TCB has access to the user’s data and any means of data
tampering is detected by the TCB.

Parma provides strong protection for the container’s root filesystem
(comprised of the container image layers and writeable scratch space) and the
user’s data. For container image layers (pulled in plaintext by the untrusted
container manager and stored in a host-side block device), Parma mounts the
device as an integrity-protected read-only filesystem (using dm-verity) and
relies on the filesystem driver to enforce integrity checking upon an access
to the filesystem. For confidentiality and integrity of privacy-sensitive data
stored in a block device (e.g., writeable scratch space of the container’s
root filesystem) or blob storage (e.g., remote blobs holding user data), Parma
relies on block-level encryption and integrity (using dm-crypt + dm-integrity)
to decrypt memory-mapped blocks, guaranteeing that data appears in plaintext
only within the VM’s hardware-protected memory.

Finally, Parma provides container attestation rooted in a hardware-issued
attestation by enforcing attested user-specified _execution policies_. We have
augmented the guest agent to enforce the execution policy such that it only
executes commands (submitted by the untrusted container shim) which are
explicitly allowed by the user, as seen in Figure 1. The policy is attested by
encoding its measurement in the attestation report as an immutable field at
UVM initialization. As a result of including the execution policy, the
hardware-issued attestation forms an inductive proof over the future state of
the container group. The attestation can then be used downstream for
operations needed by secure computation. For example, remote verifiers may
release keys (governing the user’s encrypted data) to only those container
groups which can present an attestation report encoding the expected execution
policy and measurement of the utility VM.

##### Contributions:

The main contributions of our work are:

  * •

Parma, a novel security architecture for confidential containerized workloads.
Parma establishes security guarantees rooted in an inductive proof over all
future states of the container group provided by the introduction of an
attested execution policy.

  * •

an implementation of Parma which forms the basis for Confidential Containers
on Azure Container Instances [2] and is publicly available on GitHub
111https://github.com/microsoft/hcsshim/tree/main/pkg/securitypolicy.

  * •

neither requiring changes to existing containers, nor container image signing.
Instead, the execution policy ensures that only the actions the user has
explicitly expressed are allowed to take place within the container group,
maintaining support for existing CaaS deployment practices.

  * •

an evaluation of our implementation with standard benchmarks for computation,
network, and database activity. We compare a base container system to
containers running within a TEE enclave with and without Parma. We demonstrate
that Parma introduces 0–26% additional overhead in performance over running
outside the enclave, with a mean 13% overhead on SPEC2017, and that adding
execution policies introduces less than 1% additional overhead.

There were also significant implementation challenges, including SEV-SNP
enablement in the hypervisor, bounce buffers for I/O, Linux enlightenment for
SEV-SNP including attestation report fetching, and hardening the hypervisor
interface. These are not claimed as contributions.

##  2 Background

We will begin by introducing the technological dependencies of Parma, namely
Trusted Execution Environments (TEEs) and the AMD SEV-SNP architecture.

###  2.1 Trusted Execution Environments

There have been many proposed security architectures which aim to provide a
TEE [26, 8, 11, 15, 23, 27]. The goal of a TEE is to isolate workloads from
the host system in order to protect them against manipulation whilst running.
Most architectures provide secure environments, typically called _enclaves_ ,
which run in parallel with the underlying host operating system. As such, the
Trusted Computing Base (TCB) contains the required hardware which provides the
needed security capabilities and the software to utilize it to maintain the
guarantees of the TEE. While each TEE architecture has its own idiosyncrasies,
there are desirable qualities which increase their utility:

Small TCB

Minimizing the TCB is essential to reduce the attack surface of the TEE.

Strong Isolation

The enclaves must be isolated from the host at all times, including the
register state and memory.

Attestable State

The boot-up process and state of the TEE must be verifiable using attestation.

Minimal Overhead

High performance costs incurred by using the TEE greatly minimize utility.

Minimal Adoption Cost

While perhaps not a goal shared by all TEEs, greater utility is achieved if
running code in the TEE does not require significant reworking of a workflow
(e.g., rewriting software to target an enclave-specific subset of a language,
requiring custom tool-chains).

###  2.2 AMD Secure Encrypted Virtualization-Secure Nested Paging

The commercially available TEE offering from AMD is called Secure Encrypted
Virtualization (SEV) [26] and targets cloud servers. As indicated in the name,
it is focused on protecting Virtual Machines (VMs) from a malicious host or
hypervisor. We use a specialization of SEV called SEV-SNP [4] (Secure Nested
Paging). AMD SEV-SNP is available in AMD’s EPYC Milan processors and extends
the SEV and SEV-ES (Encrypted State) technologies, which offer isolation of a
VM by providing encrypted memory and CPU register state. AMD SEV-SNP adds
memory integrity protection to ensure that a VM is able to read the most
recent values written to an encrypted memory page. In doing so, it provides
protection against data replay, corruption, remapping- and aliasing-based
attacks.

####  2.2.1 Platform Security Processor

The Platform Security Processor firmware (PSP) implements the security
environment for hardware-isolated VMs. The PSP provides a unique identity to
the CPU by deriving the Versioned Chip Endorsement Key (VCEK) from chip-unique
secrets and the current TCB version. The PSP also provides ABI functions for
managing the platform, the life-cycle of a guest VM, and data structures
utilized by the PSP to maintain integrity of memory pages.

####  2.2.2 Memory Encryption

AMD Secure Memory Encryption (SME) [26] is a general-purpose mechanism for
main memory encryption that is flexible and integrated into the CPU
architecture. It is provided via dedicated hardware in the on-die memory
controllers that provides an Advanced Encryption Standard (AES) engine. This
encrypts data when it is written to DRAM, and then decrypts it when read,
providing protection against physical attacks on the memory bus and/or
modules. The key used by the AES engine is randomly generated on each system
reset and is not visible to any process running on the CPU cores. Instead, the
key is managed entirely by the PSP. Each VM has memory encrypted with its own
key, and can choose which data memory pages they would like to be private.
Private memory is encrypted with a guest-specific key, whereas shared memory
may be encrypted with a hypervisor key.

####  2.2.3 Secure Nested Paging

The memory encryption provided by AMD-SEV is necessary but not sufficient to
protect against runtime manipulation. In particular, it does not protect
against _integrity attacks_ such as:

Replay

The attacker writes a valid past block of data to a memory page. This is of
particular concern if the attacker knows the unencrypted data.

Data Corruption

If the attacker can write to a page then even if it is encrypted they can
write random bytes, corrupting the memory.

Memory Aliasing

A malicious hypervisor maps two or more guest pages to the same physical page,
such that the guest corrupts its own memory.

Memory Re-Mapping

A malicious hypervisor can also map one guest page to multiple physical pages,
so that the guest has an inconsistent view of memory where only a subset of
the data it wrote appears.

####  2.2.4 Reverse Map Table

The relationship between guest pages and physical pages is maintained by a
structure called a Reverse Map Table (RMP). It is shared across the system and
contains one entry for every 4k page of DRAM that may be used by VMs. The
purpose of the RMP is to track the owner for each page of memory, and control
access to memory so that only the owner of the page can write it. The RMP is
used in conjunction with standard x86 page tables to enforce memory
restrictions and page access rights. When running in an AMD SEV-SNP VM, the
RMP check is slightly more complex. AMD-V 2-level paging (also called Nested
Paging) is used to translate a Guest Virtual Address (GVA) to a Guest Physical
Address (GPA), and then finally to a System Physical Address (SPA). The SPA is
used to index the RMP and the entry is checked [4].

####  2.2.5 Page Validation

Each RMP entry contains the GPA at which a particular page of DRAM should be
mapped. While the nested page tables ensure that each GPA can only map to one
SPA, the hypervisor may change these tables at any time. Thus, inside each RMP
entry is a Validated bit, which is automatically cleared to zero by the CPU
when a new RMP entry is created for a guest. Pages which have the validated
bit cleared are not usable by the hypervisor or as a private guest page. The
guest can only use the page after it sets the Validated bit via a new
instruction, PVALIDATE. Only the guest is able to use PVALIDATE, and each
guest VM can only validate its own memory. If the guest VM only validates the
memory corresponding to a GPA once, then the injective mapping between GPAs
and SPAs is guaranteed.

####  2.2.6 Attestation

The PSP can issue hardware attestation reports capturing various security-
related attributes, constructed or specified during initialization and
runtime. Among other information, the resulting attestation report contains
the guest launch measurement, the host data, and the report data. The
attestation report is signed by the VCEK.

##### Initialization.

During VM launch, the PSP initializes a cryptographic digest context used to
construct the measurement of the guest. The hypervisor can insert data into
the the guest’s memory address space at the granularity of a page, during
which the cryptographic digest context is updated with the data, thereby
binding the measurement of the guest with all operations that the hypervisor
took on the guest’s memory contents. A special page is added by the hypervisor
to the guest memory, which is populated by the PSP with an encryption key that
establishes a secure communication channel between the PSP and the guest. Once
the VM launch completes, the PSP finalizes the cryptographic digest which is
encoded as the guest launch measurement in the attestation report. The
hypervisor may provide 256-bits of arbitrary data to be encoded as host data
in the attestation report.

##### Runtime.

The PSP generates attestation reports on behalf of a guest VM. The request and
response are submitted via the secure channel established during the guest
launch, ensuring that a malicious host cannot impersonate the guest VM. Upon
requesting a report, the guest may supply 512-bits of arbitrary data to be
encoded in the report as report data.

##  3 Parma Architecture

In this section, we present Parma, an architecture that implements the
confidential containers abstraction using attested execution policies. We
first describe the container platform which forms the basis of the Parma
design and implementation (3.1) and then provide a detailed description of the
threat model (3.2).

Finally, we present the security guarantees under the threat model and how
Parma provides these guarantees via a collection of design principles (3.3).
The guiding principle of Parma is to provide an inductive proof over the state
of a container group, rooted in the attestation report produced by the PSP.
The standard components and lifecycle for the container platform (the CPLAT)
are largely unchanged, with the exception of the guest agent, whose actions
become circumscribed by the execution policy (3.4). Thus constrained, the
future state of the system can be rooted in the measurement performed during
guest initialization.

###  3.1 Container Platform

The container platform (the CPLAT) is a group of components built around the
capabilities of containerd [14]. containerd is a daemon which manages the
complete container life-cycle, from image pull and storage to container
execution and supervision to low-level storage and network attachments.
containerd supports the Open Container Initiative (OCI) [30] image and runtime
specifications, and provides the substrate for multiple container offerings,
such as Docker [19], Kubernetes [25], and various cloud offerings [3, 1, 22].
Clients interact with containerd via a client interface, such as ctr, nerdctl,
or crictl. containerd supports both running bare metal containers (i.e., those
that run directly on the host) and also containers that run within a utility
VM (UVM).

Our work focuses on VM-isolated containers. The CPLAT interfaces with a custom
container shim running in the host operating system. The container shim
interacts with (i) host services to bring up a UVM required for launching a
new pod and (ii) the guest agent running in the UVM. The guest agent is
responsible for creating containers and spawning a runc instance for starting
the container. In essence, the container shim-guest agent path allows the
CPLAT components running in the host operating system to execute containers in
isolated guest VMs. The execution of a VM-isolated container on Linux using
CPLAT involves three high-level steps (as seen in Figure 2): (i) pull the
container’s image, (ii) launch a pod for hosting the container, (iii) start a
container.

Figure 2: Container Flow. The sequence diagram on the left shows the process
that results in a VM-isolated container. The pentagons correspond to the
workflow steps from the text: (i) pull the image, (ii) launch a pod, (iii)
start a container. The circles in this figure outline multiple points of
attack within this workflow: The container shim may pass a compromised (1) UVM
image or (2) guest agent during UVM creation. The container manager can alter
or fabricate malicious layer VHDs (3) and/or mount any combination of layers
onto to UVM (4). The container shim can pass any set of layers to use for
creating a container file system (5), as well as any combination of
environment variables or commands (6). A compromised host OS can tamper with
local storage (7), attack the memory of the UVM (8), or manipulate remote
communications (9). This list is not comprehensive.

Image pull

Pulling images entails downloading them from a container registry (unless they
are already cached on the machine). Once the pull is done, the image is
unpacked and the image for each layer of the container is stored as a virtual
hard drive.

Pod launch

Launching a pod entails creating and launching a UVM along with the guest
agent. Thereafter, the container shim interacts with the guest agent to create
and start containers. At the end of the pod launch, the container shim creates
and starts a sandbox/pause container that holds the Linux namespaces for
future containers.

Container start

Starting a container requires that the guest agent mounts the container’s root
filesystem into the UVM; the root filesystem comprises the container layers
and a writeable scratch layer. In doing so, the container shim (i) attaches
each container layer (in the OCI specification) to the UVM and (ii) creates
and attaches to the UVM a writeable sandbox virtual hard drive. The container
layer and sandbox devices are then mounted by the guest agent into the UVM as
an overlay root filesystem. Finally, the guest agent creates a runtime bundle
that contains the overlay filesystem path and configuration data (compiled
using the OCI runtime specification.) The runtime bundle is passed to the runc
instance, which subsequently starts the container.

###  3.2 Threat Model

We consider a strong adversary who controls the entire host system software,
including the hypervisor and the host operating system along with all services
running within it. However, we trust the CPU package, including the platform
security processor (PSP) and the AMD SEV-SNP implementation, which provides
hardware-based isolation of the guest’s address space from the system
software. We also trust the firmware running on the PSP and its measurements
of the guest VM, including the guest agent.

Such an adversary can:

  * •

tamper with the container’s OCI runtime specification;

  * •

tamper with block devices storing the read-only container image layers and the
writeable scratch layer;

  * •

tamper with container definitions, including the overlay filesystem (i.e.,
changing the order or injecting rogue layers), adding, altering, or removing
environment variables, altering the user command, and the mount sources and
destinations from the UVM.

  * •

add, delete, and make arbitrary modifications to network messages, i.e., fully
control the network.

  * •

request execution of arbitrary commands in the UVM and in individual
containers.

  * •

request debugging information from the UVM and running containers, such as
access to I/O, the stack, or container properties.

These capabilities provide the adversary with the ability to gain access to
the address space of the guest operating system.

##### Out of Scope.

Anything not mentioned here, e.g., side-channel attacks, are outside the scope
of our threat model.

Figure 3: Attestation workflow. Here we present a typical attestation
workflow. A container (key in circle) attempts to obtain and decrypt the
user’s data for use by other containers in the group. The key has been
previously provisioned into a key management service with a defined key
release policy. The container within the UVM requests that the PSP issues an
attestation report (1) including an RSA wrapping public key as a runtime
claim. The report and additional attestation evidence are provided to the
attestation service (2), which verifies that it the report is valid and then
provides an attestation token that represents platform, init, and runtime
claims. Finally, the attestation token is provided to the key management
service (3) which returns the customer’s key to the container wrapped using a
RSA public key as long as the token’s claims satisfy the key release policy
statement.

###  3.3 Security Guarantees

Under the threat model presented in Section 3.2, we wish to provide strong
confidentiality and integrity guarantees for the container and for customer
data. The provided security guarantees are based on the following principles:

Hardware-based Isolation of the UVM. The memory address space and disks of the
VM must be protected from the host and other VMs by hardware-level isolation.
Parma relies on the SEV-SNP hardware guarantee that the memory address space
of the UVM cannot be accessed by host system software.

Integrity-protected Filesystems. Any block device or blob storage is mounted
in the UVM as an integrity-protected file system. The file system driver
enforces integrity checking upon an access to the file system, ensuring that
the host system software cannot tamper with the data and container images. In
Parma, a container file system is expressed as an ordered sequence of layers,
where each layer is mounted as a separate device and then assembled into an
overlay filesystem [31]. First, Parma verifies as each layer is mounted that
the dm-verity root hash [18] for the device matches a layer that is enumerated
in the policy. Second, when the container shim requests the mounting of an
overlay filesystem that assembles multiple layer devices, Parma verifies that
the specific ordering of layers is explicitly laid out in the execution policy
for one or more containers.

Encrypted Filesystems. Any block device or blob storage that holds privacy-
sensitive data is mounted as an encrypted filesystem. The filesystem driver
decrypts the memory-mapped block upon an access to the filesystem. The
decrypted block is stored in hardware-isolated memory space, ensuring that
host system software cannot access the plaintext data. The writable scratch
space of the container is mounted with dm-crypt [16] and dm-integrity [17],
and this is enforced by the execution policy. The encryption key for the
writeable scratch space is ephemeral and is provisioned initially in hardware-
protected memory and erased once the device is mounted.

UVM Measurement. The UVM, its operating system and the guest agent are
crytographically measured during initialization by the TEE and this
measurement can be requested over a secure channel at any time by user
containers. The AMD SEV-SNP hardware performs the measurement and encodes it
in the signed attestation report as discussed in Section 2.2.6.

Verifiable Execution Policy. The user must be provided with a mechanism to
verify that the active execution policy (see below in (Section 3.4)) in a
container group is what they expect it to be. The execution policy is defined
and measured independently by the user and it is then provided to the CaaS
deployment system. The host measures the policy (e.g., using SHA-512) and
places this measurement in the immutable host data of the report as described
in Section 2.2.6. The policy itself is passed to the UVM by the container
shim, where it is measured again to ensure that its measurement matches the
one encoded as host data in the report.

Remote Attestation. Remote verifiers (i.e., tenants, external services,
attestation services) need to verify an attestation report so that they can
establish trust in a secure communication channel with the container group
running within the UVM. In particular, remote verifiers need to to verify that
the UVM has booted the expected operating system, the correct guest agent, and
further that the guest agent is configured with the expected execution policy.

In Parma, the UVM (including privileged containers) can request an attestation
report using the secure channel established between the PSP and the UVM, as
detailed in Section 2.2.6. The requester generates an emphemeral token (e.g.,
TLS public key pair or a sealing/wrapping public key) which is presented as a
runtime claim in the report; the token’s cryptographic digest is encoded as
report data in the report. A remote verifier can then verify that (i) the
report has been signed by a genuine AMD processor using a key rooted to AMD’s
root certificate authority, (ii) the guest launch measurement and host data
match the expected VM measurement and the digest of the expected execution
policy, (iii) the report data matches the hash digest of the runtime claim
presented as additional evidence.

Once the verification completes, the remote verifier that trusts the UVM
(including the guest OS, guest agent and the execution policy) trusts that the
UVM and the container group running with it will not reveal the private keys
from which the public tokens have been generated, e.g., TLS private key,
sealing/wrapping private key. The remote verifer can utilize the runtime claim
accordingly. For instance,

  * •

a TLS public key can be used for establishing a TLS connection with the
attested container group. As such, the remote verifier can trust there is no
replay or man-in-the-middle attack;

  * •

a sealing public key can be used to seal (via encryption) a request or
response intended only for the attested containers;

  * •

a wrapping public key can be used by a key management service to wrap and
release encryption keys required by the VM’s container group for decrypting
encrypted remote blob storage. As such, the remote verifier can trust that
only trustworthy and attested container groups can unwrap the encryption keys.
Figure 3 illustrates this process.

###  3.4 Execution Policy

As discussed in our threat model, the container shim is not trusted as it
could be under the control of an attacker. This implies that any action which
the container shim requests the guest agent undertake inside the UVM is
suspect (see Section 3.2 for a list of malicious host actions). Even if the
current state of the container group is valid, there is no guarantee that the
host will not compromise it in the future, and thus no way for the attestation
report to be used as a gate on access to secure customer data. The attestation
report on its own simply records the UVM OS, the guest agent, and the
container runtime versions in use. It is not able to make any claims about the
container group the host will subsequently orchestrate.

For example, the host can start the user container group in a manner which is
expected by an attestation service until such time as it acquires some desired
secure information, and then load a series of containers which open the
container group to a remote code execution attack. The attestation report,
obtained during initialization, cannot protect against this. Even updating it
via providing additional runtime data to the PSP (as described in Section
2.2.6) does not help, because the vulnerability is added by the host after the
attestation report has been consumed by the external service.

To address this vulnerability, we introduce the concept of an _execution
policy_. Authored by the customer, it describes what actions the guest agent
is allowed to take throughout the lifecycle of the container group. The guest
agent is altered to consult this policy before taking any of the actions in
Table 1, providing information to the policy that is used to make decisions.
These actions each have a corresponding _enforcement point_ in the execution
policy which will either allow or deny the action. In our implementation the
policy is defined using the Rego policy language [34]. A sample enforcement
point can be seen in Listing 1.

Action |  Policy Information
---|---
Mount a device |  device hash, target path
Unmount a device |  target path
Mount overlay |  ID, path list, target path
Unmount overlay |  target path
Create container |  ID, command, environment, working directory, mounts
Execute process (in container) |  ID, command, environment, working directory
Execute process (in UVM) |  command, environment, working directory
Shutdown container |  ID
Signal process |  ID, signal, command
Mount host device |  target path
Unmount host device |  target path
Mount scratch |  target path, encryption flag
Unmount scratch |  target path
Get properties |  —
Dump stacks |  —
Logging (in the UVM) |  —
Logging (containers) |  —
Table 1: Policy Actions. These are the actions we propose to be under the
control of the execution policy. The list is specific to our implementation,
but given standardization around containerd it should be applicable to most
scenarios. First we have actions which pertain to the creation of containers.
By ensuring that any device mounted by the guest has a dm-verity root hash
[18] that is listed in the policy, and that they are combined into overlay
filesystems [31] in layer orders that coincide with specific containers, we
first establish that the container file systems are correct. We can then start
the container, further ensuring that the environment variables and start
command comply with policy and that mounts from the UVM to the container are
as expected (along with other container specific properties). Other actions
proceed in a similar manner, constraining the control which the container shim
has over the guest agent.

⬇

1default mount_device := {"allowed": false}

2

3device_mounted(target) {

4 data.metadata.devices[target]

5}

6

7mount_device := {"metadata": [addDevice],

8 "allowed": true} {

9 not device_mounted(input.target)

10 some container in data.policy.containers

11 some layer in container.layers

12 input.deviceHash == layer

13 addDevice := {

14 "name": "devices",

15 "action": "add",

16 "key": input.target,

17 "value": input.deviceHash

18 }

19}

Listing 1: Sample enforcement point. Here, as in our implementation, the
policy is expressed in Rego [34].

A novel feature of our implementation is the ability for a policy to
manipulate its own metadata state (maintained by the guest agent). This
provides an attested mechanism for the execution policy to build a
representation of the state of the container group, allowing for more complex
interactions. For example, in the rule shown in Listing 1, the enforcement
point for mounting a device creates a metadata entry for the device which will
be used to prevent other devices from being mounted to the same target path.

The result of making this small change to the guest agent is that the state
space of the container group is bounded by a state machine, in which
transitions between states correspond to the actions described above. Each
transition is executed atomically and comes with an enforcement point.

##### Induction.

The state machine starts as a system that is fully measured and attested,
including the execution policy with all its enforcement points, with the root
of trust being the PSP hardware ($n=1$). All possible transitions are
described by the execution policy. Regardless of which ($n$) transitions have
been taken after that, each of the actions listed in Table 1 cannot break
integrity or confidentiality without deliberate modification of the respective
enforcement point, which would have had to happen before the initial
measurement ($n+1$). Any sequence of such transitions therefore maintains
integrity and confidentiality. Our enforcement points are carefully designed
to maintain these properties. Note that confidentiality is modulo acceptance
of the UVM and the execution policy. That is, the end-user must verify that
the attestation report they receive from Parma is bound to a UVM and an
execution policy that uses the end-user’s data in a manner they accept.

##  4 Evaluation

We used benchmarking tools to evaluate several typical containerized workloads
for reductions in computation throughput, network throughput, and database
transaction rates to ensure that Parma does not introduce significant
computational overhead. In all cases we demonstrate that Parma provides
confidentiality for containerized workloads with minimal costs to performance
(typically less than 1% additional overhead over running in an enclave).

Each benchmarking experiment is conducted using two machines: (1) a DELL
PowerEdge R7515 with an AMD EPYC 7543P 32-Core Processor and 128GB of memory
for hosting the container runtime and (2) a benchmarking client (to avoid
impact of any benchmarking software upon the evaluation) with the same
configuration connected to (1) on the same subnet via 10GBit Ethernet. (1) is
running Windows Server 2022 Datacenter (22H2) and an offline version of the
Azure Container Instances CPLAT (i.e., containerd, cri, and hcsshim). The UVM
runs a patched version of 5.15 Linux which includes AMD and Microsoft patches
to provide AMD SEV-SNP enlightenment. (2) is running Ubuntu 20.04 with Linux
kernel 5.15.

###  4.1 nginx

Web services are a common use case for containerization, and so we benchmark
the popular nginx webserver using the wrk2 [41] benchmarking tool. Each test
is run for 60 seconds on 10 threads, simulating 100 concurrent users making
200 requests per second (for a total of 12000 requests per test). We repeat
the tests 20 times for each of three configurations:

Base

A baseline nginx container running outside the SEV-SNP enclave,

SEV-SNP

The same container running within the SEV-SNP enclave,

Parma

The same container again within the enclave and with an attested execution
policy,

and measure the latency. The results are shown in Figure 4. The median curves
are computed over all experiments per configuration, and the histograms are
composed of all latency samples which were gathered. We observe an increase in
latency by the introduction of SEV-SNP, as expected, and also a very minor
increase in latency when adding the execution policy. However, it is worth
noting that these effects are only reliably observed in aggregate, i.e., all
median curves are within the first quartiles of each other.

Figure 4: nginx Results. Here we see results from our benchmarking of nginx.
The top plot shows the median latency curves (left and up is better). The
bottom plot shows the latency histograms. We gather latency samples from 20
experiments in which we simulate 100 clients making 200 requests a second, for
60 seconds. The overhead of running inside the enclave introduces a noticeable
increase in latency in SEV-SNP over Base. The addition in Parma of the
execution policy, however, results in a less than 1% increase in latency over
SEV-SNP.

###  4.2 redis

The in-memory key/value database redis provides another useful benchmark for
containerized compute. It supports a diverse set of data structures, such as
hashtables, sets, and lists. We perform our benchmarking using the provided
redis-benchmark with 25 parallel clients and a subset of tests, the results of
which can be seen in Table 2. Looking at the geometric mean over all actions,
we see a performance overhead of 18% added by operating within the AMD SEV-SNP
enclave, and a further 1% when using Parma. The performance overhead is
attributed to increased TLB pressure arising from large working sets which
exhibit poor temporal reuse in TLBs and trigger page table walks. In SEV-SNP-
enabled systems, table page table walks incur additional metadata checks (in
the Reverse Page Table) to ensure that the page is indeed owned by the VM.

Setup |  PING_INLINE |  PING_BULK |  SET |  GET |  INCR |  LPUSH
---|---|---|---|---|---|---
Base | 68±2.3 | 69±2.3 | 69±1.8 | 69±1.9 | 69±2.1 | 68±2.0
SNP | 57±3.2 | 58±4.7 | 57±3.1 | 57±4.2 | 57±3.7 | 55±4.4
Ours | 56±3.3 | 57±3.4 | 56±4.1 | 56±5.0 | 54±4.3 | 54±4.5

RPUSH |  LPOP |  RPOP |  SADD |  HSET |  SPOP |  GeoMean
---|---|---|---|---|---|---
69±2.3 | 69±2.3 | 68±2.1 | 69±1.7 | 67±1.4 | 69±2.1 |  68±1.0
56±4.1 | 54±4.2 | 55±4.2 | 58±3.5 | 54±4.3 | 57±3.9 |  56±1.1
54±3.8 | 52±3.9 | 54±4.3 | 56±4.0 | 56±4.5 | 58±4.4 |  55±1.1

Table 2: redis results.. In this table we show the comparative request rates
for different tests from the standard redis-benchmark tool broken out by Base
(container run without SEV-SNP), SNP (with SEV-SNP), and Parma (SEV-SNP +
execution policy). Values are in thousands of requests per second, higher is
better. While both SEV-SNP and Parma exhibit a decrease in performance over
Base as a result of the overheads introduced by running within the enclave,
there is little difference between them.

###  4.3 SPEC2017

We also evaluate Parma by measuring the computation performance overhead using
the SPEC2017 intspeed benchmarks [36]. The benchmark programs are compiled and
run on the bare metal hardware. When containerized, they are provided with 32
cores and 32 GB of memory. As can be seen in Table 3 AMD SEV-SNP adds a
performance overhead of 13% on average, and Parma adds less than 1% on top of
this. By looking at the individual benchmarks in Figure 5, SEV-SNP introduces
a wide range (1-38%) of performance overhead in SPECint benchmarks. The
overheads are down to (i) the increased TLB pressure (further exacerbated in
SEV-SNP setups as discussed in redis benchmark); 631.deepsjeng, the most
memory-intensive benchmark in SPECint introduces the second-highest overhead
and (ii) the additional overhead for accessing the encrypted scratch space;
620.omnetpp, the most IO-intensive benchmark (due to large test inputs)
introduces the highest overhead (38%).

Setup |  Base Ratio |  \- (Base)
---|---|---
Base | 8.43 | 0.0%
SNP | 7.33 | 13.1%
Ours | 7.30 | 13.4%
Table 3: SPEC2017 results. We run the SPEC2017 intspeed benchmarks in four
configurations: on the bare metal host (Bare), in a container (Base), in a
container in a hardware-isolated VM (SNP), and Ours (i.e., using Parma). The
reported values are the base ratio from reportable benchmark runs (see [36]
for details on the reportable flag). Higher is better. Figure 5: SPEC2017
results. This plot shows the per-benchmark runtimes (in seconds) for SPEC2017
broken out by Base (container run without SEV-SNP), SNP (with SEV-SNP), and
Parma (SEV-SNP + execution policy). Lower is better. 631.deepsjeng, the most
memory-intensive benchmark in SPECint introduces the second-highest overhead.
620.omnetpp, the most IO-intensive benchmark (due to large test inputs)
introduces the highest overhead. Discussions of these outliers can be found in
the text.

###  4.4 NVidia Triton Inference Server

Finally, we evaluate Parma by running a machine learning (ML) inference
workload based on NVidia’s Triton Inference Server [39]. Models (trained
offline) and their parameters are used by the server to serve requests via a
REST API.

The confidential ML inference server is deployed via a container group that
comprises two containers: an (unmodified) Triton inference container, and a
sidecar container that mounts an encrypted remote blob (holding the ML model)
using dm-crypt and dm-integrity. (The sidecar container also implements the
attestation workflow described in Figure 3 to release the encryption key.) The
filesystem (and the contained ML model) is made available to the Triton
inference container.

We evaluate the inference servers using NVidia’s perf-analyzer system,
allowing us to measure the overhead introduced by SEV-SNP and Parma, as shown
in Figure 6. For each of the three configurations (Base, SNP, and Parma) we
run four different experiments with 1 to 4 concurrent clients making
continuous inference requests. In Figure 6 we report the median throughput for
these experiments over 3 trials and observce a performance overhead of 26%
when running in the AMD SEV-SNP enclave. As before, the additional overhead
from Parma is 1%. The overheads share the same root cause in the increased TLB
pressure as was previous described in the redis benchmark.

Figure 6: NVidia Triton Results. This plot shows the inference rate for the
Base (container run without SEV-SNP), SNP (with SEV-SNP), and Parma (SEV-SNP +
execution policy) configurations. The median values gathered over three
experiments are shown for each number of concurrent clients.

##  5 Related Work

A number of TEE container runtimes have been proposed to enable running
applications or containers on Intel SGX [7, 10, 33, 35, 40]. A common feature
across these proposals is the use of a library OS running in-enclave. By
design, a library OS provides a subset of OS features, and so can only run
some containers without modification. In addition, the application’s network
interface, the interface between the library OS, and the actual out-of-enclave
OS are security boundaries. This has a performance impact, as the library OS
must provide a secure communication mechanism to the out-of-enclave OS and
validate all data that crosses the boundary. In contrast, Parma provides an
actual OS in-enclave, can run unmodified containers, and only the
application’s network interface is a security boundary. Additionally, Parma
provides the inductive proof of all future states via the attested execution
policy.

Hecate [21] uses AMD VM privilege levels (VMPLs) to run a nested hypervisor
and a guest OS within the same AMD SEV-SNP isolated VM. This allows an
unmodified guest OS to be run as a confidential VM, modulo kernel code
integrity. However, Hecate does not address attestation, file system integrity
and confidentiality, or execution policy. In addition, Hecate allows guest OS
administrators full access to the VM.

Brasser et al. have concurrently proposed TCX, a collection of trusted
container extensions for running containers securely within hardware-isolated
utility VMs on AMD SEV processors [12]. TCX relies (a) on a root VM (akin to
the SGX quoting enclave) for bootstrapping the utility VM, thus increasing the
TCB, and (b) on a secure channel established between the container owner and
the utility VM for preventing untrusted entities from submitting container
commands to the VM. The latter design choice does not support the CaaS
deployment model, wherein the container owner and cloud service provider
personas are different, thus requiring that the CSP submit container commands
to the utility VM. In addition, the container owner is in the TCB. The end-
user of the confidential container (e.g., a bank customer, a patient
submitting medical data to their doctor) has no attestation over what
container commands have been or will be run.

SEVGuard explores running user-mode applications on guest SEV-protected VMs
without a guest-side kernel component [32]. SEVGuard relies on an existing
kernel virtualization API for interaction with host kernel features and
provides support for calling shared libraries on the host. While SEVGuard
offers a low TCB, it is vulnerable to attacks on the kernel virtualization API
and shared libraries and does not provide secure persistent storage.

##  6 Future Work

While Parma provides a solid foundation for confidential containers, there are
some limitations to this technique which invite future investigation.

###  6.1 Trusted Computing Base

Parma reduces the TCB by removing the need to trust the host, the hypervisor,
and the CSP, but it could be smaller. In particular, by trusting the UVM we
necessarily import the UVM OS (e.g., Linux) into the TCB, as well as the
standard libraries needed to implement other elements like the guest agent.
However, much of that code is entirely vestigial in the context of providing a
container runtime. One potential line of inquiry would be to explore ways of
reducing this aspect of the UVM to the smallest possible kernel and the barest
necessities needed by the guest agent, runc and other tools to further reduce
the attack surface.

###  6.2 Policy Flexibility

One downside of having an execution policy which is measured during
initialization and then subsequently used for attestation-based security
operations is that the release policies will necessarily be tied to a fixed
version of the execution policy. If container images need to change, e.g., due
to necessary security updates upon discovery of a vulnerability, it requires
not only an update to the execution policy but also an update to all release
policies as well. In many scenarios this is a desirable property, but users
may want to choose to loosen how the policy defines which actions it allows. A
promising area of future research would be to find a manner in which to
provide this flexibility without sacrificing the post-verifiable inductive
proof over the state of the container group which Parma provides.

###  6.3 Writeable Filesystems Freshness

Parma relies on dm-integrity for block-level integrity of writeable
filesystems. While dm-integrity provides integrity protection based on
authentication tags, the latter are vulnerable to replay attacks and do not
provide any freshness guarantees. Freshness could be provided using update-
able integrity trees (e.g., Merkle Trees) but at a huge latency and bandwidth
overhead when a data block (i.e., leaf block in the tree) is updated due to a
chain of updates to all intermediate blocks lying with the root-leaf path. A
promising area of future research would be to explore security-performance
trade-offs for writeable filesystems with freshness guarantees.

##  7 Conclusion

In this paper we have introduced Parma, a novel method for providing
confidential computation for containerized workflows via the introduction of
an attested execution policy. Further, we have demonstrated that Parma adds
less than 1% additional performance overhead beyond that added by the
underlying TEE (i.e., AMD SEV-SNP). We also outline how the security
properties of the system provide an inductive proof over the future state of
the container group rooted in the attestation report. This provides the
ability (via remote attestation) for external third-parties to securely
communicate with containers, enabling a wide range of containerized workflows
which require confidential access to secure data.

## Availability

The open source implementation of Parma is available as part of the hcsshim
system (https://github.com/microsoft/hcsshim/tree/main/pkg/securitypolicy) and
is the technology which enables Confidential Azure Container Instances.

## Acknowledgements

Thanks to Istvan Haller for help with the SPEC2017 benchmark and helpful
conversations.

## References

  * [1] Azure Container Instances: Microsoft Azure.  https://azure.microsoft.com/en-gb/products/container-instances/.  Online; accessed 21 November 2022.
  * [2] Confidential containers on azure container instances.  https://learn.microsoft.com/en-us/azure/container-instances/container-instances-confidential-overview.  Online; accessed 7 March 2023.
  * [3] Docker on Amazon Web Services.  https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/.  Online; accessed 21 November 2022.
  * [4] AMD SEV-SNP: Strengthening vm isolation with integrity protection and more.  https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf, 2020\.
  * [5] The realm management extension (RME), for Armv9-A arm architecture reference manual supplement.  https://developer.arm.com/documentation/ddi0615/latest/.  Online; accessed 21 November 2022.
  * [6] ARM security technology building a secure system using TrustZone technology.  https://developer.arm.com/documentation/PRD29-GENC-009492/c?lang=en.  Online; accessed 21 November 2022.
  * [7] Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L. Stillwell, David Goltzsche, Dave Eyers, Rüdiger Kapitza, Peter Pietzuch, and Christof Fetzer.  SCONE: Secure linux containers with intel SGX.  In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), pages 689–703, Savannah, GA, November 2016. USENIX Association.
  * [8] Raad Bahmani, Ferdinand Brasser, Ghada Dessouky, Patrick Jauernig, Matthias Klimmek, Ahmad-Reza Sadeghi, and Emmanuel Stapf.  CURE: A security architecture with customizable and resilient enclaves.  CoRR, abs/2010.15866, 2020.
  * [9] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield.  Xen and the art of virtualization.  In Symposium on Operating Systems Principles (SOSP ’03), October 2003.
  * [10] Andrew Baumann, Marcus Peinado, and Galen Hunt.  Shielding applications from an untrusted cloud with Haven.  In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), October 2014.
  * [11] Ferdinand Brasser, David Gens, Patrick Jauernig, Ahmad-Reza Sadeghi, and Emmanuel Stapf.  SANCTUARY: ARMing TrustZone with user-space enclaves.  In Proc. of Network and Distributed System Security Symposium, 01 2019.
  * [12] Ferdinand Brasser, Patrick Jauernig, Frederik Pustelnik, Ahmad-Reza Sadeghi, and Emmanuel Stapf.  Trusted container extensions for container-based confidential computing.  In arXiv, May 2022.
  * [13] David Champagne and Ruby B. Lee.  Scalable architectural support for trusted software.  In HPCA - 16 2010 The Sixteenth International Symposium on High-Performance Computer Architecture, pages 1–12, 2010.
  * [14] containerd.  https://containerd.io/.  Online; accessed 21 November 2022.
  * [15] Victor Costan, Ilia Lebedev, and Srinivas Devadas.  Sanctum: Minimal hardware extensions for strong software isolation.  In 25th USENIX Security Symposium (USENIX Security 16), pages 857–874, Austin, TX, August 2016. USENIX Association.
  * [16] dm-crypt.  https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html.  Online; accessed 8 December 2022.
  * [17] dm-integrity.  https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html.  Online; accessed 8 December 2022.
  * [18] dm-verity.  https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html.  Online; accessed 30 November 2022.
  * [19] Docker.  https://www.docker.com/.  Online; accessed 21 November 2022.
  * [20] Dmitry Evtyushkin, Jesse Elwell, Meltem Ozsoy, Dmitry Ponomarev, Nael Abu Ghazaleh, and Ryan Riley.  Iso-X: a flexible architecture for hardware-managed isolated execution.  In 2014 47th Annual IEEE/ACM International Symposium on Microarchitecture, pages 190–202, 2014.
  * [21] Xinyang Ge, Hsuan-Chi Kuo, and Weidong Cui.  Hecate: Lifting and shifting on-premises workloads to an untrusted cloud.  In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 1231–1242, 2022.
  * [22] Google Cloud Run.  https://cloud.google.com/run.  Online; accessed 21 November 2022.
  * [23] Intel software guard extensions.  https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/overview.html.  Online; accessed 21 November 2022.
  * [24] Intel trust domain extensions.  https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html.  Online; accessed 21 November 2022.
  * [25] Kubernetes.  https://kubernetes.io/.  Online; accessed 21 November 2022.
  * [26] David Kaplin, Jeremy Powell, and Tom Woller.  AMD memory encryption.  https://amd.wpenginepowered.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v9-Public.pdf, 2021\.
  * [27] Dayeol Lee, David Kohlbrenner, Shweta Shinde, Krste Asanović, and Dawn Song.  Keystone: An open framework for architecting trusted execution environments.  In Proceedings of the Fifteenth European Conference on Computer Systems, EuroSys ’20, New York, NY, USA, 2020. Association for Computing Machinery.
  * [28] Xupeng Li, Xuheng Li, Christoffer Dall, Ronghui Gu, Jason Nieh, Yousuf Sait, and Gareth Stockwell.  Design and verification of the Arm Confidential Compute Architecture.  In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), 2021.
  * [29] Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Michael K. Reiter, and Hiroshi Isozaki.  Flicker: An execution infrastructure for tcb minimization.  In Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, Eurosys ’08, page 315–328, New York, NY, USA, 2008\. Association for Computing Machinery.
  * [30] OCI Technical Oversight Board.  Open container initiative distribution specification.  Standard v1.0.1, Open Container Initiative, 2021.
  * [31] Overlay filesystem.  https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html.  Online; accessed 30 November 2022.
  * [32] Ralph Palutke, Andreas Neubaum, and Johanne Gotzfried.  SEVGuard: Protecting user mode applications using Secure Encrypted Virtualization.  In International Conference on Security and Privacy in Communication Systems, December 2019.
  * [33] Christian Priebe, Divya Muthukumaran, Joshua Lind, Huanzhou Zhu, Shujie Cui, Vasily A. Sartakov, and Peter Pietzuch.  SGX-LKL: Securing the Host OS Interface for Trusted Execution.  In arXiv, January 2020.
  * [34] Policy language.  https://www.openpolicyagent.org/docs/latest/policy-language/.  Online; accessed 30 November 2022.
  * [35] Shweta Shinde, Dat Le Tien, Shruti Tople, and Prateek Saxena.  Panoply: Low-TCB Linux applications with SGX enclaves.  In Network and Distributed System Security Symposium (NDSS), March 2017.
  * [36] SPEC2017.  https://www.spec.org/cpu2017/.  Online; accessed 11 December 2022.
  * [37] G. Edward Suh, Dwaine Clarke, Blaise Gassend, Marten van Dijk, and Srinivas Devadas.  AEGIS: architecture for tamper-evident and tamper-resistant processing.  In ACM International Conference on Supercomputing 25th Anniversary Volume, page 357–368, New York, NY, USA, 2003. Association for Computing Machinery.
  * [38] He Sun, Kun Sun, Yuewu Wang, Jiwu Jing, and Haining Wang.  TrustICE: hardware-assisted isolated computing environments on mobile devices.  In 2015 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, pages 367–378, 2015.
  * [39] NVidia Triton Inference Server.  https://developer.nvidia.com/nvidia-triton-inference-server.  Online; accessed 11 December 2022.
  * [40] Chia-Che Tsai, Donald E. Porter, and Mona Vij.  Graphene-SGX: A practical library OS for unmodified applications on SGX.  In 2017 USENIX Annual Technical Conference (ATC), June 2017.
  * [41] wrk2.  https://github.com/giltene/wrk2.  Git tag 44a94c17d8e6a0bac8559b53da76848e430cb7a7.