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  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]
Date:	Fri, 19 Sep 2014 14:30:56 +0100
From:	Catalin Marinas <>
To:	Christopher Covington <>
Cc:	Peter Maydell <>,
	Sonny Rao <>,
	Will Deacon <>,
	Mark Rutland <>,
	Stephen Boyd <>,
	Marc Zyngier <>,
	arm-mail-list <>,
	Doug Anderson <>,
	lkml - Kernel Mailing List <>
Subject: Re: [RFC] arm: Handle starting up in secure mode

On Fri, Sep 19, 2014 at 02:22:10PM +0100, Christopher Covington wrote:
> On 09/19/2014 01:56 AM, Peter Maydell wrote:
> > On 17 September 2014 06:25, Christopher Covington <> wrote:
> >> On 09/16/2014 05:24 PM, Christopher Covington wrote:
> >>> On 09/16/2014 05:09 PM, Christopher Covington wrote:
> >>>> ARM Linux currently has the most features available to it in hypervisor
> >>>> (HYP) mode, so switch to it when possible. This can also ensure proper
> >>>> reset of newer registers such as CNTVOFF.
> >>>>
> >>>> The permissions on the Non-Secure Access Control Register (NSACR) are
> >>>> used to probe what the security setting currently is when in supervisor
> >>>> (SVC) mode.
> >>>
> >>> Sorry, this doesn't work yet. I was misinterpreting my test results. For what
> >>> it's worth, my testing and development methodology is to run it after hacked
> >>> up versions of the semihosting bootwrapper on the simulator that corresponds
> >>> to rtsm_ve-aemv8a.dtb (AEM VE FVP these days?) and examine the instruction traces.
> >>
> >> Looks like the real problem was that I was hacking up the bootwrapper
> >> incorrectly--my start-in-secure-mode bootwrapper variant wasn't setting up the
> >> GIC for non-secure access. With that changed, I've tested the following
> >> variations using the Image file in a single core configuration.
> >>
> >> Start in non-secure SVC with non-secure access to GIC configured.
> >>
> >> Start in secure SVC with non-secure access to GIC configured.
> >>
> >> Start in secure SVC with non-secure access to GIC configured and hypervisor
> >> support disabled in the model (-C cluster.has_el2=0). This required setting
> >> the VBAR again in non-secure SVC but with that fix it seems to work. I'll
> >> include this change in v2.
> > 
> > If you're relying on the boot loader to set up the GIC to support
> > non-secure access anyway, why not just have it boot the kernel in Hyp
> > like the boot protocol document recommends? (The same thing as the GIC
> > is going to apply for any other hardware that needs configuration to
> > allow NS access; if we need the firmware to deal with this we might as
> > well just have it boot us in the right mode too.)
> I'd like to get rid of as much of the bootwrapper as possible (having gotten
> spoiled by using QEMU's built-in bootloader). I'm just taking it one step at a
> time. Handling GIC initialization in the kernel is probably the next step.

The problem is that the kernel doesn't know about GIC until much later.
So I don't see an easy workaround, other than relying on the boot-loader
to do the right thing (and then we go to the point Peter made about
changing it to start Linux in Hyp mode directly).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists