Re: [Xen-devel] Xen on POWER

[André Przywara <andre.przywara@xxxxxxx>]

On 09/03/18 13:35, awokd wrote:
> On Fri, March 9, 2018 11:52 am, awokd wrote:
> 
>> Xen on ARM might be a more reasonable starting point but I'm not sure
>> that would provide enough horsepower to drive a workstation

That's indeed an issue. There are ARM64 SoCs which are very capable and
could easily match or even outperform commodity Intel desktop hardware,
but no-one offers them in a desktop or workstation package. I guess the
seemingly dwindling desktop market is not very attractive to vendors.

>> and have
>> (possibly
>> unfounded) concerns about the platform following in x86's footsteps with
>> TrustZone and end-user lock out.
> 
> Sorry, didn't realize I was replying to someone @arm.com! My possibly
> mistaken perception is that ARM requires proprietary blobs and TrustZone
> provides a way to lock out end-users so they can't provide their own boot
> binaries. In some applications that's a good thing, but not for personal
> use.

That's a common misconception. Trustzone is the marketing name of a
rather innocent, but indeed quite clever architectural feature, namely
to separate the potentially vulnerable "non-secure" OS from some other
trusted code, for instance firmware. The neat property is that this
extends to hardware devices, which can be sorted into one of those two
groups. But how this is actually used is entirely up to the particular
platform.
The boot binary protection is a concept popular in embedded systems and
mobile phones, which is what ARM is often associated with.
But many server like systems (including storage or network focused
boards) run Open Source implementations of the firmware, for instance
the BSD licensed "ARM Trusted Firmware", developed on Github. This makes
the whole firmware on those boards replaceable and visitable. *Some*
systems may ship binary blobs, but this is mostly for system
initialization (DRAM training, platform setup) and the code won't stay
around at OS runtime. Eventually those could be replaced as well.
In fact on those systems you could actually use TrustZone to your
advantage, for instance for storing private keys in a place inaccessible
by the normal (read: hackable) OS, and only offering software interfaces
to encrypt data. The Open Source OP-TEE framework for instance is
exploring this direction.

> It's entirely possible I'm unfairly tarring ARM with the same x86 brush so
> if I'm mistaken on any of these aspects please feel free to correct me
> publicly.

No worries about that, and I actually didn't want to point you to ARM
platforms primarily (though this might have been a interesting side
effect. ;-)
I was just wondering if coming up with a whole new platform port of Xen
is the right and reasonable answer to you security concerns on your
existing platform. I very much fancy the idea of alternative platforms
(even non-ARM ;-), but it might be more worthwhile to support those
people who work on fixing or mitigating the existing problems (x86
binary blob firmware). Or even better: Piggy-back on the already
existing ARM64 port of Xen and help improving that.
Given from our experience there are many very detailed and intricate
problems to solve in such a platform port, especially since Power
deviates from both x86 and ARM in some ways (for instance paging and
TLBs). Also things like memory model and ordering, asynchronous
exceptions and tons of races in various places need to be considered.
Starting from scratch here sounds like a mammoth task, judging from the
bugs that we still discover on a somewhat weekly base here in the
existing Xen ports.
I don't want to steer you away from the Power on Xen port, it might
actually be beneficial to the Xen ecosystem, but if you are hoping for
having something usable in a year or so, you might be disappointed ;-)
At least without having the proper resources, to somewhat support
George's suggestions.

Cheers,
Andre.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel