* [PATCH www] design.html: backpedal a bit on POWER9
@ 2020-11-18 12:01 Alyssa Ross
2020-11-18 12:52 ` Michael Raskin
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Alyssa Ross @ 2020-11-18 12:01 UTC (permalink / raw)
To: devel; +Cc: 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.
Reported-by: Molly Miller <mm@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH www] design.html: backpedal a bit on POWER9
2020-11-18 12:01 [PATCH www] design.html: backpedal a bit on POWER9 Alyssa Ross
@ 2020-11-18 12:52 ` Michael Raskin
2020-11-20 14:06 ` Alyssa Ross
2020-11-21 15:23 ` [PATCH www 2/1] design.html: mention aarch64 as well as x86_64 Alyssa Ross
2020-11-21 16:34 ` Michael Raskin
2 siblings, 1 reply; 7+ messages in thread
From: Michael Raskin @ 2020-11-18 12:52 UTC (permalink / raw)
To: hi, devel; +Cc: mm
>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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH www] design.html: backpedal a bit on POWER9
2020-11-18 12:52 ` Michael Raskin
@ 2020-11-20 14:06 ` Alyssa Ross
0 siblings, 0 replies; 7+ messages in thread
From: Alyssa Ross @ 2020-11-20 14:06 UTC (permalink / raw)
To: Michael Raskin; +Cc: Molly Miller, devel
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
> 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).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH www 2/1] design.html: mention aarch64 as well as x86_64
2020-11-18 12:01 [PATCH www] design.html: backpedal a bit on POWER9 Alyssa Ross
2020-11-18 12:52 ` Michael Raskin
@ 2020-11-21 15:23 ` Alyssa Ross
2020-11-21 16:34 ` Michael Raskin
2 siblings, 0 replies; 7+ messages in thread
From: Alyssa Ross @ 2020-11-21 15:23 UTC (permalink / raw)
To: devel; +Cc: Molly Miller, Michael Raskin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH www 2/1] design.html: mention aarch64 as well as x86_64
2020-11-18 12:01 [PATCH www] design.html: backpedal a bit on POWER9 Alyssa Ross
2020-11-18 12:52 ` Michael Raskin
2020-11-21 15:23 ` [PATCH www 2/1] design.html: mention aarch64 as well as x86_64 Alyssa Ross
@ 2020-11-21 16:34 ` Michael Raskin
2020-11-22 20:09 ` Alyssa Ross
2020-11-29 23:54 ` [PATCH www 3/1] design.html: mention goal of diverse build hardware Alyssa Ross
2 siblings, 2 replies; 7+ messages in thread
From: Michael Raskin @ 2020-11-21 16:34 UTC (permalink / raw)
To: hi, devel; +Cc: mm
>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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH www 2/1] design.html: mention aarch64 as well as x86_64
2020-11-21 16:34 ` Michael Raskin
@ 2020-11-22 20:09 ` Alyssa Ross
2020-11-29 23:54 ` [PATCH www 3/1] design.html: mention goal of diverse build hardware Alyssa Ross
1 sibling, 0 replies; 7+ messages in thread
From: Alyssa Ross @ 2020-11-22 20:09 UTC (permalink / raw)
To: Michael Raskin; +Cc: devel, Molly Miller
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
> >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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH www 3/1] design.html: mention goal of diverse build hardware
2020-11-21 16:34 ` Michael Raskin
2020-11-22 20:09 ` Alyssa Ross
@ 2020-11-29 23:54 ` Alyssa Ross
1 sibling, 0 replies; 7+ messages in thread
From: Alyssa Ross @ 2020-11-29 23:54 UTC (permalink / raw)
To: devel, Michael Raskin; +Cc: Molly Miller
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-11-29 23:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-18 12:01 [PATCH www] design.html: backpedal a bit on POWER9 Alyssa Ross
2020-11-18 12:52 ` Michael Raskin
2020-11-20 14:06 ` Alyssa Ross
2020-11-21 15:23 ` [PATCH www 2/1] design.html: mention aarch64 as well as x86_64 Alyssa Ross
2020-11-21 16:34 ` Michael Raskin
2020-11-22 20:09 ` Alyssa Ross
2020-11-29 23:54 ` [PATCH www 3/1] design.html: mention goal of diverse build hardware Alyssa Ross
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).