From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DB983859E0 for ; Fri, 1 May 2026 12:23:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777638226; cv=none; b=NSATfzIuBJyKW43pX1MSfmldHnuvHPUiQW9fKqTOhKo4CE/9Hh4l+1/0SSCEtSzvwiTBYG/n3K6abIsQ/yO96L4b9TW+g+Urshh1tDlziXfUWN6OM01cP/aKl3RfPRT/45c4eVn9LvpoAwMQAe1Ndun4WHBDuZCOJ9bxdG21fMk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777638226; c=relaxed/simple; bh=hG1+nTYFaVMeBN3UfDamEXK/Fu0XaXrJJh/rhgkXCuU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=huirBr0y6w5Vbn0WOj//Fyj3T165s85LFimHlgSgPMfBpM+FD9/8uctlqaSx1v4gULPuQZy04abjJ47knZLL+Oz9H2dzwe+cMdhf4ShY+XeapOfMHeylrMae9g7zLtShNDKxXWlgVzIvmVgoW9EOrxmJpbzLqobYf6IfrPMsktA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=F+ik0Clu; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="F+ik0Clu" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488af96f6b2so24167235e9.0 for ; Fri, 01 May 2026 05:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1777638224; x=1778243024; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hG1+nTYFaVMeBN3UfDamEXK/Fu0XaXrJJh/rhgkXCuU=; b=F+ik0CluLpFSJtAndiyesuImbqllnRpEN6xqrVzpzxHZPjGATMPrrxKDH9gPHEpgIv WebNVMJfAI2ZMTRzS+cgnftNLRuD41Kjx33oHzrX5nSsi9wNFH5LFaJWfITLf1rIeiSu VBQhV2gPncFMqIP9IUkI/kvnzYyqJpZ/EzSP/ZiVgabg96Gvu2Mui8QLwKgEfY9y38Wy F81rumDONf1IWtTXgZV5suU3a1QkSPxFLeRt7S6eKvm5kM+WX6YUFW7UsxvpGXgL242K aIhz74Vxdp+hJWeIJEeZj1OCIEYTpr3j9YPhcr1qz1/7PizBKW9kz7jr3wI0gyspbVIj afew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777638224; x=1778243024; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hG1+nTYFaVMeBN3UfDamEXK/Fu0XaXrJJh/rhgkXCuU=; b=KW6kTXe6odDdeq7vBlz/sEqE9cLADIT9noQRywgtTrswLmqHzdbK/pCSeDmZ/U6rg/ SfE+NB1TxhHL3MbY5HT6k4YfPZreOM4dl+tc1gziedJXQ/P94OPt5JY41ziSLHBlW18h N9L7PEeTy1wwnhD8+/IoyBPMd/TegoCVOQ1XZTvG6miAYXAyaqYSKPDf4WHKdLvWtAcN vV83JNAKlJdFvxd6oLnxVYU+bPlwZQMDQVwKjhj8gWqV4T2wwGTSXnt+smxhDRbHZWYF +Sz63LPwFgthEx+XVNd4+E/bWdaUHaf1h/AlO38dYahvN/fHkeQLI1rkKu+TsNPEzQ7H F04Q== X-Gm-Message-State: AOJu0YwVDXN6hUy9K4VNLN8qryhx961WWF/kgznPqvSuSmMMBsiYHPwx sljJ29ZOkVwo5sJe/O+zneRrAp9eqZk14wRz92MYC5x6ucGaD76gJ7Wpu1lXZ8uDtzA= X-Gm-Gg: AeBDiet08LXBmz4MobRBiv+UUbold2caPe8uAMUR2rAQTeU+4J0gYkKVZCSM4XQv0Fm DmGGWog7ZkwW8Sg64mhqitMyq5v+mCZUym/jjwMiUaJy/HmIz8D9PAeAd6QgIns2eCDrr0pyO6n r4R/RmYwFNXqj8OxDMBrVtNQ8RYp07Z6IFgRTcINoi3mpx3m7r7Nk/OkTrU52oyxJ2WRsUk0PKH nvu6JrGtMWGy0IqeN3ZhTVpnIdoLDuVV9lROy+jIlWgGgHrtjvgWM/0hIIqsm/ZNgA8u8Xx1D9Y 1HagGWPsQBMZIrdajVGLwHc/d7TQ28NJ40cHeGlE+50CQPiU5Sr7vVwObPXxcfuAT+QRDjVKmaZ YsQbPHkxoieHnP2qLcWUlHP/SGNXyoKTpiiSoqujf1CWhXNPzGvDdxb0OWZAmIwI9rEIzVj86QK Lftiqqo6tvb3K2+KECyVuoEgkJDeGNgVN9yawnjxxhsIQ= X-Received: by 2002:a05:600c:4f47:b0:485:3cf3:1010 with SMTP id 5b1f17b1804b1-48a8eb61e38mr44018115e9.2.1777638223881; Fri, 01 May 2026 05:23:43 -0700 (PDT) Received: from [10.11.12.108] ([79.115.63.228]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-44a986aab44sm4869155f8f.29.2026.05.01.05.23.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2026 05:23:43 -0700 (PDT) Message-ID: <00f82e4b-4e1e-495d-b0bf-b6e4563cfee6@linaro.org> Date: Fri, 1 May 2026 15:23:40 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/6] firmware: samsung: acpm: Validate SRAM shared memory and queue pointers To: Krzysztof Kozlowski , Alim Akhtar Cc: linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, peter.griffin@linaro.org, andre.draszik@linaro.org, jyescas@google.com, kernel-team@android.com, stable@vger.kernel.org References: <20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad@linaro.org> <20260429-acpm-fixes-sashiko-reports-v3-4-47cf74ab09ad@linaro.org> Content-Language: en-US From: Tudor Ambarus In-Reply-To: <20260429-acpm-fixes-sashiko-reports-v3-4-47cf74ab09ad@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi everyone, After further review, I've decided to drop this specific SRAM validation patch from the upcoming v4 series. I had the typical band-aid vs. the surgery dilemma. While the intention was to protect against compromised firmware providing out-of-bounds offsets, implementing this in the probe() path turns out to be an incomplete band-aid. I identified two firmware quirks that complicate static validation during initialization: 1) Some channels seem to use absolute physical DRAM addresses instead of SRAM offsets. Mapping these against the SRAM ioremap triggers a fatal page fault if we don't explicitly fence them off. 2) Some channels are purely doorbells (mlen == 0). acpm_do_xfer() and acpm_get_rx() functions currently assume all channels have payloads and sequence numbers, meaning these channels will break at runtime if we let them pass probe. Trying to silently disable or bypass these unsupported configurations during probe() makes the code brittle and creates a false sense of security regarding bounds checking. I think the proper architectural fix is to introduce a formal acpm_request_channel() API. This will allow the driver to validate parameters at probe time, mark the unsupported channels and gracefully return -EOPNOTSUPP to client drivers, rather than hacking workarounds into the probe and runtime paths. I'll leave the broader SRAM boundary validation for a future patch series. Thanks, ta