Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3404615pxf; Mon, 22 Mar 2021 05:49:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyje9tOPA7nTxdmfougo4truHSS4rMfZqfzoKkl93TlmTtpsixY8Mp+r4ui+B8BezxAFD6f X-Received: by 2002:a17:906:d114:: with SMTP id b20mr19034575ejz.449.1616417354880; Mon, 22 Mar 2021 05:49:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616417354; cv=none; d=google.com; s=arc-20160816; b=eHviURVlD7yxnr69KQ7wn3yQ/q62IAWJHJoBGAoxKQt4ZRNMFo99Tqnkd9DmOlHVdS Y0hKWmMoj1oQkm6jur2m6XlXjJo7gqo30aaVlFcaCIcMwBxISuyTPjxKWXRUgTETgbMw DZiIn5DGKXkp2xf3EXdlY4IfcSX0VGb4XJqvDchK/NMpOVhMm4/KwXcslhO9t+dGdAqX XTOPlaz6Zs1kh4qGgbYMAa/i60dT6slCB+TW3NCrHRtu0tYiMSAJmDoPTj4VA/IRmcuP m8UFk0/ZMJv7Zm1tCli8mlDHF6iAPYsBU5M7LYp5gyDC01YHu4gmiOLMV5P6k3KcXKof oVAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=BoQFpRZ5iAprPLCNR4Budjbp1y0+5Zgtc6n1RTGZDzA=; b=iY3Wz2BKvBlkFzUHoFcFApCQURr56FjLjIlOAjjsQuXgMNiiiXHFfBLM/XQTKuVSyP OXglGQsCAPlh4aoYYkVXmtzPKmG18yEz39I4mCJw1gvzCB47F0oQcnjoHZchP0+hKETC AEMo/1/Ox55uDDsOhqlosLtEqa/T5wApbX5gkGV73Ka/aF1LvGwL0Qx2I22Xb+AIShGO d+bMFVhQabRb+lUbN3M9KYtCplaMSApW10DA5ZH4ndviZcswL6YR9c5cqVxlQnoFtGBA PEHqYpsgGhWSsTQ2QSDwfVD8S4WyrHnDhqMpKeHuUKc91Zpj+jyupe2MChBIer5IFLvt fd7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=z6M7n6iR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sa4si11238383ejb.662.2021.03.22.05.48.51; Mon, 22 Mar 2021 05:49:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=z6M7n6iR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232479AbhCVMrt (ORCPT + 99 others); Mon, 22 Mar 2021 08:47:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:35426 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232003AbhCVMje (ORCPT ); Mon, 22 Mar 2021 08:39:34 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id AFBEB619A2; Mon, 22 Mar 2021 12:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1616416696; bh=QuGiOYuzq0ntzJUrAlRofhELOhughI7VSrqqNFaZxfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z6M7n6iRSSSMdtYZN4pwMhhFa/0uYKJuEtIu8DNTgs0SsGZV+xIswsOB95D51iA4d 9VlSmjao2ZdsXaj12899vXhaghME2eI3HmxjCdYx8/3KgkKrm0VhzWqZoDnmMLTgi1 y5Bpiusxd8Fw4Uf1trx1qwZzQSUrUEpOPDer6kEY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sandipan Das , "Naveen N. Rao" , Michael Ellerman , Sasha Levin Subject: [PATCH 5.10 086/157] powerpc/sstep: Fix load-store and update emulation Date: Mon, 22 Mar 2021 13:27:23 +0100 Message-Id: <20210322121936.515547204@linuxfoundation.org> X-Mailer: git-send-email 2.31.0 In-Reply-To: <20210322121933.746237845@linuxfoundation.org> References: <20210322121933.746237845@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sandipan Das [ Upstream commit bbda4b6c7d7c7f79da71f95c92a5d76be22c3efd ] The Power ISA says that the fixed-point load and update instructions must neither use R0 for the base address (RA) nor have the destination (RT) and the base address (RA) as the same register. Similarly, for fixed-point stores and floating-point loads and stores, the instruction is invalid when R0 is used as the base address (RA). This is applicable to the following instructions. * Load Byte and Zero with Update (lbzu) * Load Byte and Zero with Update Indexed (lbzux) * Load Halfword and Zero with Update (lhzu) * Load Halfword and Zero with Update Indexed (lhzux) * Load Halfword Algebraic with Update (lhau) * Load Halfword Algebraic with Update Indexed (lhaux) * Load Word and Zero with Update (lwzu) * Load Word and Zero with Update Indexed (lwzux) * Load Word Algebraic with Update Indexed (lwaux) * Load Doubleword with Update (ldu) * Load Doubleword with Update Indexed (ldux) * Load Floating Single with Update (lfsu) * Load Floating Single with Update Indexed (lfsux) * Load Floating Double with Update (lfdu) * Load Floating Double with Update Indexed (lfdux) * Store Byte with Update (stbu) * Store Byte with Update Indexed (stbux) * Store Halfword with Update (sthu) * Store Halfword with Update Indexed (sthux) * Store Word with Update (stwu) * Store Word with Update Indexed (stwux) * Store Doubleword with Update (stdu) * Store Doubleword with Update Indexed (stdux) * Store Floating Single with Update (stfsu) * Store Floating Single with Update Indexed (stfsux) * Store Floating Double with Update (stfdu) * Store Floating Double with Update Indexed (stfdux) E.g. the following behaviour is observed for an invalid load and update instruction having RA = RT. While a userspace program having an instruction word like 0xe9ce0001, i.e. ldu r14, 0(r14), runs without getting receiving a SIGILL on a Power system (observed on P8 and P9), the outcome of executing that instruction word varies and its behaviour can be considered to be undefined. Attaching an uprobe at that instruction's address results in emulation which currently performs the load as well as writes the effective address back to the base register. This might not match the outcome from hardware. To remove any inconsistencies, this adds additional checks for the aforementioned instructions to make sure that the emulation infrastructure treats them as unknown. The kernel can then fallback to executing such instructions on hardware. Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()") Signed-off-by: Sandipan Das Reviewed-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210204080744.135785-1-sandipan@linux.ibm.com Signed-off-by: Sasha Levin --- arch/powerpc/lib/sstep.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c index 242bdd8281e0..0f228ee11ca4 100644 --- a/arch/powerpc/lib/sstep.c +++ b/arch/powerpc/lib/sstep.c @@ -2909,6 +2909,20 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs, } + if (OP_IS_LOAD_STORE(op->type) && (op->type & UPDATE)) { + switch (GETTYPE(op->type)) { + case LOAD: + if (ra == rd) + goto unknown_opcode; + fallthrough; + case STORE: + case LOAD_FP: + case STORE_FP: + if (ra == 0) + goto unknown_opcode; + } + } + #ifdef CONFIG_VSX if ((GETTYPE(op->type) == LOAD_VSX || GETTYPE(op->type) == STORE_VSX) && -- 2.30.1