From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 6CBB12F6578 for ; Wed, 26 Nov 2025 10:57:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764154648; cv=none; b=VdMUZqALDvmCKTbasaDhwPs7tmPgHJBvM1e+6aS6+LUKrfqOZDtiS1DE4kDH+FAMb654CNRgiizISdYRb8Yzihdi62nm77CYNPxnoPCk9x99esyzh0XsAO+Dnm4N1/BpPecOdd2yqdnOT/S7l9CS261SgCLkxvQ3PKC+4PdDD1k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764154648; c=relaxed/simple; bh=Hwcf/bmTEk/eEfJK5jdQBNc4qNh8JrjuhRwVgGM4WiI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L8U8lseWnTVMqQHZd3hkauOA8PBjNOh/FiCHf/9gBq9nS8KBWNUqSG1wbVyUX0JaeZH8WfefpXLMdxC4T03uSS70+4ulvw2YpKmKAwyLE/4XH1a3BwfKDVBFoCQVeoS7c+AfSji9X1PuIhrNOXdm+CiniJCky0G5qKbBX+ewXC0= 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=R0i/4W0m; arc=none smtp.client-ip=209.85.128.42 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="R0i/4W0m" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so54076405e9.1 for ; Wed, 26 Nov 2025 02:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1764154645; x=1764759445; 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=xqXD5UxhVl/qedWfuQJ1mScY0sYX8Bi2EGwWdCnH12o=; b=R0i/4W0mM/bPjV8KW0O2OZtQJtmkipNn1oY1UurCi5NgcHFgxxSVsEVsm8USgT0PoD wVUowDKpNOWR3gDk0uxfOvm7+BEdgp7OMWsmOt5Xj7rIVlEq602/6vFHT/UAYgPd5yK/ VzxdiNhkZQrexT4hoBdbXyH1LRf58uFs7Iwqpy4AJrUe5ADVQV3RgBHzl41G9Qbljjm5 PaX58ccD6O7FqPAN9SQM7nKT5ets++gT5WNeawNIg7M9TDj1VUlnRzwW1M87+7WWFHMY FDS+jWdc8VGj/WXJtEuiFmsGWbonT5Bc/xlvxcmYFhnqoLfz09fPvrdYQTEKfR8FkYub gKCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764154645; x=1764759445; 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=xqXD5UxhVl/qedWfuQJ1mScY0sYX8Bi2EGwWdCnH12o=; b=hx21lWP7gDe0CFwpHXehWoomq51CW56gC5XxpD64X+sU9/5OFylowilDH1jCxvxtHK fFdp3lfgwMDuW0bh4T8wMOYNtFQA5EI7StRWU1McXmqASsPBOPx2u6O/o8ifvOPc3jRu aZhMCkmh7iqngsx1n6xp7DQLcwUVQzT3X0x7viu98ZVbXB7o4DzRHzCgwy+dkBg6HM+R i85/TRAoks5NU6KnRFSJSAbqnG+To/Ks7DmllCqqdv69VV5kxf1iqeaDB/a181jSA1nw enMNA7Yst5zkfLw+d2UVYZMfG/NaicKr5sKyO7IqjYPFiirjcCjuIZZr/4LwePrRakm8 y+6g== X-Forwarded-Encrypted: i=1; AJvYcCXCG5yJosywbuHEUKN5RCHZaPFAOIxSp1Q1XuZXHYoT2l55lSViLGCRbJIJjRSmovAmhTG16CtupK7rXuY=@vger.kernel.org X-Gm-Message-State: AOJu0YyNqiSmKYhBiMdzPM5u6oi6V9ULeRr20ryInzTC8y2xPTm3GxIT 4vvl0SWjDAv0HvCRgx6gcly7Yuik37v+DG5atCW43W7/vb4G2fVHA7cPaljgyhLnpwJcHU/KoeB I0DdIFmE= X-Gm-Gg: ASbGncu0PGeK4wtS9HwJ9s68Gp/9ZfcrLrbYzzNKeL3NWnIWUa54roq2gst03Jkm5GP TQ4wj7EeFJ4d+eZq9rqJEzP098aFWKInvdKDt/iDZij7M3Q5nE2058sIGobrooYUskey8hAE3Qs K4Dbm6X73cWtuqnt7c9s+zcMG7e+3hih0N4PaYWxrmT4PnASzCj/7pc6N7EDyUtu4LsuGWK6a9F Zb99XvbM6BesqRppXrGi3ytQOOziM3IX+33Dni8rjPMFR9I1M/fBO3m/dZn3p4SmvMpbJTunJs5 fEybq8z+Ow/w0vJ3P2oB1S+qTFons0gM2ZRGSibXZps8s0yc8Mxl3UtSRj+tPf88fbg+Rhw2fPm 3M1ClAnuW7V7Vy2yBruK6siG5Vxl0RhdGS/tNFzBPk7ZORJ4dsy8+n0xIYVgd4LZo682v0c0aRT LpY2vBQw3G52KSkA6j X-Google-Smtp-Source: AGHT+IGJVYWCYJ3S88DHqP10Kg/CMuGOigEQvkZH1FXVwz7BCvehg53dPZp4WCChCiUbgB2T2w+dGg== X-Received: by 2002:a05:600c:19c6:b0:477:7975:30ea with SMTP id 5b1f17b1804b1-47904b25e46mr56780175e9.29.1764154644604; Wed, 26 Nov 2025 02:57:24 -0800 (PST) Received: from [192.168.1.3] ([185.48.77.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4790adf5387sm35802845e9.12.2025.11.26.02.57.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Nov 2025 02:57:24 -0800 (PST) Message-ID: <68efd5a2-3b65-4f37-9bf0-40c4e5ade480@linaro.org> Date: Wed, 26 Nov 2025 10:57:23 +0000 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] coresight: etm3x: Fix buffer overwrite in cntr_val_show() To: Mike Leach Cc: Kuan-Wei Chiu , suzuki.poulose@arm.com, alexander.shishkin@linux.intel.com, pratikp@codeaurora.org, mathieu.poirier@linaro.org, gregkh@linuxfoundation.org, jserv@ccns.ncku.edu.tw, marscheng@google.com, ericchancf@google.com, milesjiang@google.com, nickpan@google.com, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20251121002350.1166758-1-visitorckw@gmail.com> <172ca2d9-4a6f-4498-bdfd-8aa7428581ce@linaro.org> <05babb6d-a588-49f8-a34a-c82d5f58adf5@linaro.org> Content-Language: en-US From: James Clark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 26/11/2025 10:49 am, Mike Leach wrote: > Hi, > > On Mon, 24 Nov 2025 at 16:12, James Clark wrote: >> >> >> >> On 21/11/2025 5:02 pm, Kuan-Wei Chiu wrote: >>> Hi James, >>> >>> On Fri, Nov 21, 2025 at 09:50:03AM +0000, James Clark wrote: >>>> >>>> >>>> On 21/11/2025 12:23 am, Kuan-Wei Chiu wrote: >>>>> The cntr_val_show() function is meant to display the values of all >>>>> available counters. However, the sprintf() call inside the loop was >>>>> always writing to the beginning of the buffer, causing the output of >>>>> previous iterations to be overwritten. As a result, only the value of >>>>> the last counter was actually returned to the user. >>>>> >>>>> Fix this by using the return value of sprintf() to calculate the >>>>> correct offset into the buffer for the next write, ensuring that all >>>>> counter values are appended sequentially. >>>>> >>>>> Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver") >>>>> Signed-off-by: Kuan-Wei Chiu >>>>> --- >>>>> Build tested only. I do not have the hardware to run the etm3x driver, >>>>> so I would be grateful if someone could verify this on actual hardware. >>>>> >>>>> I noticed this issue while browsing the coresight code after attending >>>>> a technical talk on the subject. This code dates back to the initial >>>>> driver submission over 10 years ago, so I was surprised it hadn't been >>>>> caught earlier. Although I cannot perform runtime testing, the logic >>>>> error seems obvious to me, so I still decided to submit this patch. >>>> >>>> Nice find. I think the point that it wasn't caught changes how we fix it. >>>> Either nobody used it ever - so we can just delete it. Or someone was using >>>> it and they expect it to always return a single entry with the value of the >>>> last counter and this is a potentially breaking change. So maybe instead of >>>> fixing this we should add a new cntr_vals_show() which works correctly. But >>>> then again if nobody is using it we shouldn't do that either. >>> >>> Thanks for your feedback. >>> >>> I agree that if any tool relies on the current behavior, this patch >>> would break the ABI and violate the hard rule that we must never break >>> userspace. >>> >>> However, I am not sure how to determine if any userspace tools are >>> actually using this sysfs interface. Is there a recommended way to >>> verify this, or a standard procedure/convention to follow in this >>> situation? >>> >>> Regards, >>> Kuan-Wei >>> >> >> There's no way of knowing apart from deducing that there are 0 users of >> the 'correct' version of the API because it never existed. This isn't >> even a regression, it was broken from the beginning. >> >> I suppose it does work when hardware only has one counter, but I don't >> know how likely that is? >> >> Looking at cntr_val_store() I think I was wrong before when I said it >> should be a separate file for each counter. Writing to it already writes >> to the counter currently selected by cntr_idx and splitting it out to >> separate files would have to break that too. So we can fix the display >> bug by making show operate on the currently selected counter in the same >> way as store. Then it makes a bit more sense and we can delete the >> "counter %d: " prefix. >> >> ETM4 already does it this way too. >> > I agree with this. > > The difficulty in having a file per counter is that different > implementations have different numbers of counters. Rather than > complicate the driver by dynamically generating the sysfs files, the It wouldn't be that hard because there is a maximum number of counters. You'd generate them all and then use the is_visible() thing to hide ones that didn't exist on that device. But it looks like we don't want to do it that way for other reasons anyway. > single file + selector paradigm makes things easier. The index is > validated against the actual number of counters for this instance, and > read/write occurs for the selected one. > > Regards > > Mike > >>>> >>>> The interface isn't even that great, it should be a separate file per >>>> counter. You don't want to be parsing strings and colons to try to read a >>>> single value, especially in C. Separate files allows you to read it directly >>>> without any hassle. >>>> >>>>> >>>>> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>>>> index 762109307b86..312033e74b7a 100644 >>>>> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>>>> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c >>>>> @@ -725,7 +725,7 @@ static ssize_t cntr_val_show(struct device *dev, >>>>> if (!coresight_get_mode(drvdata->csdev)) { >>>>> spin_lock(&drvdata->spinlock); >>>>> for (i = 0; i < drvdata->nr_cntr; i++) >>>>> - ret += sprintf(buf, "counter %d: %x\n", >>>>> + ret += sprintf(buf + ret, "counter %d: %x\n", >>>>> i, config->cntr_val[i]); >>>>> spin_unlock(&drvdata->spinlock); >>>>> return ret; >>>>> @@ -733,7 +733,7 @@ static ssize_t cntr_val_show(struct device *dev, >>>>> for (i = 0; i < drvdata->nr_cntr; i++) { >>>>> val = etm_readl(drvdata, ETMCNTVRn(i)); >>>>> - ret += sprintf(buf, "counter %d: %x\n", i, val); >>>>> + ret += sprintf(buf + ret, "counter %d: %x\n", i, val); >>>>> } >>>>> return ret; >>>> >> > >