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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 19 Sep 2014 14:30:56 +0100 From: Catalin Marinas <catalin.marinas@....com> To: Christopher Covington <cov@...eaurora.org> Cc: Peter Maydell <peter.maydell@...aro.org>, Sonny Rao <sonnyrao@...omium.org>, Will Deacon <Will.Deacon@....com>, Mark Rutland <Mark.Rutland@....com>, Stephen Boyd <sboyd@...eaurora.org>, Marc Zyngier <Marc.Zyngier@....com>, arm-mail-list <linux-arm-kernel@...ts.infradead.org>, Doug Anderson <dianders@...omium.org>, lkml - Kernel Mailing List <linux-kernel@...r.kernel.org> 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 <cov@...eaurora.org> 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). -- 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/
Powered by blists - more mailing lists