Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp5738423imb; Fri, 8 Mar 2019 00:54:15 -0800 (PST) X-Google-Smtp-Source: APXvYqxL4JUPdq3l3jQlR72/k3YPP1JGEWDzSdGJYwgFlvicc3kgd8P+HYBTHBOxocbMNFwIpSA9 X-Received: by 2002:a63:cf01:: with SMTP id j1mr15641758pgg.342.1552035255344; Fri, 08 Mar 2019 00:54:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552035255; cv=none; d=google.com; s=arc-20160816; b=OvaBVEQOKrZvJZ2y9fxcaS4kWhVPD4Lk/7Ku6ASZOc23rL+NCCH89XVEvQS5XHiNDI zyZiCYNSJPPtPLaQuYumLrCtal4DUrrSc3eDi/2Y7GJM0TEB5jjGYGu/otsTATpj3MJh 2U0C9v9qZ37s7q8y5TLNzMmVNwJbyumJNWFZC2dlBLpIVTw6Tbyzyuckzu4KjJrgUapY OZUg4rj1LihE9h7HfSO6F0xNiRQZ7I6H4X94cEefiWEuSCiu/snuiPjiWqJ1KfXVHCYY GzZkCK6Y0EJKZUkMyXKS5pwzB9u5/5e3CJndZjfkWc4572hJgV2RregnCMWaPXROzGjw k8zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=Epzvyc9GGSP7cfqVVNfvz4S/KW5UlhBXOeZbYred4hw=; b=ggStvhPQ6xJAGVkxxiFwDfg6JpqDyzPT6KvMEv55BV6VCGUjtTffeO1JZz8isO75Jq vzCxGvX2uCUwO9CzI/XYCY3Yj3XwiGBr2ZS8EeIy/BHXNVQDthfhwgxft+cwKFND4K6+ dcKlnPqYeT0WSQIt4V5qQ5cYkuenv38Zb1Fo94Jm8+0p77LJDBJOO75D4C6GzEds5B8z GgDTn5GV90+HJbQfGttBo943sJ+pPk9zn/emBvqjWQmwHkSSPem/yZipJtvzpPcF1DAW qmlcVbIy7HqSGWzloOyxD66NM/iwVme1lF2TXPL/jNIP1ZMHzJMOjqDuo9xjlZGyPALA SgYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t19si3945141pgu.272.2019.03.08.00.53.59; Fri, 08 Mar 2019 00:54:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726418AbfCHIxa (ORCPT + 99 others); Fri, 8 Mar 2019 03:53:30 -0500 Received: from mail-ua1-f67.google.com ([209.85.222.67]:46699 "EHLO mail-ua1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726238AbfCHIxV (ORCPT ); Fri, 8 Mar 2019 03:53:21 -0500 Received: by mail-ua1-f67.google.com with SMTP id j8so11148898uae.13; Fri, 08 Mar 2019 00:53:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Epzvyc9GGSP7cfqVVNfvz4S/KW5UlhBXOeZbYred4hw=; b=s1Yn6trgpLNxnMgCyP+Z030k1bFjedhlFDi2z6E6cw+g6iD8rvWMYf9/ilw6og+Tis jUgzSHf/j8Iw+D8aosrJaNz0h2+dlru6UzDB1nX2mI6Dp7tN17GzU+WvRt5srItlUbz6 XoqSFuCqWx/5beplAz10Vau14WklJtc+w5DEem21YmXSLl5ZUpzmCya4Z7ZFXGptMbQO Ts8FGgDYf7JoTDRGdic8cVMILXC3ka1rGNw/t5lgHHIimWUYqCHzqo0U4e+4pcLUqka+ 3Vwg9FEJQrcQ83+AyzfYgfJFoC8Y9N/gdt7Z/xkQQVVOUlOa/mo1ZVLx3Ffp2aYudcif Ob5g== X-Gm-Message-State: APjAAAVgqHidXtZtxgG+ga/FJYwY5sRTFBDplE1tyATpu+8lLtQHJ1bK 52y2Jg2bKnM7tOKmLZwWZHzV/LiX01QGqYptbk0= X-Received: by 2002:a9f:30dc:: with SMTP id k28mr9442718uab.75.1552035200158; Fri, 08 Mar 2019 00:53:20 -0800 (PST) MIME-Version: 1.0 References: <20190301160856.129678-1-joel@joelfernandes.org> <20190307150343.GB258852@google.com> In-Reply-To: <20190307150343.GB258852@google.com> From: Geert Uytterhoeven Date: Fri, 8 Mar 2019 09:53:07 +0100 Message-ID: Subject: Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel To: Joel Fernandes Cc: Linux Kernel Mailing List , Andrew Morton , Alexei Starovoitov , atishp04@gmail.com, dancol@google.com, Dan Williams , Dietmar Eggemann , Greg KH , Guenter Roeck , Jonathan Corbet , karim.yaghmour@opersys.com, Kees Cook , Android Kernel Team , "open list:DOCUMENTATION" , "open list:KERNEL SELFTEST FRAMEWORK" , linux-trace-devel@vger.kernel.org, Manoj Rao , Masahiro Yamada , Masami Hiramatsu , qais.yousef@arm.com, Randy Dunlap , Steven Rostedt , Shuah Khan , yhs@fb.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Joel, On Thu, Mar 7, 2019 at 4:03 PM Joel Fernandes wrote: > On Thu, Mar 07, 2019 at 09:58:24AM +0100, Geert Uytterhoeven wrote: > > On Fri, Mar 1, 2019 at 5:10 PM Joel Fernandes (Google) > > wrote: > > > Introduce in-kernel headers and other artifacts which are made available > > > as an archive through proc (/proc/kheaders.tar.xz 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 > > > package on Android. Further once a different kernel is booted, any > > > headers stored on the file system will no longer be useful. By storing > > > the headers as a compressed archive within the kernel, we can avoid these > > > issues that have been a hindrance for a long time. > > > > > > The feature is also buildable as a module just in case the user desires > > > it not being part of the kernel image. This makes it possible to load > > > and unload the headers on demand. A tracing program, or a kernel module > > > builder can load the module, do its operations, and then unload the > > > module to save kernel memory. The total memory needed is 3.8MB. > > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > the same technique to embed the headers. > > > > > > To build a module, the below steps have been tested on an x86 machine: > > > modprobe kheaders > > > rm -rf $HOME/headers > > > mkdir -p $HOME/headers > > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null > > > cd my-kernel-module > > > make -C $HOME/headers M=$(pwd) modules > > > rmmod kheaders > > > > As the usage pattern will be accessing the individual files, what about > > implementing a file system that provides read-only access to the internal > > kheaders archive? > > > > mount kheaders $HOME/headers -t kheaders > > I thought about it already. This is easier said than done though. The archive > is compressed from 40MB to 3.6MB. If we leave it uncompressed in RAM, then it > will take up the entire 40MB of RAM and in Android we don't even use > disk-based swap. Sure. > So we will need some kind of intra file compressed memory representation that > a filesystem can use for the backing store. I thought of RAM-backed squashfs Right, I didn't think of squashfs. Having a kernel module that sets up an MTD that can be mounted with squashfs is IMHO an even better (and more generic) solution. > but it requires squashfs-tools to be installed at build time (which my host > distro itself didn't have). Squashfs not being part of your host distro is not the hardest problem to solve... > It is just so much easier to use tar + xz at build time, and leave the > decompression task to the user. After decompression, the files will live on > the disk and the page-cache mechanism will free memory when/if the files fall > off the LRUs. I'm also considering how generic and extensible the solution is. What if people need other build artifacts in the future (e.g. signing key to load signed modules)? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds