From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 20DD6C433FE for ; Fri, 30 Sep 2022 09:48:15 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CAA8B84C01; Fri, 30 Sep 2022 11:48:12 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="kwPBu+eq"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2826984C01; Fri, 30 Sep 2022 11:48:12 +0200 (CEST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5EB538423D for ; Fri, 30 Sep 2022 11:48:09 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jens.wiklander@linaro.org Received: by mail-lf1-x12c.google.com with SMTP id bu25so6074199lfb.3 for ; Fri, 30 Sep 2022 02:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=EfQqAkMQv7fjBIRLRlo0QWGxYdgxqFmhMlRWZqiL6Po=; b=kwPBu+eq0CjDYNIo5eUqyBtAr0mztTnMzMxEvMQlA4Arg0fJ0XMCZVAQ42IMFlza8m QhsAOy20S2Pp1GyG0qTloK1I/8BmREAmBScNqP+V5VUvNCAhuGQAoq7Py5r7LvqRVe1G DUxVOOsf2XYirE/SmljmsRbhHRRkjsOXlo+SMn6Q2fMR4Q7znw0t2kAPNq99XCX0KnSF NMlgA5s/YqHE08W9laXiHd/khGm9DMfmRMyqBhz6lZpQ7DVaxx8A43mhCKI7Uv0MCdEA VrWi/ebsdU1QHTlIIxJ05f8eRU752rs1o1JZY5YVoiBSvARZYx2xFMzg9IfcnXldy+nB krWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=EfQqAkMQv7fjBIRLRlo0QWGxYdgxqFmhMlRWZqiL6Po=; b=TJzgi8u2FHDrAdMRDxWMgUxeuZxArvXHQkDy85+b6esqmeru+jX6QXgLr9izuEk7R+ XitXopVun/Tq66zq1c1+p0MELDjsYYGNqMFtNun37GNDxJSRVV/9znlu14TS/Lr/yCax OqHhfwYmY6kT5ploz2FOAYYpelU2COkudadSr3dS1WuFio00F4vKHre9CT/UsiXXQs39 5FBH65bXRhKKdz2+OlyXyv3cwdB1kfAIqPxXtRKK4uQBEhCfJj+JhjtsySYi6q4olnNL c73HLjr0aHiXXdNQfyNpEaeit/QeJQkrE2IzGAtJmLVdGRusSEcxjlIJuQ9d1/QpDSSr ME9A== X-Gm-Message-State: ACrzQf2BeO+Nxncl6XMhV8zt0ZQS6fkPTO4EHgzpw1Ej+pCJRiX0BaOj lzP57IJ0yqTgc2YFsxn9OHP1gg== X-Google-Smtp-Source: AMsMyM7BYVxeYV62zruF33tQ5pOYyBbr9+T/gbTnf5dzV8O+1NZLwVchXx/hok8j9kUd/ZAuHH6dyQ== X-Received: by 2002:a05:6512:b01:b0:4a1:baae:327d with SMTP id w1-20020a0565120b0100b004a1baae327dmr2948057lfu.668.1664531288621; Fri, 30 Sep 2022 02:48:08 -0700 (PDT) Received: from jade (h-79-136-84-253.A175.priv.bahnhof.se. [79.136.84.253]) by smtp.gmail.com with ESMTPSA id e1-20020a2e9e01000000b0026548b59479sm114740ljk.64.2022.09.30.02.48.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 02:48:07 -0700 (PDT) Date: Fri, 30 Sep 2022 11:48:04 +0200 From: Jens Wiklander To: Abdellatif El Khlifi Cc: achin.gupta@arm.com, ilias.apalodimas@linaro.org, nd@arm.com, sjg@chromium.org, trini@konsulko.com, u-boot@lists.denx.de, vishnu.banavath@arm.com, xueliang.zhong@arm.com Subject: Re: [PATCH v5 02/10] arm64: smccc: clear the Xn registers after SMC calls Message-ID: References: <20220926101723.9965-1-abdellatif.elkhlifi@arm.com> <20220926140827.15125-1-abdellatif.elkhlifi@arm.com> <20220926140827.15125-3-abdellatif.elkhlifi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220926140827.15125-3-abdellatif.elkhlifi@arm.com> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On Mon, Sep 26, 2022 at 03:08:19PM +0100, Abdellatif El Khlifi wrote: > set to zero the x0-x17 registers > > As per the SMCCC v1.2 spec, unused result and scratch registers > can leak information after an SMC call. We can mitigate against > this risk by returning zero in each register. > > The leakage we are referring to is data leakage across exception > levels. The intent is to prevent lower exception levels (EL1/EL0) > from reading the SMC data exchanged at EL2. > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > --- > > Changelog: > =============== > > v4: > > * move the clearing code into a new macro: clear_gp_regs > > v3: > > * clear the Xn registers after SMC calls > > > arch/arm/cpu/armv8/smccc-call.S | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S > index ec6f299bc9..32f3eb8eeb 100644 > --- a/arch/arm/cpu/armv8/smccc-call.S > +++ b/arch/arm/cpu/armv8/smccc-call.S > @@ -50,6 +50,12 @@ ENDPROC(__arm_smccc_hvc) > > #ifdef CONFIG_ARM64 > > + .macro clear_gp_regs > + .irp n,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17 > + mov x\n, xzr > + .endr > + .endm > + > .macro SMCCC_1_2 instr > /* Save `res` and free a GPR that won't be clobbered */ > stp x1, x19, [sp, #-16]! > @@ -84,6 +90,9 @@ ENDPROC(__arm_smccc_hvc) > stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] > stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] > > + /* x0-x17 registers can leak information after an SMC or HVC call. Let's clear them */ > + clear_gp_regs > + This should in my opinion not be needed. The higher exception level should only return what it indends to return and certainly not rely on lower exception levels to try to hide eventual unintentionally revealed secrets. In an earlier conversation you said: > The leakage we are referring to is data leakage across exception levels. > The intent is to prevent lower exception levels (EL1/EL0) to read the > data exchanged at EL2. > > The linux kernel clears the general purpose registers before switching > to EL0. As far as I know u-boot doesn't. > > So, the code above makes sure the registers are cleared. U-Boot is as far as I know not changing to EL0. Do you have a real example where this cleaning actually would be needed? If it's needed I'd expect the cleaning to be done just before changing exception level. Cheers, Jens > /* Restore original x19 */ > ldp xzr, x19, [sp], #16 > ret > -- > 2.17.1 >