- Spectrum Development - spectrum-os.org

[PATCH nixpkgs] spectrumPackages.rootfs: fix custom path entries
by Alyssa Ross 16 Mar '21

16 Mar '21

Stage 1 was supposed to be able to take a list of PATH entries to prepend to the default PATH, but it didn't do anything with them. Now, it properly adds them to the PATH as early as possible during boot. This mechanism isn't currently used anywhere, but is very useful for debugging. --- pkgs/os-specific/linux/spectrum/rootfs/generic.nix | 3 ++- pkgs/os-specific/linux/spectrum/rootfs/stage1.nix | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/pkgs/os-specific/linux/spectrum/rootfs/generic.nix b/pkgs/os-specific/linux/spectrum/rootfs/generic.nix index 0a99f99bd5b..81fb80a614f 100644 --- a/pkgs/os-specific/linux/spectrum/rootfs/generic.nix +++ b/pkgs/os-specific/linux/spectrum/rootfs/generic.nix @@ -8,7 +8,8 @@ let makeStage1 = import ./stage1.nix { inherit writeScript lib - execline s6 s6-portable-utils s6-linux-utils s6-linux-init busybox mesa; + execline s6 s6-portable-utils s6-linux-utils s6-linux-init busybox mesa + path; }; makeServicesDir = import ./services.nix { diff --git a/pkgs/os-specific/linux/spectrum/rootfs/stage1.nix b/pkgs/os-specific/linux/spectrum/rootfs/stage1.nix index be7853316e9..6caf9ff93b8 100644 --- a/pkgs/os-specific/linux/spectrum/rootfs/stage1.nix +++ b/pkgs/os-specific/linux/spectrum/rootfs/stage1.nix @@ -1,16 +1,19 @@ { writeScript, lib , execline, s6, s6-portable-utils, s6-linux-utils, s6-linux-init, busybox, mesa +, path ? [] }: { run ? "true" }: let - path = [ s6 s6-portable-utils s6-linux-utils s6-linux-init busybox execline ]; + path' = path ++ [ + s6 s6-portable-utils s6-linux-utils s6-linux-init busybox execline + ]; in writeScript "init-stage1" '' #! ${execline}/bin/execlineb -P - export PATH ${lib.makeBinPath path} + export PATH ${lib.makeBinPath path'} ${s6}/bin/s6-setsid -qb -- importas -i spectrumcmd spectrumcmd -- 2.30.0

2 2

[PATCH nixpkgs] spectrumPackages.spectrum-vm: fix without Wayland
by Alyssa Ross 15 Mar '21

15 Mar '21

This errored because of the undefined XDG_RUNTIME_DIR or WAYLAND_DISPLAY. I'd tried to prevent that by disabling -e around this part, but it turns out I should have disabled -u instead. --- pkgs/os-specific/linux/spectrum/spectrum-vm/spectrum-vm.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pkgs/os-specific/linux/spectrum/spectrum-vm/spectrum-vm.in b/pkgs/os-specific/linux/spectrum/spectrum-vm/spectrum-vm.in index 4fa0287a805..8d95c178689 100755 --- a/pkgs/os-specific/linux/spectrum/spectrum-vm/spectrum-vm.in +++ b/pkgs/os-specific/linux/spectrum/spectrum-vm/spectrum-vm.in @@ -55,7 +55,7 @@ do esac done -set +e +set +u if [ -n "$XDG_RUNTIME_DIR" ] then set -- -s "$XDG_RUNTIME_DIR" "$@" @@ -63,7 +63,7 @@ then then set -- --wayland-sock "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" "$@" fi fi -set -e +set -u exec "$crosvm" run \ -p init=/sbin/init \ -- 2.30.0

1 1

[PATCH linux] usbip: tools: usbipd: add s6 readiness notification
by Alyssa Ross 15 Mar '21

15 Mar '21

This implements the s6 readiness notification protocol[1]. When the daemon has started and is listening on its socket(s), it will emit a readiness notification on a user-specified file descriptor. systemd-based systems can also use the readiness notification, using the sdnotify-wrapper program[2]. [1]: https://skarnet.org/software/s6/s6-supervise.html [2]: https://skarnet.org/software/misc/sdnotify-wrapper.c Signed-off-by: Alyssa Ross <hi(a)alyssa.is> --- This is important for us in Spectrum to be able to run usbipd to export USB devices to other VMs. I plan to add this patch to linuxPackages.usbip in Spectrum nixpkgs. I might attempt to upstream it to Linux, but I'm not sure yet -- the s6 protocol is perfect for our needs but fairly obsure, so I'm not sure if they'd like it. tools/usb/usbip/src/usbipd.c | 70 ++++++++++++++++++++++++++++-------- 1 file changed, 55 insertions(+), 15 deletions(-) diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c index 48398a78e88af..4ee41040735f4 100644 --- a/tools/usb/usbip/src/usbipd.c +++ b/tools/usb/usbip/src/usbipd.c @@ -22,6 +22,7 @@ #include <arpa/inet.h> #include <sys/socket.h> #include <netinet/in.h> +#include <fcntl.h> #ifdef HAVE_LIBWRAP #include <tcpd.h> @@ -65,6 +66,10 @@ static const char usbipd_help_string[] = " -D, --daemon\n" " Run as a daemon process.\n" "\n" + " -nFD, --notify-fd FD\n" + " Once ready to receive connections, write a line feed\n" + " character to FD, then close it.\n" + "\n" " -d, --debug\n" " Print debugging information.\n" "\n" @@ -88,6 +93,30 @@ static void usbipd_help(void) printf("%s\n", usbipd_help_string); } +static int parse_notify_fd(char *arg) +{ + dbg("parsing notify-fd arg '%s'", arg); + char *end; + unsigned long int notify_fd = strtoul(arg, &end, 10); + + if (end == arg) { + err("notify-fd: could not parse '%s' as decimal integer", arg); + return -1; + } + + if (*end != '\0') { + err("notify-fd: garbage at end of '%s'", arg); + return -1; + } + + if (fcntl(notify_fd, F_GETFD) == -1) { + err("notify-fd: %s", strerror(errno)); + return -1; + } + + return notify_fd; +} + static int recv_request_import(int sockfd) { struct op_import_request req; @@ -488,7 +517,7 @@ static void remove_pid_file(void) } } -static int do_standalone_mode(int daemonize, int ipv4, int ipv6) +static int do_standalone_mode(int daemonize, int notify_fd, int ipv4, int ipv6) { struct addrinfo *ai_head; int sockfdlist[MAXSOCKFD]; @@ -543,6 +572,13 @@ static int do_standalone_mode(int daemonize, int ipv4, int ipv6) dbg("listening on %d address%s", nsockfd, (nsockfd == 1) ? "" : "es"); + if (notify_fd != -1) { + const char lf[] = { '\n' }; + if (write(notify_fd, lf, sizeof lf) == -1) + err("failed to notify readiness"); + close(notify_fd); + } + fds = calloc(nsockfd, sizeof(struct pollfd)); for (i = 0; i < nsockfd; i++) { fds[i].fd = sockfdlist[i]; @@ -586,17 +622,18 @@ static int do_standalone_mode(int daemonize, int ipv4, int ipv6) int main(int argc, char *argv[]) { static const struct option longopts[] = { - { "ipv4", no_argument, NULL, '4' }, - { "ipv6", no_argument, NULL, '6' }, - { "daemon", no_argument, NULL, 'D' }, - { "daemon", no_argument, NULL, 'D' }, - { "debug", no_argument, NULL, 'd' }, - { "device", no_argument, NULL, 'e' }, - { "pid", optional_argument, NULL, 'P' }, - { "tcp-port", required_argument, NULL, 't' }, - { "help", no_argument, NULL, 'h' }, - { "version", no_argument, NULL, 'v' }, - { NULL, 0, NULL, 0 } + { "ipv4", no_argument, NULL, '4' }, + { "ipv6", no_argument, NULL, '6' }, + { "daemon", no_argument, NULL, 'D' }, + { "daemon", no_argument, NULL, 'D' }, + { "notify-fd", required_argument, NULL, 'n' }, + { "debug", no_argument, NULL, 'd' }, + { "device", no_argument, NULL, 'e' }, + { "pid", optional_argument, NULL, 'P' }, + { "tcp-port", required_argument, NULL, 't' }, + { "help", no_argument, NULL, 'h' }, + { "version", no_argument, NULL, 'v' }, + { NULL, 0, NULL, 0 } }; enum { @@ -605,7 +642,7 @@ int main(int argc, char *argv[]) cmd_version } cmd; - int daemonize = 0; + int daemonize = 0, notify_fd = -1; int ipv4 = 0, ipv6 = 0; int opt, rc = -1; @@ -620,7 +657,7 @@ int main(int argc, char *argv[]) cmd = cmd_standalone_mode; driver = &host_driver; for (;;) { - opt = getopt_long(argc, argv, "46DdeP::t:hv", longopts, NULL); + opt = getopt_long(argc, argv, "46Dn:deP::t:hv", longopts, NULL); if (opt == -1) break; @@ -635,6 +672,9 @@ int main(int argc, char *argv[]) case 'D': daemonize = 1; break; + case 'n': + notify_fd = parse_notify_fd(optarg); + break; case 'd': usbip_use_debug = 1; break; @@ -665,7 +705,7 @@ int main(int argc, char *argv[]) switch (cmd) { case cmd_standalone_mode: - rc = do_standalone_mode(daemonize, ipv4, ipv6); + rc = do_standalone_mode(daemonize, notify_fd, ipv4, ipv6); remove_pid_file(); break; case cmd_version: -- 2.27.0

1 0

This Week in Spectrum, 2021-W10
by Alyssa Ross 14 Mar '21

14 Mar '21

Surprise! I sent the last This Week in Spectrum in August. Since then, it's been pretty quiet. What happened? Towards then end of last year, I was aggressively pushing to achieve a funding milestone, but was starting to struggle to keep myself going. After that last TWiS, I decided to stop posting them for a while to fully concentrate on the push. I continued like that for two more months, before getting to the point where I was so burned out I just couldn't keep going, with the milestone still not done, the work I had done so far on it unpublished (and not in a good state to be published), and time running out. Fortunately, I was able to talk to NLnet, and they agreed to extend my funding deadlines and renegotiate the milestones. With that sorted out, in late November I began a hiatus from Spectrum to allow myself to recover from the burnout. I'm very grateful to my GitHub Sponsors, thanks to whom I was able to take this time to recover. I tried to come back at the end of January, but after a single day of Spectrum work I was feeling much the same as I had been in November. This week, though, something changed! I've been working on Spectrum again for the last week, and I've been feeling great about it! Now, there were three months of work between the last TWiS in August, and the start of my hiatus. That's a lot of work I haven't written about. But I think the only way this is really going to work is if I leave that largely unwritten about for now, because TWiS tends to be thousands of words long even when it's covering a single week of work. So I'm just going to talk about what I've done in the last week, explaining context from previous work as necessary. With all that in mind, here we go! "Qubes-lite with KVM and Wayland"[1] ------------------------------------ First up is something somebody else did, which is always nice! Thomas has been doing his own great work replacing his Qubes system with a system built on NixOS, using KVM and Wayland. Thomas got in touch on the Spectrum discuss mailing list in January[2] asking some questions about how some things were implemented, and we went back and forth a bit then (although not as much as I'd have liked, due to my burnout :/). Since then, he's come up with some awesome stuff, like an OCaml implementation of a virtio-wayland proxy (equivalent to Sommelier in Chromium OS). In our further conversation prompted by Thomas's article, Thomas raised a further interesting idea[3] -- what if we had a Sommelier-like Wayland proxy, but that ran in the same security domain as the compositor. That way, we could filter to allow only the protocol extensions we want to. We could implement our own permissions when the compositor doesn't. This code would be responsible for securely handling Wayland messages from an untrusted guest, which would be beneficial because it would be a lot less code to audit, and because it could be written in a memory-safe language. This would avoid the need to write or find a secure Wayland compositor, and would in fact allow us to use virtually any compositor without having to worry nearly as much about its security credentials. I'm very excited by that idea, and I've been asking myself for the past few days why I didn't think of it before! I've thought several times "it's quite nice that Sommelier gives us a known subset of Wayland, but it's a shame we can't rely on it since it runs inside a application guest". But for some reason it just never occurred to me to follow that idea one step further, to "what if we had a similar program that run in the compositor's security domain". [1]: https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland/ [2]: https://spectrum-os.org/lists/archives/spectrum-discuss/CAG4opy_hz_ESEpY0Tq… [3]: https://spectrum-os.org/lists/archives/spectrum-discuss/CAG4opy_JztAH3tD+ZU… uscpi-vsock ----------- ucspi-vsock[4] is a program I started writing in September. VSOCK[5] is a special Linux socket type that allows for communication between VMs, and I'm using it to allow services running in VMs (a USBIP daemon, for example), to notify the host (and by extension other VMs), when the service in the VM becomes ready to accept connections. USCPI[6] is a standard command interface for making it easy to do socket communication using standard IO primitives, without having to teach programs how to do socket connections for every kind of socket. There are several UCSPI implementations for common socket types like Internet and Unix domain sockets, but until now there was not one for VSOCK. So, for example, in a VM we can do: vsockclient 2 $port sh -c 'echo >&7' Which will connect to the host over VSOCK (in VSOCK the host is always address 2), write a newline, and close the connection. UCSPI lets us implement this with standard shell tools. There's an equivalent "vsockserver" program for the other end, that will run a command whenever a connection is received. Anyway, this week I went back to ucspi-vsock to fix some bugs[7][8][9][10]. As usual, (although I'm happy to realise this is still the case after all these months!) Cole was kind enough to review my patches. [4]: https://spectrum-os.org/git/ucspi-vsock/ [5]: https://man7.org/linux/man-pages/man7/vsock.7.html [6]: https://cr.yp.to/proto/ucspi.txt [7]: https://spectrum-os.org/lists/archives/spectrum-devel/20210309154048.14474-… [8]: https://spectrum-os.org/lists/archives/spectrum-devel/20210309171816.8589-1… [9]: https://spectrum-os.org/lists/archives/spectrum-devel/20210310204516.20041-… [10]: https://spectrum-os.org/lists/archives/spectrum-devel/20210310204555.20725-… Interguest networking --------------------- The bulk of my work this week has been in Spectrum's Nixpkgs, which is where (for now, at least) all the VM definitions and stuff live. Mostly, I've been trying to clean up months of frantic work into something I can actually publish as a series of patches, so it's out there instead of just on my computer! My focus at the moment is on doing this with the interguest networking implementation I wrote last year. The plan for this remains the same as last year: have a VM that manages all network hardware access and acts as a router for other VMs that need to talk to the outside world. Eventually, this will hopefully use virtio-vhost-user[11], which will allow us to avoid going through a networking stack on the host at all (or even having one), but until virtio-vhost-user is further along, we'll use bridge devices on the host to connect client VMs to the router. A very basic version of the latter is implemented and working for me locally -- I can run an application VM, and have it connect to another VM which runs the drivers for my ethernet port using VFIO (PCI passthrough). This code was a big ball of mud, and I'd also subtly broken it when I moved on from interguest networking last year to try to get a proof of concept going for another form of interguest communication. So I spent this week trying to page all the context I'd lost in the last few months back into my brain, making lots of partial git commits, writing commit messages, and fixing it up so that it works again. I think what I have is about ready to publish -- hopefully you'll see some patches next week. But what exists at the moment is still very limited -- the biggest limitation is that the router VM doesn't support hotplugging, so a VM that wants to connect to it actually has to be started first, before the router VM. Not good for something that should be run as a system service and likely started on boot! To overcome this limitation, I'll probably have to add support in crosvm for adding network devices at runtime using the control socket. I think this should be easy enough, and I haven't looked at what's happened in crosvm + rust-vmm since I've been away, so it's even possible somebody else will have done this already. [11]: https://wiki.qemu.org/Features/VirtioVhostUser So, the todo list for next week is getting the initial interguest networking PoC patchset posted. That'll come with a nice little demo other people will be able to try out if they want to. And then, I'll work on improving it further to the point where it's actually practical. I don't want to spend /too/ much time on this, since ultimately I do want to be using a virtio-vhost-user stack, which is quite different, but it's important to have an implementation of this so there's something to test further development (that doesn't care about the implementation details) against. My biggest worry at the moment is burning out again. Working in moderation isn't easy for me (I tend to get very sucked into things), but it's important for the project that I find a way to keep my work sustainable, so we don't lose time like this again. I'm still a little hesitant to say "this is it, I'm back for real". But the signs are looking good. Thank you for sticking with me through this.

1 0

[PATCH ucspi-vsock] vsockserver: use fclose instead of close
by Alyssa Ross 10 Mar '21

10 Mar '21

stdio can buffer output, so if we close stdout without going through stdio, there might be buffered output that is never written. --- vsockserver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vsockserver.c b/vsockserver.c index dd9a74a..196056a 100644 --- a/vsockserver.c +++ b/vsockserver.c @@ -90,7 +90,7 @@ int main(int argc, char *argv[]) if (notify) { printf("%" PRIu32 "\n", lport); - close(STDOUT_FILENO); + fclose(stdout); } setenvf("VSOCKLOCALCID", 1, "%" PRIu32, lcid); -- 2.30.0

2 2

[PATCH ucspi-vsock] Makefile: link object files instead of source files
by Alyssa Ross 10 Mar '21

10 Mar '21

Previously this would (I assume) needlessly recompile vsockserver.c and vsockclient.c when Make has already automatically compiled those. GNU Make has an automatic variable, $+, that we could use here, but currently the Makefile is portable, and it would be a shame to require GNU Make just for that. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index b931c89..4f11b64 100644 --- a/Makefile +++ b/Makefile @@ -19,9 +19,9 @@ install: vsockclient vsockserver .PHONY: install vsockclient: vsockclient.o env.o log.o util.o vsock.o - $(CC) $(LDFLAGS) -o vsockclient vsockclient.c env.o log.o util.o vsock.o $(LDLIBS) + $(CC) $(LDFLAGS) -o vsockclient vsockclient.o env.o log.o util.o vsock.o $(LDLIBS) vsockserver: vsockserver.o env.o log.o util.o vsock.o - $(CC) $(LDFLAGS) -o vsockserver vsockserver.c env.o log.o util.o vsock.o $(LDLIBS) + $(CC) $(LDFLAGS) -o vsockserver vsockserver.o env.o log.o util.o vsock.o $(LDLIBS) vsockclient.o: env.h log.h util.h vsock.h vsockserver.o: env.h log.h util.h vsock.h -- 2.30.0

2 1

[PATCH ucspi-vsock] vsock_accept: return fd instead of 0 on success
by Alyssa Ross 10 Mar '21

10 Mar '21

This would result in the spawned process being hooked up to stdin, instead of the vsock. Then stdin would be closed, so subsequent processes would be connected to nothing. Oops. --- I am... a bit embarassed that I didn't notice this after already fixing the exact same problem in vsock_connect[1]. Maybe I can write an integration test that runs vsockserver and vsockclient and checks they actually do the right thing... [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20210309171816.8589-1… vsock.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/vsock.c b/vsock.c index d9ff3b6..e6a173c 100644 --- a/vsock.c +++ b/vsock.c @@ -32,14 +32,15 @@ int vsock_accept(int sockfd, uint32_t *cid, uint32_t *port) { struct sockaddr_vm addr = { 0 }; socklen_t addr_size = sizeof addr; + int fd; - if (accept(sockfd, (struct sockaddr *)&addr, &addr_size) == -1) + if ((fd = accept(sockfd, (struct sockaddr *)&addr, &addr_size)) == -1) return -1; *cid = addr.svm_cid; *port = addr.svm_port; - return 0; + return fd; } int vsock_connect(int fd, uint32_t cid, uint32_t port) -- 2.30.0

2 1

[PATCH ucspi-vsock] vsock_open: return fd instead of 0 on success
by Alyssa Ross 10 Mar '21

10 Mar '21

Previously, this returned the return value of connect(2), which is 0 on success. So stdin would be assigned to descriptors 6 and 7 in vsockclient instead of the socket. Oops. --- vsock.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/vsock.c b/vsock.c index 3bcd8b3..d9ff3b6 100644 --- a/vsock.c +++ b/vsock.c @@ -55,7 +55,10 @@ int vsock_open(uint32_t cid, uint32_t port) if (fd == -1) return -1; - return vsock_connect(fd, cid, port); + if (vsock_connect(fd, cid, port) == -1) + return -1; + + return fd; } int vsock_get_port(int fd, uint32_t *port) -- 2.30.0

2 1

[PATCH www] index.html: add alt text to logo
by Alyssa Ross 19 Dec '20

19 Dec '20

The empty alt text would make the image basically invisible if the user agent didn't display the image for whatever reason. This would have been fine if the image was entirely decorative, but since it's also the only way to navigate to the logo page it's important it has some fallback content so there's still something to select. --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 10dcdeb..4345121 100644 --- a/index.html +++ b/index.html @@ -17,8 +17,8 @@ <body> <a href="logo" style="float: left; margin: 0 1em 0.5em 0"> - <img class="logo" src="logo/logo_html.svg" width="70" height="70" alt=""> - <img class="no-logo" srcset="logo/logo140.png 140w" src="logo/logo70.png" width="70" height="70" alt="" hidden loading="lazy"> + <img class="logo" src="logo/logo_html.svg" width="70" height="70" alt="Spectrum logo"> + <img class="no-logo" srcset="logo/logo140.png 140w" src="logo/logo70.png" width="70" height="70" alt="Spectrum logo" hidden loading="lazy"> </a> <h1>Spectrum — a step towards <em>usable</em> secure computing</h1> -- 2.27.0

1 0

[PATCH www] design.html: backpedal a bit on POWER9
by Alyssa Ross 29 Nov '20

29 Nov '20

Supporting POWER9 isn't going to be as easy as I'd initially hoped. This patch aims to explain that there are blockers that I'd need help overcoming to be able to support it, even though I'd still like to. I don't want to be promising anything I can't deliver on, and I now know that it's very unlikely I'll be able to deliver on this without help. Reported-by: Molly Miller <mm(a)m-squa.red> --- design.html | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/design.html b/design.html index 181c15c..f683ed4 100644 --- a/design.html +++ b/design.html @@ -127,18 +127,26 @@ Management Engine</a> / <a href="https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor">AMD Platform Security Processor</a>. -<p>So, Spectrum will additionally have -first class support for at least ppc64le. This architecture has been -chosen because it is the only other architecture that can come close -to the sheer performance x86_64 can offer at the high end, and -because, in stark contrast to x86_64, it is possible to buy a new -ppc64le (POWER9) system that does not require any proprietary firmware -that cannot be inspected and audited. It is a goal of the project to -build all packages, x86_64 and ppc64le, on POWER9 hardware. Even if a -user has to trust the x86_64 computer available to them, anti-freedom -firmware, undocumented backdoors and all, it would be a disservice to -them to force them to use packages built on other such untrustworthy -hardware. +<p> +I would like Spectrum to additionally have first class support for at +least ppc64le. This is the only other architecture that can come +close to the sheer performance x86_64 can offer at the high end, and +in stark contrast to x86_64, it is possible to buy a new ppc64le +(POWER9) system that does not require any proprietary firmware that +cannot be inspected and audited. A blocker for POWER9 support is an +support in crosvm for virtualizing that architecture, which is outside +the expertise of anybody currently working on Spectrum but would be a +very welcome contribution. + +<p> +Ideally, all Spectrum packages, x86_64 and ppc64le, would be built on +POWER9 hardware. Even if a user has to trust the x86_64 computer +available to them, anti-freedom firmware, undocumented backdoors and +all, they would be able to benefit from binary packages that were +built on trustworthy hardware without these limitations. +Unfortunately, preliminary research has shown that x86_64 +virtualization on POWER9 is not currently sufficiantly performant for +this to be feasible. <p> <small>Permission is granted to copy, distribute and/or modify this -- 2.27.0

2 6