From: Michael Raskin <7c6f434c@mail.ru>
To: hi@alyssa.is, discuss@spectrum-os.org, devel@spectrum-os.org
Cc: edef@edef.eu, philipp@xndr.de
Subject: This (and Last) Week in Spectrum, 2020-W34 & 2020-W35
Date: Wed, 26 Aug 2020 15:31:38 +0200 [thread overview]
Message-ID: <E1kAvOt-0007no-1V.7c6f434c-mail-ru@smtp58.i.mail.ru> (raw)
In-Reply-To: <87zh6jk8gr.fsf@alyssa.is>
>to handle 9P over vsock, but I haven't tested yet. We can use existing
>virtiofsd and 9P software (there are promising Rust implementations of
>each), and harden them against potential vulnerabilites like directory
>traversals using kernel features like RESOLVE_BENEATH and
>RESOLVE_NO_XDEV. For the boot device, maybe there's no reason not to
Also, if the server is in a namespace seeing only a bind mount to the
necessary part of the FS, in a VM that only sees that one FS, the cheap
attacks just become moot. You can probably talk it into traversal, but
it doesn't see more than allowed anyway; talking it into attacking the
VM kernel is hopefully harder (and still has limited impact)
>just mount it using the host kernel, or maybe there's something to be
>gained by just reading a small bootstrap payload into memory from the
>start of the disk once, and then making all future communication go via
>a VM. I'm not really sure yet. But the important thing is we'll have
>mechanisms for all this in place. Maybe we'll decide that non-boot
>devices should just go over inter-VM 9P, but in any case, we'll still
>need all these pieces.
Can virtiofs eventually be backed by a VM-wrapped vhost-user?
Although we probably do want host-side page cache, as VM's requests to
host are way more transparent for the scheduler than inter-VM requests.
>computers I've tried it on so far. I suspect that I will get GPU
>isolation working, but I'm not sure how reliable or performant it will
>be.
Hmm. Also a good question what is the timeslice for inter-VM
communication. Does it make sense to have two VMs alternate for slices
of ten milliseconds? This is just what is probably needed to have 25fps
video playback???
>I'm pushing quite hard to make it over the line with my hardware
>isolation funding milestone. I'm so close, and I'm about to need the
>money. But once I've hit that, I think I'm going to need a break. This
>stuff is gruelling.
I wish you strength for this push!
prev parent reply other threads:[~2020-08-26 13:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 22:03 Alyssa Ross
2020-08-26 13:31 ` Michael Raskin [this message]
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=E1kAvOt-0007no-1V.7c6f434c-mail-ru@smtp58.i.mail.ru \
--to=7c6f434c@mail.ru \
--cc=devel@spectrum-os.org \
--cc=discuss@spectrum-os.org \
--cc=edef@edef.eu \
--cc=hi@alyssa.is \
--cc=philipp@xndr.de \
/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.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
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 NNTP newsgroup(s).