From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: "Jörg Rödel" <joro@8bytes.org>,
"svsm-devel@coconut-svsm.dev" <svsm-devel@coconut-svsm.dev>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>
Subject: RE: [svsm-devel] Development Plan Document
Date: Wed, 15 May 2024 10:20:15 +0000 [thread overview]
Message-ID: <DM8PR11MB57503B95AFE00B2BC99B3F88E7EC2@DM8PR11MB5750.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ZkMpkfepqUWfq1RY@8bytes.org>
> On Fri, May 10, 2024 at 12:17:26PM +0200, Jörg Rödel wrote:
> > The document is on GitHub in Markdown and PDF format:
> >
> > https://github.com/joergroedel/svsm-governance/blob/dev-plan/draft-
> development-plan.md
> >
> > https://github.com/joergroedel/svsm-governance/blob/dev-plan/draft-
> development-plan.pdf
>
> FYI, I just updated the documents with a new added section about
> proposed core code work items. There are three new items there and I
> moved two over from the Sec section.
Hi,
Thank you, this is a great document to have!
Some questions/comments:
1. I was surprised to see a Service VM mode (page 4), because I haven’t
realized this is being considered for Coconut-svsm. Is there more information
on the use cases behind this? I can image these usecases myself, but would
be great to know the ones you are targeting.
2. Section 9. Cryptography support. The requirement on the isolation
is somewhat confusing. It reads like the keys or cryptographic assets would
never leave the border of the cryptographic module (even in the
encrypted form?), which I am not sure the requirement applicable for all
usecases. I think it would be better for the start to define the *purpose*
of the cryptographic layer in coconut-svsm: is it just a set of securely implemented
algorithms to be exposed for user-space or/and kernel processes to perform needed
cryptographic functions (like we have crypto API in Linux) or a real cryptographic
service is envisioned that would be managing the keys and exposing
crypto services based on these keys? If latter, such service scope needs to be
defined/specified.
3. "Implement or port a cryptography library to Coconut-SVSM... ".
This is going to be tricky to get right, especially given the future aim for FIPS
certification. Implementing crypto functions from scratch correctly
is pretty difficult, so typically we tend to rely on existing libraries that have
been verified to provide adequate implementation. I would suggest here to
build a list of crypto algorithms that is envisioned to be needed (smaller list
is better and preferably taking post-quantum requirements in account) and based
on this (and other requirements) make a selection. Even well-known rust
libraries like ring last time we checked didn’t do things like proper key zerozation, etc.
Also, any crypto solution would need a secure cryptographic RNG which is
going to be a separate problem of its own unless everyone agrees that we can
directly use x86 platform provided RNGs or use their input to seed a
cryptographic CPRNG (Linux uses ChaCha but with FIPS certification in mind
the methods defined in NIST SP 800-90A/B/C should be considered instead).
4. Section 12.1. User-mode security FW. I guess the aim here is to create
a Mandatory Access Control FW, right (based on the comment about SELinux)?
This seems to go together with section 10.4 for filesystem permission model
unless there an additional Discretionary Access control is envisioned for that.
5. Section 12.2: by double-validation you mean the case when a private page
is added twice to the CVM (reaccept in TDX terms)?
6. section 8.1. Syscall interface. For TDX we had to be very careful
on things like syscall entry and other critical places in Linux to make sure
we cannot get a #VE event (probably the same for #VC for AMD?) in the
middle of switching between the userspace and kernel state. TDX provides some
controls to enable to protect from unwanted #VE which probably will be
useful for coconut-svsm also as a security measure.
7. Section 8.2. The instruction decoder needs to be explicitly stress-tested/
fuzzed. We are starting to look into this problem for Linux now since we
might need to allow userspace MMIO decoding in the TDX code, so maybe
we can reuse some of that work for this one here.
8. One item I would add is that it would be good to document and check
that all relevant (non-dynamic and with potential security implication) inputs
from the host/VMM are measured by the Coconut-SVSM correctly
into platform specific attestation registers. This closely relates to 10.1, but
it is not about the higher level attestation service but about how coconut-svsm
measures itself and its own assets. Ideally this should work with both vTPM
service available and without.
9. I remember in past we discussed about ACPI tables passthrough via coconut
-SVSM and generation in the Coconut-svsm. Should this also be listed for debate
purpose as it has its own benefits and challenges?
Best Regards,
Elena.
next prev parent reply other threads:[~2024-05-15 10:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 10:17 Development Plan Document Jörg Rödel
2024-05-14 9:06 ` [svsm-devel] " Jörg Rödel
2024-05-15 10:20 ` Reshetova, Elena [this message]
2024-05-15 11:59 ` Carlos López
2024-05-15 12:04 ` Reshetova, Elena
2024-05-15 12:14 ` Jörg Rödel
2024-05-17 10:01 ` Reshetova, Elena
2024-05-23 9:52 ` Jörg Rödel
2024-05-16 7:49 ` Jörg Rödel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM8PR11MB57503B95AFE00B2BC99B3F88E7EC2@DM8PR11MB5750.namprd11.prod.outlook.com \
--to=elena.reshetova@intel.com \
--cc=joro@8bytes.org \
--cc=linux-coco@lists.linux.dev \
--cc=svsm-devel@coconut-svsm.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).