linux-kernel - Re: [PATCH 08/36] AArch64: Kernel booting and initialisation

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: <CAMuHMdU24_7AScHyS+-xD+6rw-pw_6sP19TME4ZOpNxC+MLe_g@mail.gmail.com>
Date:	Fri, 20 Jul 2012 14:32:39 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Jon Masters <jonathan@...masters.org>,
	Christopher Covington <cov@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Will Deacon <Will.Deacon@....com>
Subject: Re: [PATCH 08/36] AArch64: Kernel booting and initialisation

Hi Catalin,

On Fri, Jul 20, 2012 at 12:52 PM, Catalin Marinas
<catalin.marinas@....com> wrote:
> On Fri, Jul 20, 2012 at 09:28:12AM +0100, Arnd Bergmann wrote:
>> On Friday 20 July 2012, Jon Masters wrote:
>> > > I think it would be best to list the technical limitations, from the
>> > > kernel's perspective, of the unsupported exception levels and the
>> > > advantages of the supported exception levels here. If you want to guide
>> > > system builders towards EL2, I think it'd be more convincing to document
>> > > the relevant technical aspects (perhaps KVM needs facilities only
>> > > available in EL2) than just providing an unexplained requirement.
>> >
>> > Unless you enter at EL2 you can never install a hypervisor. That's the
>> > reason for the requirement for generally entering at EL2 when possible.
>>
>> How do nested hypervisors work in this scenario? Does the first-level
>> hypervisor (counting from most priviledged) provide a guest that starts
>> in an emulated EL2 state, or is this done differently?
>
> Your favourite topic :). Self virtualisation is not easily possible, at
> least not with how KVM on ARM is being implemented. The hardware does
> not allow code running at EL1 to be told that it is at EL2 (or code
> running at EL2 to be trapped at EL2). So for normal virtualisation,
> guest OSes start at EL1 and they benefit of all the hardware
> acceleration. If a guest OS wants to run KVM again, it won't have access
> to the virtualisation extensions (EL2 system register access would cause
> an undefined trap). The best it can do is run the nested guest OS in EL0
> and trap accesses to system registers (no that different from Qemu).
>
> If such feature is needed, the best approach is for all kernels, host or
> guest, to always enter at (non-secure) EL1. The EL2 would have a clearly
> defined HVC API for nested page tables, virtual interrupts, context
> switching etc. This way, the host OS can inform the hypervisor that
> guest OSes are allowed to use this API for their own nested guests. But
> getting such hypervisor API right is a bit tricky and the feedback from
> the KVM guys so far is that they need the flexibility of running their
> own code at EL2. I guess another benefit is that both KVM and Xen could
> use the same API.
>
> But is this feature really needed?

Sure :-)

A sysadmin can prevent me from running my own virtualization layer and
managing my own virtual machines (that's why UserModeLinux is so interesting).

Can software detect if it's running in EL1 or EL2 (and e.g. refuse to run)?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/