. my initial motivation for ARM was that
intel seemed more prone to #spectre than ARM;
https://developer.arm.com/support/security-update
"majority of Arm processors are not impacted
by any variation of this side-channel speculation mechanism."
and is ARM saddled with ME or SMM? ...not sure.
I've had an ARM-based laptop (the chromebook),
there are more coming but it was rocky start.
https://www.computerworld.com/article/3161291/chromebooks/arm-to-battle-intel-in-chromebooks-and-windows-10.html
however:
https://www.pcworld.com/article/2834764/arm-vs-intel-why-chipmakers-want-your-chromebooks-brains.html
"while ARM can run most other operating systems,
it can’t run Windows—at least, not the traditional
X86-based Windows that is powered by AMD and Intel chips."
deal killer?
On Wed, Jan 10, 2018 at 5:25 PM, taii...@gmx.com wrote:
>
> And yes ARM has a kind of IOMMU, I believe it is called GIC-v3 but not
> available on the average ARM stuff like a laptop or phone.
>
. GIC-v3 is version 3 of the Generic Interrupt Controller;
http://infocenter.arm.com/help/topic/com.arm.doc.dai0492b/GICv3_Software_Overview_Official_Release_B.pdf
the feature like VT-d on ARM is SMMU:
https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf
"Intel Virtualization Technology for Direct I/O [Intel VT-d]
is an I/O memory management unit (IOMMU)
designed for the VMM (Virtual Machine Monitor),
to support I/O virtualization.
Since Intel VT-d has the capability of
fine-grained access control per device,
it is a better mitigation for DMA attacks.
Other system architectures also have similar IOMMU capability,
such as [AMD IOMMU], [ARM SMMU]."
details of GIC-v3:
http://infocenter.arm.com/help/topic/com.arm.doc.dai0492b/GICv3_Software_Overview_Official_Release_B.pdf
Support for virtualization.
Support for more than eight PE[processor elements]s.
Support for up to 1020 interrupt IDs.
Support for two Security states.
Support for more than eight PEs.
Support for message-based interrupts.
Support for more than 1020 interrupt IDs.
System register access to the CPU Interface registers.
An enhanced security model,
separating Secure and Non-secure Group 1 interrupts.
Virtualization:
ARMv8-A includes optional support for virtualization.
To complement this, GICv3 also supports virtualization.
Support for virtualization support in GICv3 adds:
Hardware virtualization of the CPU interface registers.
Virtual interrupts.
Maintenance interrupts.
NOTE: The GIC architecture does not provide
features for virtualizaing the Distributor,
Redistributors or ITSs.
Virtualization of these interfaces must be handled by software.
This is outside the scope of this document and is not described here.
ARM Virtualization with SMMU:
https://www.arm.com/files/pdf/System-MMU-Whitepaper-v8.0.pdf
The ARM® Architecture Virtualization Extensions
and the importance of System MMU [mem mgt unit]
for virtualized solutions and beyond.
This paper ...explores how SMMU
will enable vast reductions in
software costs and complexity,
and at the same time aligning with the ARM’s ethos of
low power, high performance designs.
.
Memory management challenges in virtualized systems:
In a virtualized system, the subject of memory management
is very important and can lead to substantial complexity.
One of the key functions of most operating systems
is to support a stage of virtual memory management
to partition the physical memory
controlled by the operating system
across multiple processes.
In a system where each Guest OS is running inside a Virtual Machine,
the memory that is being allocated by the Guest OS
is not the true physical memory of the system,
but instead it is an intermediate physical memory.
The VMM directly controls the allocation of the
actual physical memory,
thereby fulfilling its role of arbiter
of the shared physical resources.
There are two approaches to handling the
two stage of address translation (VA to IPA and IPA to PA).
In current systems where only one stage
of memory address space translation
is provided in hardware,
for example using the MMU in the CPU,
the hypervisor must manage the relationship between
VA, IPA and PA directly.
This is generally done by the hypervisor
maintaining its own translation tables
(called shadow translation tables),
which are derived by interpreting
each Guest OS translation table.
The hypervisor must ensure that
all changes to the Guest OS translation tables
are reflected in the shadow structures,
as well as enforcing protection and redirecting
access faults to the appropriate stage.
The required mechanism can be complex
and add performance overhead.
The alternative is to use hardware assistance
for both stages of translation,
and this is what the ARM SMMU enables.
I later thought this topic more appropriate for the qubes-devel newsgroup;
https://groups.google.com/d/msgid/qubes-devel/ce1a9bb0-5b7e-441f-87ae-16df277fd428%40googlegroups.com
.
but if ARM can't do Windows...
--
Amer
