[PATCH www] design.html: backpedal a bit on POWER9
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
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.
I wonder whether it is still correct to imply that Aarch64 is not comparable in performance. It does look even worse than x86_64 from transparency point of view, though. Do I understand correctly that none of rust-vmm versions support POWER9?
I wonder whether it is still correct to imply that Aarch64 is not comparable in performance. It does look even worse than x86_64 from transparency point of view, though.
Good point, I'll revise that.
Do I understand correctly that none of rust-vmm versions support POWER9?
Correct (as far as I know).
Michael is right that aarch64 is probably suitably performant at this point. I also improved the arguments here a bit as it was lacking before. For example, the "huge attack surface" (of the Management Engine) link pointed to a talk that wasn't about the ME at all, but about a backdoor in VIA's instruction set. Cc: Michael Raskin <7c6f434c@mail.ru> --- I'd like to continue to link to x86 Considered Harmful somewhere in the text, but couldn't figure out how to fit it in since there's not really anywhere I'm talking about x86 specifically rather than all architectures. I'd appreciate suggestions for how I might do that. design.html | 47 +++++++++++++++++++++++++++++------------------ 1 file changed, 29 insertions(+), 18 deletions(-) diff --git a/design.html b/design.html index f683ed4..3c0e37d 100644 --- a/design.html +++ b/design.html @@ -113,19 +113,28 @@ configuration file. This use case should be kept in mind when writing the Nix API for Spectrum. <p> -While Spectrum is expected to largely run on personal computers, most -of which will almost certainly use the x86_64 architecture, this will -not be the only architecture given first class support by Spectrum. -One of the advantages to Spectrum's Linux base is the extremely wide -hardware support that Linux offers, and, beyond that, x86_64 -is <a href="https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf">notably -untrustworthy</a>, especially with -the <a href="https://invidio.us/watch?v=_eSAF_qT_FY">huge attack -surface</a> of -the <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine">Intel -Management Engine</a> -/ <a href="https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor">AMD -Platform Security Processor</a>. +Spectrum is expected to largely run on personal computers, most of +which will almost certainly use the x86_64 or aarch64 architectures. +Unfortunately, these common architectures are the most lacking in +terms of trustworthiness. All require unauditable proprietary blogs +to boot, and +the <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine">Intel +Management +Engine</a>, <a href="https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor">AMD +Platform Security Processer</a>, +and <a href="https://en.wikipedia.org/wiki/ARM_architecture#Security_extensions">ARM +TrustZone</a>, all of which are constantly running highly privileged, +unauditable code. A backdoor or compromise in any of this code could +give complete access to the system, invisibly to running the operating +system. As more functionality is moved into these environments, the +attack surfaces grow larger and larger, and +already <a href="https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities">many +vulnerabilities</a> have been demonstrated in the most studied of +these systems, Intel's Management Engine. Fears of backdoors are not +unjustified either — VIA C3 x86 CPUs used in personal computers have +been found to contain +a <a href="https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs-wp.pdf">hardware +backdoor</a> allowing local privilege escalation. <p> I would like Spectrum to additionally have first class support for at @@ -133,13 +142,15 @@ 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. +cannot be inspected and audited. One of the advantages of Spectrum's +Linux base is the extremely wide hardware support that Linux offers, +so the only blocker for POWER9 support is 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 +Ideally, all Spectrum packages, for all architectures, 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 -- 2.27.0
I'd like to continue to link to x86 Considered Harmful somewhere in the text, but couldn't figure out how to fit it in since there's not really anywhere I'm talking about x86 specifically rather than all architectures. I'd appreciate suggestions for how I might do that.
I think it is nice to have «why not ARM» and «why not x86*» sections when you have an implementation that you are justifying, and no doubts on the way-cheaper attack level (there must be a memory attack on Sway given a hijacked browser, mustn't there be?) Right now, you getting a restful break is more useful than picking wording on choices Spectrum cannot yet afford to make. [horrible mis-implementation of user hostility is worse than no implementation, perfect implementations do nto exist]
<p> I would like Spectrum to additionally have first class support for at
Looks fine
+cannot be inspected and audited. One of the advantages of Spectrum's +Linux base is the extremely wide hardware support that Linux offers, +so the only blocker for POWER9 support is 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.
Looks frank and true
<p> -Ideally, all Spectrum packages, x86_64 and ppc64le, would be built on +Ideally, all Spectrum packages, for all architectures, would be built on POWER9 hardware. Even if a user has to trust the x86_64 computer
_Ideally_ on diverse hardware with more than one transparent-ish platform, because lack of blobs to load does not mean lack of backed-in vulnerable functionality. Open POWER9 cores help, but do not prove faithful implementation on a specific chip in your hands, all that stuff. I would put as « Ideally, all Spectrum packages, for all architectures, would be built on diverse hardware including a platform with POWER9 level of openness. » But, again, this a bridge to burn once it is crossed, or something.
I'd like to continue to link to x86 Considered Harmful somewhere in the text, but couldn't figure out how to fit it in since there's not really anywhere I'm talking about x86 specifically rather than all architectures. I'd appreciate suggestions for how I might do that.
I think it is nice to have «why not ARM» and «why not x86*» sections when you have an implementation that you are justifying, and no doubts on the way-cheaper attack level (there must be a memory attack on Sway given a hijacked browser, mustn't there be?)
Right now, you getting a restful break is more useful than picking wording on choices Spectrum cannot yet afford to make.
Yeah good idea but absolutely. I just want to make sure that while I'm having the break I don't have to worry that people are looking at the website and getting the impression that I'm going to be able to do something I'm not.
<p> -Ideally, all Spectrum packages, x86_64 and ppc64le, would be built on +Ideally, all Spectrum packages, for all architectures, would be built on POWER9 hardware. Even if a user has to trust the x86_64 computer
_Ideally_ on diverse hardware with more than one transparent-ish platform, because lack of blobs to load does not mean lack of backed-in vulnerable functionality. Open POWER9 cores help, but do not prove faithful implementation on a specific chip in your hands, all that stuff.
I would put as « Ideally, all Spectrum packages, for all architectures, would be built on diverse hardware including a platform with POWER9 level of openness. »
But, again, this a bridge to burn once it is crossed, or something.
Yeah sounds good, I think I'll just go with exactly that phrasing.
Thanks-to: Michael Raskin <7c6f434c@mail.ru> --- design.html | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/design.html b/design.html index 285d743..a126bee 100644 --- a/design.html +++ b/design.html @@ -151,14 +151,14 @@ anybody currently working on Spectrum but would be a very welcome contribution. <p> -Ideally, all Spectrum packages, for all architectures, 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. +Ideally, all Spectrum packages, for all architectures, would be built +on diverse hardware including a platform with POWER9's level of +openness. 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
participants (2)
-
Alyssa Ross
-
Michael Raskin