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]
Date:   Sun, 12 May 2019 15:29:40 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Michael Witten <mfwitten@...il.com>
Cc:     Michal Marek <michal.lkml@...kovi.net>,
        David Woodhouse <dwmw2@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: The UAPI references Kconfig's CONFIG_* macros (variables)

On Sat, May 11, 2019 at 1:28 PM Michael Witten <mfwitten@...il.com> wrote:
>
> The  UAPI  headers  contain  references  to  Kconfig's  `CONFIG_'
> macros. Either this is a bug,  or there needs to be some standard
> way for users  to provide definitions for these  macros, in order
> to complete Linux's user-space API. Consider:


In fact, scripts/headers_check.pl has ability to check
CONFIG_ options leaked to user space,
but it has been disabled for a long time.

If you revert the following and run "make headers_check",
you will see lots.

In my understanding, we want to check this,
but it is _still_ too noisy.



commit 7e3fa56141175026136b392fd026d5d07c49720e
Author: Sam Ravnborg <sam@...nborg.org>
Date:   Fri Jan 30 23:56:42 2009 +0100

    kbuild: drop check for CONFIG_ in headers_check

    The check for references to CONFIG_ symbols in exported headers turned
    out to be too agressive with the current state of affairs.
    After the work of Jaswinder to clean up all relevant cases we are down
    to almost pure noise.

    So lets drop the check for now - we can always add it back later
    should our headers be ready for that.

    Signed-off-by: Sam Ravnborg <sam@...nborg.org>
    Signed-off-by: Ingo Molnar <mingo@...e.hu>

diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
index db30fac..56f90a4 100644
--- a/scripts/headers_check.pl
+++ b/scripts/headers_check.pl
@@ -38,7 +38,7 @@ foreach my $file (@files) {
                &check_asm_types();
                &check_sizetypes();
                &check_prototypes();
-               &check_config();
+               # Dropped for now. Too much noise &check_config();
        }
        close FH;
 }









>
>   #!/bin/sh
>   cd "${linux_repo}"
>
>   # Careful!
>   #git reset --hard HEAD
>   #git clean -fdx
>
>   git checkout v5.1
>   #zcat /proc/config.gz >.config
>
>   mkdir -p /tmp/uapi/include
>   make INSTALL_HDR_PATH=/tmp/uapi headers_install
>
>   printf >/tmp/uapi/raw.c '%s\n%s\n' \
>     '#include <linux/raw.h>' \
>     'int main() { return MAX_RAW_MINORS; }'
>
> Then:
>
>   $ gcc -c -I/tmp/uapi/include /tmp/uapi/raw.c
>   In file included from /tmp/uapi/raw.c:1:0:
>   /tmp/uapi/raw.c: In function ‘main’:
>   /tmp/uapi/include/linux/raw.h:17:24: error: ‘CONFIG_MAX_RAW_DEVS’ undeclared (first use in this function)
>    #define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
>                           ^
>   /tmp/uapi/raw.c:2:21: note: in expansion of macro ‘MAX_RAW_MINORS’
>    int main() { return MAX_RAW_MINORS; }
>                        ^~~~~~~~~~~~~~
>   /tmp/uapi/include/linux/raw.h:17:24: note: each undeclared identifier is reported only once for each function it appears in
>    #define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
>                           ^
>   /tmp/uapi/raw.c:2:21: note: in expansion of macro ‘MAX_RAW_MINORS’
>    int main() { return MAX_RAW_MINORS; }
>                        ^~~~~~~~~~~~~~
>
> As you can  see, the UAPI is actually incomplete;  there is not a
> valid  definition for  `MAX_RAW_MINORS'.  Indeed,  on my  system,
> `CONFIG_MAX_RAW_DEVS'  isn't   ever  defined   anywhere,  because
> `CONFIG_RAW_DRIVER' is not set:
>
>   $ git show v5.1:drivers/char/Kconfig | sed -n 467,469p
>   config MAX_RAW_DEVS
>           int "Maximum number of RAW devices to support (1-65536)"
>           depends on RAW_DRIVER
>   $ zcat /proc/config.gz | grep RAW_DRIVER
>   # CONFIG_RAW_DRIVER is not set
>
> Even if `CONFIG_RAW_DRIVER' were  set, the desired definition for
> the  macro  `CONFIG_MAX_RAW_DEVS'  would  only be  found  in  the
> following  header (generated  at  built-time),  which is  neither
> officially nor likely available to user space:
>
>   "${linux_repo}"/include/generated/autoconf.h
>
> Other  such  references to  `CONFIG_*'  macros  are seen  in  the
> following  (some  appear only  in  comments,  but perhaps  that's
> conceptually a mistake, too):
>
>   $ (cd /tmp/uapi/include && grep -R . -e \\bCONFIG_)
>   ./asm/mman.h:#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
>   ./asm/auxvec.h:#if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64)
>   ./asm/e820.h: * kernel was built: MAX_NUMNODES == (1 << CONFIG_NODES_SHIFT),
>   ./asm/e820.h: * unless the CONFIG_X86_PMEM_LEGACY option is set.
>   ./asm/e820.h: * if CONFIG_INTEL_TXT is enabled, memory of this type will be
>   ./mtd/ubi-user.h: * default kernel value of %CONFIG_MTD_UBI_BEB_LIMIT will be used.
>   ./linux/pkt_cls.h:    TCA_FW_INDEV, /*  used by CONFIG_NET_CLS_IND */
>   ./linux/pkt_cls.h:    TCA_FW_ACT, /* used by CONFIG_NET_CLS_ACT */
>   ./linux/cm4000_cs.h: * member sizes. This leads to CONFIG_COMPAT breakage, since 32bit userspace
>   ./linux/eventpoll.h:#ifdef CONFIG_PM_SLEEP
>   ./linux/hw_breakpoint.h:#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>   ./linux/bpf.h: * has been built with CONFIG_EFFICIENT_UNALIGNED_ACCESS not set,
>   ./linux/bpf.h: *              the **CONFIG_CGROUP_NET_CLASSID** configuration option set to
>   ./linux/bpf.h: *              **CONFIG_IP_ROUTE_CLASSID** configuration option.
>   ./linux/bpf.h: *              with the **CONFIG_BPF_KPROBE_OVERRIDE** configuration
>   ./linux/bpf.h: *              the CONFIG_FUNCTION_ERROR_INJECTION option. As of this writing,
>   ./linux/bpf.h: *              **CONFIG_XFRM** configuration option.
>   ./linux/bpf.h: *              the **CONFIG_BPF_LIRC_MODE2** configuration option set to
>   ./linux/bpf.h: *              the **CONFIG_BPF_LIRC_MODE2** configuration option set to
>   ./linux/bpf.h: *              **CONFIG_SOCK_CGROUP_DATA** configuration option.
>   ./linux/bpf.h: *              **CONFIG_NET** configuration option.
>   ./linux/bpf.h: *              **CONFIG_NET** configuration option.
>   ./linux/bpf.h: *              the **CONFIG_BPF_LIRC_MODE2** configuration option set to
>   ./linux/raw.h:#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
>   ./linux/pktcdvd.h:#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
>   ./linux/flat.h:#ifdef CONFIG_BINFMT_SHARED_FLAT
>   ./linux/videodev2.h: * Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
>   ./linux/elfcore.h:#ifdef CONFIG_BINFMT_ELF_FDPIC
>   ./linux/atmdev.h:#ifdef CONFIG_COMPAT
>   ./asm-generic/bitsperlong.h: * both 32 and 64 bit user space must not rely on CONFIG_64BIT
>   ./asm-generic/unistd.h:/* mm/, CONFIG_MMU only */
>   ./asm-generic/mman-common.h:#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
>   ./asm-generic/fcntl.h:#ifndef CONFIG_64BIT
>
> What is the correct way to think about this?
>
>   * Should the UAPI make no reference to build-time configurations?
>   * Should the UAPI headers include sanity checks on behalf of the user?
>   * Should there be a `/proc/config.h.gz' facility?
>
> Sincerely,
> Michael Witten



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ