linux-kernel - Re: [RFC] arm: Handle starting up in secure mode

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] [day] [month] [year] [list]

Message-ID: <CAPz6YkU0rJBAniFidASQm8E15bo=jCrbo1QeWFtXELeuj33Lsw@mail.gmail.com>
Date:	Fri, 19 Sep 2014 09:52:17 -0700
From:	Sonny Rao <sonnyrao@...omium.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Christopher Covington <cov@...eaurora.org>,
	Peter Maydell <peter.maydell@...aro.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 6:30 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
> 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).

Well, for us, the issue is that our boot-loader isn't involved in
secondary cpu startup, either at boot time nor suspend/resume or cpu
hotplug/power gating.
So we certainly could have the boot loader set up the GIC for
non-secure access and then this type of solution would work, though
I'm not sure what else might need to be set up for non-secure access.

>
> --
> 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/