vmm: migration: add seccomp rules for migration threads - #8453
Conversation
d2ea93f to
e43a9b0
Compare
likebreath
left a comment
There was a problem hiding this comment.
This fills an important gap we have. Thank you.
I'm curious how you arrived at this list of syscalls, was it by running the integration tests with --seccomp log? If so, did you also manually exercise the TLS path (both with and without multiple connections), as that's not covered by the integration tests ?
Yes
Not yet. Will do tomorrow. Thanks! |
|
I just tested this with TLS! It works. @sboeuf @likebreath By the way: I think we can easily extend the integration test suite to use TLS - either via generating certs on the fly or by using pre-generated long-living certs (will do this in a follow-up potentially). In the meantime, if you want to generate the certs for development purposes: # CA key + self-signed CA cert
certtool --generate-privkey --outfile ca-key.pem
cat > ca.tmpl <<'EOF'
cn = "Test CA"
ca
cert_signing_key
expiration_days = 3650
EOF
certtool --generate-self-signed \
--load-privkey ca-key.pem \
--template ca.tmpl \
--outfile ca-cert.pem
# Server key + certificate signed by CA
certtool --generate-privkey --outfile server-key.pem
cat > server.tmpl <<'EOF'
cn = "localhost"
dns_name = "localhost"
ip_address = "127.0.0.1"
tls_www_server
encryption_key
signing_key
expiration_days = 3650
EOF
certtool --generate-certificate \
--load-privkey server-key.pem \
--load-ca-certificate ca-cert.pem \
--load-ca-privkey ca-key.pem \
--template server.tmpl \
--outfile server-cert.pem
# Client key + certificate signed by CA
certtool --generate-privkey --outfile client-key.pem
cat > client.tmpl <<'EOF'
cn = "test-client"
tls_www_client
encryption_key
signing_key
expiration_days = 3650
EOF
certtool --generate-certificate \
--load-privkey client-key.pem \
--load-ca-certificate ca-cert.pem \
--load-ca-privkey ca-key.pem \
--template client.tmpl \
--outfile client-cert.pemand then set |
e43a9b0 to
9b9dd47
Compare
|
@phip1611 Great. Thank you. You will need a rebase. |
9b9dd47 to
14b66df
Compare
|
Since your review, some things changed because of the work @sboeuf did in |
72344a5 to
983a4d1
Compare
983a4d1 to
8c2c002
Compare
|
Apparently the musl build and arm64 worker are not happy, which makes sense as they likely use different syscalls. @phip1611 I reached out over slack in case you need the ARM CI worker to fix it. |
bd773f1 to
2df3f28
Compare
So far, we only have seccomp rules for the postcopy-send thread. This commit introduces the basic plumbing to add seccomp rules also for the migration worker (the migration coordinator) as well as the TCP workers (both, send and receive) in the following. To streamline code setup, all filters are created at a central place early in the migration code. Although this means that some filters are created without the need to do so (e.g., postcopy), this massively simplifies code setup and error handling. This overhead is negligible. On-behalf-of: SAP [email protected] Signed-off-by: Philipp Schuster <[email protected]>
2df3f28 to
9ec7c80
Compare
On-behalf-of: SAP [email protected] Signed-off-by: Philipp Schuster <[email protected]>
On-behalf-of: SAP [email protected] Signed-off-by: Philipp Schuster <[email protected]>
9ec7c80 to
7558811
Compare
|
I think I fixed the ARM problem! It was missing |
Add missing seccomp rules for migration threads.
As always with seccomp: I am unsure if 100% of possible syscalls (from all possible code paths) are covered. We'll see.
Split-out from #8021