linux-hardening - Re: [PATCH] arm64: tegra: Enable ramoops on Tegra210 and newer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALHNRZ81AOu=3JFjrx_J5cGAe+6HLjy01AyeMfEKGrMzxNgo2A@mail.gmail.com>
Date: Thu, 31 Jul 2025 16:24:02 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jonathan Hunter <jonathanh@...dia.com>, Kees Cook <kees@...nel.org>, Tony Luck <tony.luck@...el.com>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, devicetree@...r.kernel.org, 
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH] arm64: tegra: Enable ramoops on Tegra210 and newer

On Mon, Jul 14, 2025 at 1:01 AM Aaron Kling <webgeek1234@...il.com> wrote:
>
> On Thu, Jul 3, 2025 at 2:24 AM Thierry Reding <thierry.reding@...il.com> wrote:
> >
> > On Mon, Jun 30, 2025 at 01:48:28PM -0500, Aaron Kling wrote:
> > > On Thu, May 29, 2025 at 3:53 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > > >
> > > > On 28/05/2025 19:35, Aaron Kling wrote:
> > > > >>>>
> > > > >>>> Friendly reminder to the Tegra maintainers about this question.
> > > > >>>>
> > > > >>> In lieu of a response from the Tegra subsystem maintainers, I can only
> > > > >>> hazard an assumption, Krzysztof. I presume the pstore carveout is
> > > > >>> bootloader controlled because various stages of the boot stack can
> > > > >>> dynamically allocate memory, and this became bootloader controlled to
> > > > >>> prevent any of those from overwriting pstore. I worry about hardcoding
> > > > >>> an address in the kernel dt, then finding out later that there's an
> > > > >>> in-use configuration that overwrites or corrupts that section of ram
> > > > >>> during boot. What are your thoughts on this? And is there any way for
> > > > >>> this patch to proceed?
> > > > >>
> > > > >> I haven't been able to find anything out about this yet. Generally it's
> > > > >> difficult to get the bootloaders updated for these devices. Tegra194 and
> > > > >> Tegra234 may be new enough to make an update eventually go into a
> > > > >> release, but for Tegra186 and older, I honestly wouldn't hold my
> > > > >> breath.
> > > > >>
> > > > >> Thierry
> > > > >
> > > > > Krzysztof, based on this response, is there any way or form that the
> > > > > Tegra186 part of this could be submitted? I can drop the newer
> > > > > platforms from this patch if Thierry can get a response to his other
> > > > > reply about how the bootloader could conform.
> > > > >
> > > > I don't NAK it. Eventually it is up to platform maintainer if they
> > > > accept known DTC warnings.
> > > >
> > > > Best regards,
> > > > Krzysztof
> > >
> > > If the decision is up the the tegra maintainers, then Thierry, what's
> > > your thoughts now? What is in this patch should be compatible with
> > > existing l4t and android bootloaders. But it does add a few new dtb
> > > check lines.
> >
> > I don't adding new DTC warnings, especially ones that we know up front
> > we can never get rid of. The memory one is a notable exception because
> > the system becomes unusable without it.
> >
> > ramoops is not in that same category. While it's certainly nice to have,
> > I don't think it's critical enough to warrant that permanent exception.
> > Where possible I think we need to work to address issues souch as this
> > at the root and fix bootloaders to do the right thing.
> >
> > For any cases where we can't fix the bootloaders, I think that's
> > something we have to live with. Having the support for this live in a
> > fork is a fair compromise, I think.
> >
> > I know this is frustrating, and it's very painful for me personally
> > because I initially set out to redress a lot of these things and failed
> > to do so.
> >
> > However I can't justify accepting endless amounts of quirks upstream,
> > all of which would set a bad precedent, just for the sake of things
> > being upstream.
> >
> > Thierry
>
> Alright, so to make sure everything is on the same page, let me walk
> through the archs.
>
> T210: This fits within dt check requirements afaik. If I send a v2
> with only t210, would that patch be acceptable? Though, I would like
> to double check that my assumption about the arch is correct. The
> downstream 4.9 kernel does allocations for ramoop I can't quite track
> in the vendor code. I'm assuming that by matching what the downstream
> kernel picks, that it's within a large carveout that the bootloader
> will never touch. I've not seen any corruption in my use of it so far.
> Is this a safe assumption?
>
> T186: Software support for this arch is eol, so what the bootloader
> does cannot be changed. Presumably no other choice but to relegate to
> a commit in a fork or out of tree patches.
>
> T194: Some software support still exists for this arch in L4T r35. Is
> there any positive feedback on making bootloader changes to meet dt
> check requirements, or is it too late in the cycle?
>
> T234: Still has active software support in L4T r36. But essentially
> the same question as t194.
>
> T264: I assume whatever happens for t234 will be mirrored here.

Reminder about this set of questions.

Aaron