| 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
| ||
|
Message-ID: <CAK7LNATUu6pSzasKEoVJfh+fS0cEq839kxrCcCwWxfsoubnQcQ@mail.gmail.com>
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