linux-kernel - 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] [day] [month] [year] [list]

Message-ID: <CALHNRZ9VEUzU07j_fUWhNnF24y64wkO5_Vun-mf6d_m=Xyx4dA@mail.gmail.com>
Date: Mon, 14 Jul 2025 01:01:19 -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 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.

Aaron