linux-hardening - Re: [PATCH v3 2/2] pstore/ramoops: Add ramoops.mem

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: <CB84A272-24F0-4526-8474-0D0CD5C5E27C@kernel.org>
Date: Thu, 13 Jun 2024 07:42:01 -0700
From: Kees Cook <kees@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>, Steven Rostedt <rostedt@...dmis.org>
CC: Mike Rapoport <rppt@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Vlastimil Babka <vbabka@...e.cz>, Lorenzo Stoakes <lstoakes@...il.com>,
 linux-mm@...ck.org, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
 Tony Luck <tony.luck@...el.com>,
 "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
 linux-hardening@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>,
 Ross Zwisler <zwisler@...gle.com>, wklin@...gle.com,
 Vineeth Remanan Pillai <vineeth@...byteword.org>,
 Joel Fernandes <joel@...lfernandes.org>,
 Suleiman Souhlal <suleiman@...gle.com>,
 Linus Torvalds <torvalds@...uxfoundation.org>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v3 2/2] pstore/ramoops: Add ramoops.mem_name= command line option

On June 13, 2024 7:06:47 AM PDT, Ard Biesheuvel <ardb@...nel.org> wrote:
>On Thu, 13 Jun 2024 at 15:26, Steven Rostedt <rostedt@...dmis.org> wrote:
>>
>> On Thu, 13 Jun 2024 08:11:48 +0200
>> Ard Biesheuvel <ardb@...nel.org> wrote:
>> > >
>> > > I've added one more comment to v5, with that fixed I can take this.
>> > >
>> >
>> > So how is this supposed to work wrt to the rigid 'no user visible
>> > regressions' rule, given that this whole thing is a best effort thing
>>
>> This has nothing to do with user space. The kernel command line has
>> broken in the past. If you update the kernel, you can update the
>> command line. There's no "no user visible regressions" rule. It's
>> "Don't break user space". This has nothing to do with user space.
>>
>> > to begin with. This needs at least a huge disclaimer that this rule
>> > does not apply, and if this works today, there is no guarantee that it
>> > will keep working on newer kernels. Otherwise, you will be making the
>> > job of the people who work on the boot code significantly more
>> > difficult. And even then, I wonder whether Linus and #regzcop are
>> > going to honour such a disclaimer.
>>
>> Again, this has nothing to do with user space. The rule Linus talks
>> about is breaking user space. This is about kernel debugging. Something
>> *completely different*!
>>
>> >
>> > So this belongs downstream, unless some guarantees can be provided
>> > that this functionality is exempt from the usual regression policies.
>>
>> I disagree. kexec/kdump also has the same issues.
>>
>
>Fair enough. As long as it is documented that there is no guarantee
>that this will keep working over a kernel upgrade, then I have no
>objections.

Yeah, I should better document this for pstore as a whole, but I've already made the call that cross-kernel-versison operation is best effort.

-Kees

-- 
Kees Cook