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  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]
Date:   Wed, 6 Mar 2019 15:35:05 -0800
From:   "H. Peter Anvin" <>
To:     Pavel Machek <>,
        Joel Fernandes <>
        Andrew Morton <>,,, Borislav Petkov <>,,,
        Ingo Molnar <>, Jan Kara <>,
        Jonathan Corbet <>,,
        Kees Cook <>,,, Manoj Rao <>,
        Masahiro Yamada <>,,
        "Peter Zijlstra (Intel)" <>,,,
        Thomas Gleixner <>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <>,
Subject: Re: [RFC] Provide in-kernel headers for making it easy to extend the

On 3/6/19 3:09 PM, Pavel Machek wrote:
> On Fri 2019-01-18 17:55:43, Joel Fernandes wrote:
>> From: "Joel Fernandes (Google)" <>
>> Introduce in-kernel headers and other artifacts which are made available
>> as an archive through proc (/proc/kheaders.tgz file). This archive makes
>> it possible to build kernel modules, run eBPF programs, and other
>> tracing programs that need to extend the kernel for tracing purposes
>> without any dependency on the file system having headers and build
>> artifacts.
>> On Android and embedded systems, it is common to switch kernels but not
>> have kernel headers available on the file system. Raw kernel headers
>> also cannot be copied into the filesystem like they can be on other
>> distros, due to licensing and other issues. There's no linux-headers
> If your licensing prevents you from having headers on the
> filesystem... then I guess you should fix the licensing.
> I agree with Christoph, this looks pretty horrible.
> 									Pavel

The argument that "it can be a module" is basically an admission of
failure - if it isn't part of the kernel image itself there is no
benefit over where the modules are stored, which will be *somewhere* in
the filesystem.

What I *do* think makes sense is to create an archive with this
information and stuff it in the same place as the modules. It reduces
the amount it is possible to muck it up.


Powered by blists - more mailing lists