linux-kernel - Re: [PATCH 00/36] AArch64 Linux kernel port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120715121644.GB10597@arm.com>
Date:	Sun, 15 Jul 2012 13:16:44 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Pavel Machek <pavel@....cz>
Cc:	Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Olof Johansson <olof@...om.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 00/36] AArch64 Linux kernel port

On Sat, Jul 14, 2012 at 10:30:32AM +0100, Pavel Machek wrote:
> > > > Agreed. It's clear from the code that it started out as a copy 
> > > > of the 32 bit ARM code base, which I think was a mistake, but 
> > > > it has also moved on since then and many areas of the 64 bit 
> > > > code are now much cleaner because they don't have to worry 
> > > > about breaking legacy code. We're also more flexible with 
> > > > trying out stuff without having to worry about breaking some 
> > > > 10 year old board code.
> > > 
> > > Just for the record, you guys are repeating all the same 
> > > arguments that led to the x86_64 fork a decade ago...
> > 
> > As I stated already, comparing AArch64 to x86_64 is not right. So even
> > if the arguments may look the same, the context is *different*. AArch64
> > is *not* an extension to the AArch32 mode.
> 
> Is it possible to boot 32-bit OS on aarch64 machine?
> 
> IOW, is it compatible in supervisor mode, too?

The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for AArch32 at kernel level is in
virtual machines or the secure OS. I'll explain below why.

The exception (or privilege) levels on an ARMv8 architecture look like
this:

Secure World	Normal World
+-----+
| EL3 |				- Secure monitor
+-----+
		+-----+
		| EL2 |		- Hypervisor (normal world only)
		+-----+
+-----+		+-----+
| EL1 |		| EL1 |		- OS kernel (secure or normal)
+-----+		+-----+
+-----+		+-----+
| EL0 |		| EL0 |		- User apps (secure or normal)
+-----+		+-----+

In theory, each of these levels (implementation specific) can run both
AArch32 and AArch64 modes. There is however a restriction on how the
mode switching is done - this can only happen on a change of exception
level. When going up the EL the register width (RW) can never go down. A
lower EL can never have a higher RW than a higher EL.

Additionally, the RW (the AArch32/AArch64 mode) for an EL is controlled
by the next higher level (with EL3 hard-wired). An EL cannot cause
itself to switch between AArch32 and AArch64.

AArch64 Linux always runs in normal world because that's where we have
virtualisation support for KVM etc. It is normally started at EL2 (but
falling shortly to EL1) unless it is a guest OS which does not have
access to the virtualisation features.

The secure world on the left hand side runs some dedicated secure
software and the communication between the two worlds is handled via
EL3. That's also the reset mode, so SoC firmware needs to run there. The
secure OS could be a 32-bit one given the investment security companies
put in certification (and that's one reason to have AArch32 support at
EL1)

On the Linux side, to be able to start a 32-bit ARM kernel the firmware
at EL3 would have to configure the lower modes as AArch32. Once that's
done, lower mode would never be able to upgrade itself to AArch64
(rendering all the AArch64 features pretty much unusable). So we require
that any SoC firmware starts the next stage boot-loader or non-secure OS
in AArch64. AArch64 Linux is able to change the execution mode for user
at EL0 (as it is lower). Guest OSes could also run in AArch32 long as
the host Linux has control of EL2.

So while it is possible, the primary target for 32-bit at the OS kernel
level is virtualisation. We also don't plan to support a 32-bit SoC on
ARMv8 systems, given that the compat layer is fully functional.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/