linux-kernel - Re: [PATCH v7 03/25] kallsyms: increase maximum kernel symbol length to 512

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: <459385ee7ccf4fcf3e22d4a11b4f438d648422bf.camel@kernel.org>
Date:   Fri, 27 May 2022 19:25:57 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        David Howells <dhowells@...hat.com>
Cc:     Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Petr Mladek <pmladek@...e.com>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Gary Guo <gary@...yguo.net>, Boqun Feng <boqun.feng@...il.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        live-patching@...r.kernel.org, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v7 03/25] kallsyms: increase maximum kernel symbol
 length to 512

On Tue, 2022-05-24 at 20:07 +0200, Miguel Ojeda wrote:
> On Mon, May 23, 2022 at 10:33 PM Jarkko Sakkinen <jarkko@...nel.org> wrote:
> > 
> > There's no description what the patch does.
> 
> I am not sure what you mean. Both the subject and the last paragraph
> describe what the patch does, while the rest gives the rationale
> behind it.
> 
> Cheers,
> Miguel

The honest answer: I don't actually remember what I was thinking 
(other stuff stole my focus) but my comment neither makes much
sense to me. Please just ignore it, and apologies for causing
confusion.

There's something I'm looking into in my spare time right now.
I'm experimenting with interfacing keyring types to Rust. The
first step, I guess, is to provide a Rust abstraction for
assoc_array.

I've skimmed through the patch set and have now *rough* idea of
patterns and techniques. My opens are more on the process side
of things since there's no yet mainline subtree.

If I send a patch or patch sets, would this be a good workflow:

1. RFC tag.
2. In the cover letter denote the patch set version, which was
   used the baseline.

Linux keyring is without argument a kind of subsystem that would
hugely benefit of the Rust work, as it is both user space facing 
nd handling a vast amount of user's confidential data. 

BR, Jarkko