From mboxrd@z Thu Jan 1 00:00:00 1970 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 A303CC61DA4 for ; Thu, 23 Feb 2023 19:44:28 +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:In-Reply-To:MIME-Version:References: Subject:Cc:To:From:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=59im6gnPoJizlCm21Gbjue9thsftD1KF/mjgP7OBkdY=; b=I1UpnOnxOgF8UR MSyVrY4itRhcfNON+M6jje25OIq52XuFr5GLcdQh3ZciUkz/OWXUllUejjBfpMjwK2DwRnKBVTCkR DdTcTUZ5zqtF7NndfELfYF4nIxRiDBvL8WpOfn8BILZHbIKc0QhrqlgfodME0YcMffuxqg0axXTRd tnf7/Es56lTUF4asKFBR7MLEI5H3WuJbxOuKVbpythvOn1+AXQOElVgHWcEhhmvEK9mvACtmIXHhy g4IRP9pmfBN0+dB9Bp/RtEwsh5uaXzIXMZLiDbbhH+rnhx8DO1gzKHa95KWyXHMKH/kCuwxJAFgHL 8kAqG+mg3e70AkuQho0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVHV9-0008JE-7P; Thu, 23 Feb 2023 19:43:35 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVHV5-0008F7-Np for linux-arm-kernel@lists.infradead.org; Thu, 23 Feb 2023 19:43:33 +0000 Received: by mail-pj1-x1029.google.com with SMTP id u10so14199679pjc.5 for ; Thu, 23 Feb 2023 11:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=LjnO9LX2oaudWt6rcbd+l5z7VPXLNIdPSojjdZ3yYwY=; b=hiuStAIwYFXYL421s/3Lu/eOuoTSSlsQBwaCgifpmsZg6YhziKooeTzsZenHIOHT+I 314pOCAXOA2sfpZ/KQI3DoDZs5Cu6ZyyWzg0Tv7bGySCcvd0+owffRaZwi/mRsXbLhBG 1RokLHwoxZHNcxvJqODrJP0OpFr7Sx2dogisA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LjnO9LX2oaudWt6rcbd+l5z7VPXLNIdPSojjdZ3yYwY=; b=Npr0Wx3xN6t0g9ITx0EHZ7qWJA1kJt+6G4Kly8fslGSg3ognZBqGHMhWE1BtgXCox3 TwaKVxhtQ21y+EfnEMOYoHyJIGBcdTeVcySo/c2jl36s99sUt8u4dO2LSLV+w49qN31H j9sO8Yu3UkU4wCO2ppx+3GYvJup7WMZ9KP5IeOEStDRE1Cxy0N4V1pw9RKd3G2hGQzi9 LMf3MZKTnMGksz4ZDwPZFIE2gMksdRSbJ86+4tiSeqrjTn/2KC8EKwKBzRPLd+8sLr0d X7IBgqiskV3PMs0m4Dfen8ddUaCqrIe05ohT6Q7qSZcd0VJ1tOjQurQBgKytkhrxHRF8 jpWg== X-Gm-Message-State: AO0yUKUKjsYdA8xhZ5MprTSMbUJdqu6NHIhrUfubmWya4/EpsHsbmnVj NPGR2rsV9O1yWwe98pIiX+8Reg== X-Google-Smtp-Source: AK7set+TL9Ckjp+vyRH438uqoixtcPKXpe+lB8xFoGl83ryXnOWzsjiRVgjs0r/TRLnZz4KSDGKWBQ== X-Received: by 2002:a17:902:e890:b0:199:2a4f:be84 with SMTP id w16-20020a170902e89000b001992a4fbe84mr18564844plg.58.1677181407313; Thu, 23 Feb 2023 11:43:27 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id d5-20020a170902c18500b00198e12c499dsm7194331pld.282.2023.02.23.11.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 11:43:26 -0800 (PST) Message-ID: <63f7c1de.170a0220.f48b.e137@mx.google.com> X-Google-Original-Message-ID: <202302231120.@keescook> Date: Thu, 23 Feb 2023 11:43:26 -0800 From: Kees Cook To: Mukesh Ojha Cc: agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org, tony.luck@intel.com, gpiccoli@igalia.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 6/6] pstore/ram: Register context with minidump References: <1676978713-7394-1-git-send-email-quic_mojha@quicinc.com> <1676978713-7394-7-git-send-email-quic_mojha@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1676978713-7394-7-git-send-email-quic_mojha@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230223_114331_836017_E0424E85 X-CRM114-Status: GOOD ( 14.82 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 21, 2023 at 04:55:13PM +0530, Mukesh Ojha wrote: > There are system which does not uses pstore directly but > may have the interest in the context saved by pstore. > Register pstore regions with minidump so that it get > dumped on minidump collection. Okay, so, this is a really interesting case -- it's a RAM backend that is already found on a system by pstore via device tree, but there is _another_ RAM overlay (minidump) that would like to know more about how the pstore ram backend carves up the memory regions so it can examine them itself too. (i.e. it's another "interface" like the pstorefs.) So we need to provide the mapping back to the overlay. It feels to me like the logic for this needs to live in the minidump driver itself (rather than in the pstore RAM backend). Specifically, it wants to know about all the operational frontends (dmesg, console, ftrace, pmsg) with their virt & phys addresses and size. The frontends are defined via enum pstore_type_id, and the other values are "normal" types, so it should be possible to move this logic into minidump instead, leaving a simpler callback. Perhaps something like: void pstore_region_defined(enum pstore_type_id, void *virt, phys_addr_t phys, size_t size); How the pstore ram backend should know to call this, though, I'm struggling to find a sensible way. How can it determine if the device tree region is actually contained by a minidump overlay? -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel