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: <CALHNRZ8=ikQe4L6h9VHpTGm+OFU0iZA_OV6LUP6jDUySBv4+Lg@mail.gmail.com>
Date: Mon, 30 Jun 2025 13:48:28 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Thierry Reding <thierry.reding@...il.com>, 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, 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.

Aaron

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ