linux-kernel - Re: [RFC] seq_buf: Export symbols to external modules

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: <87eesmwjwj.fsf@vajain21.in.ibm.com>
Date:   Fri, 17 Apr 2020 14:47:48 +0530
From:   Vaibhav Jain <vaibhav@...ux.ibm.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     linux-kernel@...r.kernel.org,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Michael Ellerman <ellerman@....ibm.com>,
        Piotr Maziarz <piotrx.maziarz@...ux.intel.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Borislav Petkov <bp@...en8.de>
Subject: Re: [RFC] seq_buf: Export symbols to external modules


Thanks for looking into this patch Steven,

Steven Rostedt <rostedt@...dmis.org> writes:

> On Thu, 16 Apr 2020 09:21:24 +0530
> Vaibhav Jain <vaibhav@...ux.ibm.com> wrote:
>
>> 'seq_buf' provides a very useful abstraction for writing to a string
>> buffer without needing to worry about it over-flowing. However even
>> though the API has been stable for couple of years now its stills not
>> exported to external modules limiting its usage.
>> 
>> Hence this patch proposes update to 'seq_buf.c' to mark all functions
>> seq_buf_X() which are part of the seq_seq API to be exported to
>> external GPL modules.
>> 
>> Earlier work:
>> There was an earlier proposal by Borislav Petkov <bp@...en8.de> to
>> export seq_buf_printf() to modules at [1], as part of his EDAC
>> patch-set "EDAC, mce_amd: Add a tracepoint for the decoded
>> error". However the proposed patch was never merged and its fate is
>> unknown as I couldn't locate any subsequent discussion as to why patch
>> in [1] was dropped.
>> 
>> References:
>> [1]: https://lore.kernel.org/lkml/20170825102411.8682-5-bp@alien8.de/
>> [2]: https://lore.kernel.org/lkml/20170825092757.434f1eda@gandalf.local.home/
>> 
>> Cc: Steven Rostedt <rostedt@...dmis.org>
>> Cc: Piotr Maziarz <piotrx.maziarz@...ux.intel.com>
>> Cc: Cezary Rojewski <cezary.rojewski@...el.com>
>> Cc: Borislav Petkov <bp@...en8.de>
>> Signed-off-by: Vaibhav Jain <vaibhav@...ux.ibm.com>
>> ---
>>  lib/seq_buf.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>> 
>>
>
> I'm perfectly fine with this change, but recently there's been a lot of
> discussion about doing something like this for out-of-tree modules. Is
> there going to be a use case for in tree modules for this? It will make the
> case much easier to get this accepted.

Having these symbols exported to modules should simplify generating file
content for pseudo file systems like sysfs or procfs. Many of the in
kernel modules export atleast one such attribute file. Using seq_buf
api provides a safe way to populate the read buffers for these attrs
as these string buffers are PAGE_SIZE in length and a buggy module can
easily cause an overflow.

My specific use-case is exporting a set of nvdimm specific flags from
papr_scm kernel module [1] via sysfs through a patch proposed at [2] and
using seq_buf should considerably simply my code as suggested by Mpe
at [3].

[1] arch/powerpc/platforms/pseries/papr_scm.c
[2] https://lore.kernel.org/linux-nvdimm/20200331143229.306718-2-vaibhav@linux.ibm.com
[3] https://lore.kernel.org/linux-nvdimm/878sjetcis.fsf@mpe.ellerman.id.au

>
> -- Steve

-- 
Vaibhav