From patchwork Mon May 27 16:12:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 13675617 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 449B7C25B78 for ; Mon, 27 May 2024 16:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: Mime-Version:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=rldGSQR+fowZi6JeD3B5NFUCEUq2r/Gwf37dInNm5bw=; b=THM Q6tt1kDt6GUF45S4eVrVtk6Kvh+D6DVTITdbs8wq5QelwjUIRauBv3B0PQgMkxckpPEE0gmJhsjqQ l99TYwFQOTWAj6abhIi/SYaJffK4pve26Rw/2/VQwdbO6k/1pjX2K5jbYonuKQmhk7qrNlSBTamWG A7mVYQWZdy9qUFTDrgdcdEW5ShuJugrjWUeaivbvUJbrWCF5l2TA5qspcCjEwllZPWIIAqhWc4VSN 1IOJksoRG5vIY5k8/AEhZkGHVwbuH/d8SZ2y4HoboL7W6Q9uI9WD7NGivfzksoHdQyAxvcWadcLX/ RWoEpVGAApVNR1hPWHE78LG+yGwuoAQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sBcxz-0000000FlvM-1dxX; Mon, 27 May 2024 16:12:55 +0000 Received: from mail-yb1-xb4a.google.com ([2607:f8b0:4864:20::b4a]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sBcxw-0000000Fluj-0oas for linux-arm-kernel@lists.infradead.org; Mon, 27 May 2024 16:12:53 +0000 Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-df7721f2e70so3457416276.0 for ; Mon, 27 May 2024 09:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716826370; x=1717431170; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=ZrpiZFSlMl2FL23qspTGSEriptD5mzQ7x+Cz02y2uLI=; b=zuPlfhuSsSbJEDXZGWNG36c/m9HGuQDoUgHfSqDYPSp96M1sBekaNodMg0GHh70PNh RQK39YUQaHQbwH9FhZ75Zw4k8LXI6Z1eBQJNGnJdlCKAMGRUAXOMHdi1Cb13E3IBnyud uZM5yxSlE8WTg2++Xhi7xkbCiouE42QzHQFhdwSfpHvdragFgjYet9HZCT9wjYTMEQdz jCdveAUNucqeCQd6h0PMpP4HbJkEJyLhEdo4IYdZ/wNl0CMdY/8FRoZmLHB/ajMRtQ+B HlUT3W1AhLllFSr1Akjt/lMASMrJBd+Iq9/kUqyQzSClb1guur4k9v/Yr09HwwN+tiqI Odrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716826370; x=1717431170; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZrpiZFSlMl2FL23qspTGSEriptD5mzQ7x+Cz02y2uLI=; b=mF7D8peEZMoB/L4OBLmirqdtXXtlYWBUQlRZvSfji18pIQ/IbtP129CIvw78BTi0X3 DVh6P80gud479AOm4XToe2Ps94ifNnRwEGSRVuiWVwi9vPY1hd2TNK6ldpHXePazfsLQ Bf8uZd2YbIqsg3Hk9Tfe/9pVxUfHfv23jJTUYT+R6dvtEWMq7YyDhunaySd9qOL14u77 jb2mtcbBMMb51GGfcVAKMXB6zVB5iXw61AQxP2VjQbgK+a7LohUyDy0CNzHxRdJHp2jL dN5ZPJzxZz5qG05C9lTFDdq+ZDBqY47kWw4G5KH95Pgt7JNyU27bgPqUhLfqUddPafxi 8/zA== X-Gm-Message-State: AOJu0YyEszkLpm3WMKkKt0jhzyOd48dOSayUAGzj5RA0FTh0m9qoMf9/ NhaapXWZ0JqVjc82duXPWT4EQlQx/fWzl+T+TFabr8Ui5pT4HBs9gX+RvyrUSpzFBF14iIowamX LLWAgZAWu333yxNnf/GyMCYU/hw5mJ9Hi9gz6wORwoBwRwRZA9ZTKL/r4X2gDtVmYj1OHev5T/J gtFX+xy12W5eiDByKJH2q1BK2gPww6Kyf52+t/EZVm X-Google-Smtp-Source: AGHT+IHjwsn/WBubYyFO4jy2Xwlzq9YR/cmu4MmGD+HlUBf8/2dU2s+5pKN9swDbQwh6eHyFzmbVPoLC X-Received: from palermo.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:118a]) (user=ardb job=sendgmr) by 2002:a25:4cc4:0:b0:df4:eb0b:8fd with SMTP id 3f1490d57ef6-df54223467dmr2691707276.2.1716826369750; Mon, 27 May 2024 09:12:49 -0700 (PDT) Date: Mon, 27 May 2024 18:12:37 +0200 Mime-Version: 1.0 X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Developer-Signature: v=1; a=openpgp-sha256; l=3063; i=ardb@kernel.org; h=from:subject; bh=E+aQrRg2IEC5HsHH0lDPwztB+W0bWlU1WS9i+V/FeEo=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIS1kw1ffl482rdn90vKp1dcNticPnHo3Zb/Z/flWu69vK +G4+OFfUUcpC4MYB4OsmCKLwOy/73aenihV6zxLFmYOKxPIEAYuTgGYyIf5DP/L529a1Me1VNB4 spHco92nl7Xd+s+3TnRbhuUV71uXzBgUGf4pqPX05a5pqdknPF2kOGZ7W5NN3QsWjW8PNl71njf 3qgsTAA== X-Mailer: git-send-email 2.45.1.288.g0e0cd299f1-goog Message-ID: <20240527161236.313448-2-ardb+git@google.com> Subject: [PATCH] ARM: ftrace: Don't assume stack frames are contiguous in memory From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org Cc: arnd@arndb.de, linux@armlinux.org.uk, linus.walleij@linaro.org, Ard Biesheuvel , " =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= " , Justin Chen , Thorsten Scherer , Florian Fainelli , Doug Berger X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240527_091252_281655_62C56F21 X-CRM114-Status: GOOD ( 18.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Ard Biesheuvel The frame pointer unwinder relies on a standard layout of the stack frame, consisting of (in downward order) Calling frame: PC <---------+ LR | SP | FP | .. locals .. | Callee frame: | PC | LR | SP | FP ----------+ where after storing its previous value on the stack, FP is made to point at the location of PC in the callee stack frame. The ftrace code assumes that this activation record is pushed first, and that any stack space for locals is allocated below this. This would imply that the caller's value of SP can be obtained by adding 4 to FP (which points to PC in the calling frame). However, recent versions of GCC appear to deviate from this rule, and so the only reliable way to obtain the caller's value of SP is to read it from the activation record. Since this involves a read from memory rather than simple arithmetic, we need to use the uaccess API here which protects against inadvertent data aborts due to corruption of data on the stack. The plain uaccess API is ftrace instrumented itself, so to avoid unbounded recursion, use the __get_kernel_nofault() primitive instead. Closes: https://lore.kernel.org/all/alp44tukzo6mvcwl4ke4ehhmojrqnv6xfcdeuliybxfjfvgd3e@gpjvwj33cc76 Reported-by: Uwe Kleine-König Closes: https://lore.kernel.org/all/d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com/ Reported-by: Justin Chen Cc: Thorsten Scherer Cc: Florian Fainelli Cc: Doug Berger Signed-off-by: Ard Biesheuvel Tested-by: Thorsten Scherer Reviewed-by: Linus Walleij Tested-by: Justin Chen --- arch/arm/kernel/ftrace.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c index a0b6d1e3812f..e61591f33a6c 100644 --- a/arch/arm/kernel/ftrace.c +++ b/arch/arm/kernel/ftrace.c @@ -232,11 +232,24 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr, unsigned long old; if (unlikely(atomic_read(¤t->tracing_graph_pause))) +err_out: return; if (IS_ENABLED(CONFIG_UNWINDER_FRAME_POINTER)) { - /* FP points one word below parent's top of stack */ - frame_pointer += 4; + /* + * Usually, the stack frames are contiguous in memory but cases + * have been observed where the next stack frame does not live + * at 'frame_pointer + 4' as this code used to assume. + * + * Instead, dereference the field in the stack frame that + * stores the SP of the calling frame: to avoid unbounded + * recursion, this cannot involve any ftrace instrumented + * functions, so use the __get_kernel_nofault() primitive + * directly. + */ + __get_kernel_nofault(&frame_pointer, + (unsigned long *)(frame_pointer - 8), + unsigned long, err_out); } else { struct stackframe frame = { .fp = frame_pointer,