| Message ID | 1484304406-10820-2-git-send-email-nicolas.dichtel@6wind.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Please, do not remove the email subject when you reply. I restore it to ease the thread follow-up. Le 13/01/2017 à 16:36, David Howells a écrit : > Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: > >> This header file is exported, thus move it to uapi. > > Exported how? It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by arch/arm/include/uapi/asm/Kbuild. You can also have a look at patch #5 to see why it was exported even if it was not in an uapi directory. Regards, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote: > Please, do not remove the email subject when you reply. I restore it to > ease the thread follow-up. I mentioned it to David, and he says it's because the long list of recipients is breaking his mailer. I've already posed the question about whether that's exploitable! > Le 13/01/2017 à 16:36, David Howells a écrit : > > Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote: > > > >> This header file is exported, thus move it to uapi. > > > > Exported how? > > It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by > arch/arm/include/uapi/asm/Kbuild. We really should not be installing non-uapi header files to userland under _any_ circumstance - this to me sounds like a bug in kbuild. The assumption is that headers outside of uapi directories are not part of the user visible API, and so can be freely modified - which in the presence of this bug is untrue. However, as it's happening, and this header has been there since 2013 (commit 09096f6a0ee2 - "ARM: 7822/1: add workaround for ambiguous C99 stdint.h types") it's now well and truely part of the user API whether we intended it to be or not, so your patch looks to me like the correct thing to do. I think it needs further evaluation to make sure kbuild isn't going to do something else silly, like subsitute include/asm-generic/types.h for the now missing arch/arm/include/asm/types.h I wonder how many more headers are unintentionally exported. ... what a mess. :(
On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. I'm taking this patch, but with the following commit log: Due to the way kbuild works, this header was unintentionally exported back in 2013 when it was created, despite it not being in a uapi/ directory. This is very non-intuitive behaviour by Kbuild. However, we've had this include exported to userland for almost four years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives no hint that anyone has complained about it. So, let's make it officially exported in this state. If anyone has any objections, they better shout sooner rather than later. > > Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> > --- > arch/arm/include/asm/types.h | 40 --------------------------------------- > arch/arm/include/uapi/asm/types.h | 40 +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 40 insertions(+), 40 deletions(-) > delete mode 100644 arch/arm/include/asm/types.h > create mode 100644 arch/arm/include/uapi/asm/types.h > > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h > deleted file mode 100644 > index a53cdb8f068c..000000000000 > --- a/arch/arm/include/asm/types.h > +++ /dev/null > @@ -1,40 +0,0 @@ > -#ifndef _ASM_TYPES_H > -#define _ASM_TYPES_H > - > -#include <asm-generic/int-ll64.h> > - > -/* > - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as > - * unambiguous on ARM as you would expect. For the types below, there is a > - * difference on ARM between GCC built for bare metal ARM, GCC built for glibc > - * and the kernel itself, which results in build errors if you try to build with > - * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' > - * in order to use NEON intrinsics) > - * > - * As the typedefs for these types in 'stdint.h' are based on builtin defines > - * supplied by GCC, we can tweak these to align with the kernel's idea of those > - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same > - * source file (provided that -ffreestanding is used). > - * > - * int32_t uint32_t uintptr_t > - * bare metal GCC long unsigned long unsigned int > - * glibc GCC int unsigned int unsigned int > - * kernel int unsigned int unsigned long > - */ > - > -#ifdef __INT32_TYPE__ > -#undef __INT32_TYPE__ > -#define __INT32_TYPE__ int > -#endif > - > -#ifdef __UINT32_TYPE__ > -#undef __UINT32_TYPE__ > -#define __UINT32_TYPE__ unsigned int > -#endif > - > -#ifdef __UINTPTR_TYPE__ > -#undef __UINTPTR_TYPE__ > -#define __UINTPTR_TYPE__ unsigned long > -#endif > - > -#endif /* _ASM_TYPES_H */ > diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h > new file mode 100644 > index 000000000000..9435a42f575e > --- /dev/null > +++ b/arch/arm/include/uapi/asm/types.h > @@ -0,0 +1,40 @@ > +#ifndef _UAPI_ASM_TYPES_H > +#define _UAPI_ASM_TYPES_H > + > +#include <asm-generic/int-ll64.h> > + > +/* > + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as > + * unambiguous on ARM as you would expect. For the types below, there is a > + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc > + * and the kernel itself, which results in build errors if you try to build with > + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' > + * in order to use NEON intrinsics) > + * > + * As the typedefs for these types in 'stdint.h' are based on builtin defines > + * supplied by GCC, we can tweak these to align with the kernel's idea of those > + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same > + * source file (provided that -ffreestanding is used). > + * > + * int32_t uint32_t uintptr_t > + * bare metal GCC long unsigned long unsigned int > + * glibc GCC int unsigned int unsigned int > + * kernel int unsigned int unsigned long > + */ > + > +#ifdef __INT32_TYPE__ > +#undef __INT32_TYPE__ > +#define __INT32_TYPE__ int > +#endif > + > +#ifdef __UINT32_TYPE__ > +#undef __UINT32_TYPE__ > +#define __UINT32_TYPE__ unsigned int > +#endif > + > +#ifdef __UINTPTR_TYPE__ > +#undef __UINTPTR_TYPE__ > +#define __UINTPTR_TYPE__ unsigned long > +#endif > + > +#endif /* _UAPI_ASM_TYPES_H */ > -- > 2.8.1 >
diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h deleted file mode 100644 index a53cdb8f068c..000000000000 --- a/arch/arm/include/asm/types.h +++ /dev/null @@ -1,40 +0,0 @@ -#ifndef _ASM_TYPES_H -#define _ASM_TYPES_H - -#include <asm-generic/int-ll64.h> - -/* - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as - * unambiguous on ARM as you would expect. For the types below, there is a - * difference on ARM between GCC built for bare metal ARM, GCC built for glibc - * and the kernel itself, which results in build errors if you try to build with - * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' - * in order to use NEON intrinsics) - * - * As the typedefs for these types in 'stdint.h' are based on builtin defines - * supplied by GCC, we can tweak these to align with the kernel's idea of those - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same - * source file (provided that -ffreestanding is used). - * - * int32_t uint32_t uintptr_t - * bare metal GCC long unsigned long unsigned int - * glibc GCC int unsigned int unsigned int - * kernel int unsigned int unsigned long - */ - -#ifdef __INT32_TYPE__ -#undef __INT32_TYPE__ -#define __INT32_TYPE__ int -#endif - -#ifdef __UINT32_TYPE__ -#undef __UINT32_TYPE__ -#define __UINT32_TYPE__ unsigned int -#endif - -#ifdef __UINTPTR_TYPE__ -#undef __UINTPTR_TYPE__ -#define __UINTPTR_TYPE__ unsigned long -#endif - -#endif /* _ASM_TYPES_H */ diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h new file mode 100644 index 000000000000..9435a42f575e --- /dev/null +++ b/arch/arm/include/uapi/asm/types.h @@ -0,0 +1,40 @@ +#ifndef _UAPI_ASM_TYPES_H +#define _UAPI_ASM_TYPES_H + +#include <asm-generic/int-ll64.h> + +/* + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as + * unambiguous on ARM as you would expect. For the types below, there is a + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc + * and the kernel itself, which results in build errors if you try to build with + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' + * in order to use NEON intrinsics) + * + * As the typedefs for these types in 'stdint.h' are based on builtin defines + * supplied by GCC, we can tweak these to align with the kernel's idea of those + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same + * source file (provided that -ffreestanding is used). + * + * int32_t uint32_t uintptr_t + * bare metal GCC long unsigned long unsigned int + * glibc GCC int unsigned int unsigned int + * kernel int unsigned int unsigned long + */ + +#ifdef __INT32_TYPE__ +#undef __INT32_TYPE__ +#define __INT32_TYPE__ int +#endif + +#ifdef __UINT32_TYPE__ +#undef __UINT32_TYPE__ +#define __UINT32_TYPE__ unsigned int +#endif + +#ifdef __UINTPTR_TYPE__ +#undef __UINTPTR_TYPE__ +#define __UINTPTR_TYPE__ unsigned long +#endif + +#endif /* _UAPI_ASM_TYPES_H */
This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> --- arch/arm/include/asm/types.h | 40 --------------------------------------- arch/arm/include/uapi/asm/types.h | 40 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 40 deletions(-) delete mode 100644 arch/arm/include/asm/types.h create mode 100644 arch/arm/include/uapi/asm/types.h