From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Tue, 12 Jun 2018 22:32:38 +0200 Subject: [U-Boot] [PATCH 1/3] ARM: HYP/non-sec: save and restore stack In-Reply-To: <2459cc4e4ce92c68@bloch.sibelius.xs4all.nl> References: <20180612172748.36790-1-kettenis@openbsd.org> <20180612172748.36790-2-kettenis@openbsd.org> <863fe22d-3220-de46-4161-376acc12f8b6@suse.de> <2459cc4e4ce92c68@bloch.sibelius.xs4all.nl> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12.06.18 22:17, Mark Kettenis wrote: >> From: Alexander Graf >> Date: Tue, 12 Jun 2018 20:46:02 +0200 >> >> On 12.06.18 19:27, Mark Kettenis wrote: >>> The current code that switches into HYP mode doesn't bother to set >>> up a stack for HYP mode. This doesn't work for EFI applications >>> as they expect a usable stack. Fix this by saving the stack >>> pointer before switching and use it to set SP_hyp from monitor. >>> This restores the stack pointer when we drop into HYP mode. >>> >>> Signed-off-by: Mark Kettenis >> >> Can we be sure that the stack in MON is usable from HYP? > > I think so. It is the stack that U-Boot sets up for itself in normal > memory. As far as I can tell arm64 re-uses this stack when dropping > down into EL2 as well. Well, the question is whether it's secure or non-secure memory. Usually the DRAM controller can be configured to have a window of RAM only available to secure and I'd certainly hope that at least the U-Boot parts that are preserved in EL3 live in such a secured area :) Alex