netdev - Re: [PATCH v2] tools: bpftool: fix reading from /proc/config.gz

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: <20190805185940.786af579@cakuba.netronome.com>
Date:   Mon, 5 Aug 2019 18:59:40 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Peter Wu <peter@...ensteyn.nl>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        Stanislav Fomichev <sdf@...gle.com>,
        Quentin Monnet <quentin.monnet@...ronome.com>
Subject: Re: [PATCH v2] tools: bpftool: fix reading from /proc/config.gz

On Tue,  6 Aug 2019 02:07:02 +0100, Peter Wu wrote:
> /proc/config has never existed as far as I can see, but /proc/config.gz
> is present on Arch Linux. Execute an external gunzip program to avoid
> linking to zlib and rework the option scanning code since a pipe is not
> seekable. This also fixes a file handle leak on some error paths.

Please post the fix for the handle leak separately against the bpf tree.

> Fixes: 4567b983f78c ("tools: bpftool: add probes for kernel configuration options")

Other than the leak I'm not sure this qualifies as a bug.
Reading config.gz was consciously left to be implemented later.

> Cc: Quentin Monnet <quentin.monnet@...ronome.com>
> Signed-off-by: Peter Wu <peter@...ensteyn.nl>
> ---
>  v2: fix style (reorder vars as reverse xmas tree, rename function,
>      braces), fallback to /proc/config.gz if uname() fails.
> 
> Hi,
> 
> Although Stanislav and Jakub suggested to use zlib in v1, I have not
> implemented that yet since the current patch is quite minimal.
> 
> Using zlib instead of executing an external gzip program would like add
> another 100-150 lines. It likely requires a bigger rewrite to avoid
> getline() assuming that no temporary file is used for the uncompressed
> config. If zlib is desired, I would suggest doing it in another patch.
> 
> Thoughts?

I'd rather avoid the fork and pipe. We already implicitly link against
zlib for libelf etc.