From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 3A9322E406 for ; Tue, 21 Jan 2025 13:12:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737465165; cv=none; b=lHPEtGdRCvYKH4GdQ3jPbLIG7DLgzUGQScUoZyw1uhFk9jjYnSnk824t7uaCNcpzNZu4h8BXY0Gw+M6v1mWHg8Hrdv2qfnbKb7LnO6ItPKHzmJHQZGf6q/iokP1E3PjlIlwqDFq390BLKNfuNqsc8rNFjt7b+Ywg+zEjkyc9QLU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737465165; c=relaxed/simple; bh=NAIeDNWBPAUV4s2hD2YhjTqYmw23E7vHz0ySOuJHVI8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WM01hmNQUrWzL8gTyzSiEP6RtTbx0jR2UKo6BbDp3Q+Sim+1V7C1fLjDbwKfuq6WbUQANhU/YjxC31h/IRFuf3ipjuPlldxPLqF1bIVjcGIN769ANUh9PdGdREI0AF6Y+zcYi4CCjz7lJ0pOk7Z+GbFCFTvA41idgQZtqvFCER0= 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=JKVNoAAG; arc=none smtp.client-ip=209.85.221.46 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="JKVNoAAG" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-3862d6d5765so3189574f8f.3 for ; Tue, 21 Jan 2025 05:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1737465161; x=1738069961; 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=s2x1boRC7Td3/KtEDErRciKOCKj4bZ9FvBbMmDACL5I=; b=JKVNoAAGzkg4HxjC86jel9/jqpGvJGta9XPkA+Yb6fKA2gE0aXgxIYhrt2aB1rsMik GMKMUXVfigcVr60xNtmYSPE5WGLBtRkY6035TKJoe1Y2psqBAvPhFbqYEfqU7SpqR54D mZdvezQoHYpoRd/9/DJCD7FGfObyGr90lM/qJ3/76VZinttNVLg/XMlcLIO8F6/DxhZo dfh4zfg5GpeBrBd5+Rj432jKOdKs0SZyQUWSkgyMRza99mGyWVyuZmfwOifU+OcUiErM 34cO5Svxp8NUhM0HdAffmFaQ94cFtzKFDoorB22UEbs2a6e4zXP0jeRhOhEvM3b93Fsp MFDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737465161; x=1738069961; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s2x1boRC7Td3/KtEDErRciKOCKj4bZ9FvBbMmDACL5I=; b=C6gEpTLg0dt1kFiIgfjHWTi1nAch12RNedEdotU+mpFDT6z6ZcO3DnFUOBFavpiQPj QTQS71c9Zg9Li2kcNmNshcBO8CSbMvPEWOz+a7Vd4xLZBHWKc1Byyz5MQNnNM1jCaEJe H9+mSQh9DdSdwGI6iagH7Kaa3K3jGYVxDFm8eGAhJra1L94dVDosYukDp9OadquZD2yu zFo/dac7lIcrpC0xncFzedRB2GPvCGenFdCi/1qjkGjBlfGUE4loCYxzC7e6qEdYiXOO v+0ppv5XipAo7OvS00tM18c10KLdVqG9XI/mY+JKtYbcmHIWZR7zwbg9q0ITymaLw1sY aHvA== X-Forwarded-Encrypted: i=1; AJvYcCXaOfbiajLCjV4VxBHzjKudzhImpCJ97FCe6MVz4Vp0LEEyda0mdHoVsQM3sb6myFCNvlloVkT6zMKR3WM=@vger.kernel.org X-Gm-Message-State: AOJu0Yx9dygOKIXGUwcRnl6OBjtQJE5HSKxkRv/rDs4rtk1HK4fd5wwT BUFaf7D5/cpEb3WB8EarhOatAvw6jjBwGrdpWFxaFEF01O5X6cgkqHHIDaknAVA= X-Gm-Gg: ASbGncu2dV73uZeL7sjXdN9h6KsBDRnCenK9h5dlnyuIqUgNwNErlTBVUO5B+NytB0M MTmlCVkwXI607gLsfvz52frgGq2aRoyD7kLgxcASHuVkHk1+UYtLLSuNqjnIuUc9fUuM5H1aWDs qHUqsKvmx6KC9vwJLXdc6rKfOMLeDa6025ROdVNKa4Ay41DZ/GYXINFgq2vswYCzec7v6Z6S7Ch 17XwJ6COYkhGZxcaxgy9kd1y3b9e0nNjSf4/qha7pMt5QDgWHRdzdU5oJMMwkl4v2w1I2jilV5U Bg== X-Google-Smtp-Source: AGHT+IFdpFJJy8M5KC3Tmd+NcjbDB60676AM8tQG4Ka5vOs+QjGJbreqWkLYn0gnkKmNKPe9eyz+tA== X-Received: by 2002:a5d:5f51:0:b0:38a:624b:e619 with SMTP id ffacd0b85a97d-38bf59e2019mr18759407f8f.43.1737465161465; Tue, 21 Jan 2025 05:12:41 -0800 (PST) Received: from [192.168.0.24] ([82.76.24.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c7527fd1sm241546295e9.31.2025.01.21.05.12.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2025 05:12:41 -0800 (PST) Message-ID: Date: Tue, 21 Jan 2025 15:12:39 +0200 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: RFC design of device coredump collection on panic in Pstore To: Kees Cook , Mukesh Ojha Cc: gregkh@linuxfoundation.org, tony.luck@intel.com, gpiccoli@igalia.com, johannes@sipsolutions.net, rafael@kernel.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, quic_shashim@quicinc.com, quic_pkondeti@quicinc.com References: <1683561060-2197-1-git-send-email-quic_mojha@quicinc.com> <202305161353.0F771E0@keescook> Content-Language: en-US From: Eugen Hristev In-Reply-To: <202305161353.0F771E0@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/16/23 23:55, Kees Cook wrote: > On Mon, May 08, 2023 at 09:21:00PM +0530, Mukesh Ojha wrote: >> 1. Device_coredump allocates some configurable contigous memory that can be controlled >> via CONFIG or bootargs and later registers for panic notifiers. >> 2. Notifier gets added. >> 3. Pstore adds device_coredump as its front-end via dumper registration similar >> to kmsg being dump today. >> 4. Successful registration of dumper. >> 5. A device driver(A-Z) can register their buffer to be dumped as part of panic. >> 6. buffer gets added to the dump list. >> 7. Panic occurs. >> 8. iterate over registered drivers and copy their dump list to its own memory and if >> it crosses device core dump memory log an error stop iterating. >> 9. Similar to devcore_dump() inline with kmsg_dump() >> 10.Copy the content to pstore region and this could be elf or raw binary that can be >> discussed. > > Yeah, I think having something like the panic dump handlers for > driver-specific data sounds like a fine idea (as long as we have actual > users of such an interface). > > I think it would be easy to add another front-end to pstore (via the > enums, etc), and expose it via a new template filename in the pstorefs. > Hello Kees, Currently I am working to get a similar design on Pstore as described by Mukesh, with some differences. I want to be able to register memory areas into Pstore, not by doing a copy, just by registering via a new API (as a frontend, area pointer and size). Further, these memory areas would be registered to a new type of zone inside pstore/zone called directly mapped zone, and then registered to any kind of backend that would support it. The backend would then decide what to do with the memory area, have it ready in a list for a panic case, hangup, or hardware fault; or something else. This implementation would avoid memory copy operations, memory reservations, and dependency to a panic handler being run. It would work in multiple scenarios, not just when the kernel is being able to run a panic handler. Further, the data can be extracted either by JTAG, firmware, remote processor or any other solution, including dedicated storage, shared memory. One could then use it to construct a coredump or specific dump information. Having different memory areas being registered has the advantage of being flexible and small, ranging from nothing to a full kernel memory range. What do you think about this approach ? Do you see it working like this ? Thank you for your suggestions, Eugen