linux-kernel - Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC

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: <20150306114021.GF8700@leverpostej>
Date:	Fri, 6 Mar 2015 11:40:21 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Chanwoo Choi <cw00.choi@...sung.com>
Cc:	Chanwoo Choi <cwchoi00@...il.com>,
	"kgene@...nel.org" <kgene@...nel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"arnd@...db.de" <arnd@...db.de>, "olof@...om.net" <olof@...om.net>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"inki.dae@...sung.com" <inki.dae@...sung.com>,
	"chanho61.park@...sung.com" <chanho61.park@...sung.com>,
	"sw0312.kim@...sung.com" <sw0312.kim@...sung.com>,
	"jh80.chung@...sung.com" <jh80.chung@...sung.com>,
	"ideal.song@...sung.com" <ideal.song@...sung.com>,
	"a.kesavan@...sung.com" <a.kesavan@...sung.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit
 Exynos5433 SoC

> >>>> CPU0 (boot CPU) is only well working for CPU_OFF.
> >>>> But when I try to turn on the CPU0 after CPU_OFF, I failed it.
> >>>
> >>> That's rather worrying. Can you look into what's going on here? I'd
> >>> rather not have dts describing things which are known to be broken.
> >>
> >> The board dts don't include any node for CPU_ON/OFF.
> > 
> > I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node
> > quoted above, and all the CPUs had enable-method = "psci".
> 
> I mean that there are not additional dt node except for 'cpu' and 'psci' node.

The psci node and cpu enable-method are sufficient. No other nodes
should be relevant.

> > 
> >> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
> >> After lockup happen, I cannot use the console.
> > 
> > That sounds like a pretty major bug.
> > 
> > Are you able to investigate with a hardware debugger?
> 
> I can't do because there are not any jtag connector.

That is very unfortunate. Which PSCI implementation are you using?
Surely whoever developed it has access to debug. Surely they should have
tested this?

> > Do other CPUs eventually log errors regarding the lockup? Or is the
> > machine completely dead from this point on?
> 
> I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show the error log without lockup.
> I gave you wrong infromation about CPU0 off.

Ok. However that's still a major bug.

[...]

> >>>>> I take it CPUs boot at EL2?
> >>>
> >>> Do the CPUs boot at EL1 or EL2?
> >>
> >> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
> >> I think that a few SoC provider probably would know it.
> > 
> > I guess I asked the wrong question.
> > 
> > Do CPUs enter the kernel at EL2 or at EL1?
> 
> Could you give me a tip how to check the kernel at EL2 or EL1?

Hmm... I thought we logged this but it looks like we don't.

You could hack in a check of is_hyp_mode_available() and
is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available,
and whether all CPUs enter at the same mode (mandatory per the boot
protocol).

Thanks,
Mark.
--
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/