[PATCH -tip] x86: headers - fix export private data to userspace

[PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

Impact: cleanup

'make headers_check' warn us about leaking of kernel private
(mostly compile time vars) data to userspace in headers. Fix it.

More detailed report for easier reviewing:

1) boot.h - neither BOOT_HEAP_SIZE, BOOT_STACK_SIZE refs
   was found by searching thru net (ie in user-space area).

2) prctl.h - sys_arch_prctl is completely removed from
   header since frankly I don't even understand why we
   describe it here. It is described like
    __SYSCALL(__NR_arch_prctl, sys_arch_prctl) in unistd_64.h
   and implemented in process_64.c. User-mode linux involved?
   So this one in fact is suspicious.

3) ptrace-abi.h - ptrace_bts_config struct is wrapped
   by __KERNEL__ -- not sure if it was ever proposed for
   userland.

4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
   could use it.

5) sigcontext32.h - we really need linux/types.h here
   since we use __u... types.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---

I should probably write "Impact: break the kernel" :)

It requires _STRONG_ review, randconfig and so on. It's
really fragile -- having NAK on response will be fine.

 arch/x86/include/asm/boot.h         |   10 +++++++---
 arch/x86/include/asm/prctl.h        |    4 ----
 arch/x86/include/asm/ptrace-abi.h   |    4 +++-
 arch/x86/include/asm/setup.h        |    4 ++--
 arch/x86/include/asm/sigcontext32.h |    2 ++
 5 files changed, 14 insertions(+), 10 deletions(-)

Index: linux-2.6.git/arch/x86/include/asm/boot.h
===================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/boot.h
+++ linux-2.6.git/arch/x86/include/asm/boot.h
@@ -10,14 +10,16 @@
 #define EXTENDED_VGA	0xfffe		/* 80x50 mode */
 #define ASK_VGA		0xfffd		/* ask for it at bootup */
 
+#ifdef __KERNEL__
+
 /* Physical address where kernel should be loaded. */
 #define LOAD_PHYSICAL_ADDR ((CONFIG_PHYSICAL_START \
 				+ (CONFIG_PHYSICAL_ALIGN - 1)) \
 				& ~(CONFIG_PHYSICAL_ALIGN - 1))
 
-#if (defined CONFIG_KERNEL_BZIP2)
+#ifdef CONFIG_KERNEL_BZIP2
 #define BOOT_HEAP_SIZE             0x400000
-#else
+#else /* !CONFIG_KERNEL_BZIP2 */
 
 #ifdef CONFIG_X86_64
 #define BOOT_HEAP_SIZE	0x7000
@@ -25,7 +27,7 @@
 #define BOOT_HEAP_SIZE	0x4000
 #endif
 
-#endif
+#endif /* !CONFIG_KERNEL_BZIP2 */
 
 #ifdef CONFIG_X86_64
 #define BOOT_STACK_SIZE	0x4000
@@ -33,4 +35,6 @@
 #define BOOT_STACK_SIZE	0x1000
 #endif
 
+#endif /* __KERNEL__ */
+
 #endif /* _ASM_X86_BOOT_H */
Index: linux-2.6.git/arch/x86/include/asm/prctl.h
===================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/prctl.h
+++ linux-2.6.git/arch/x86/include/asm/prctl.h
@@ -6,8 +6,4 @@
 #define ARCH_GET_FS 0x1003
 #define ARCH_GET_GS 0x1004
 
-#ifdef CONFIG_X86_64
-extern long sys_arch_prctl(int, unsigned long);
-#endif /* CONFIG_X86_64 */
-
 #endif /* _ASM_X86_PRCTL_H */
Index: linux-2.6.git/arch/x86/include/asm/ptrace-abi.h
===================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/ptrace-abi.h
+++ linux-2.6.git/arch/x86/include/asm/ptrace-abi.h
@@ -50,7 +50,7 @@
 #define RSP 152
 #define SS 160
 #define ARGOFFSET R11
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLY__ || __FRAME_OFFSETS */
 
 /* top of stack page */
 #define FRAME_SIZE 168
@@ -80,6 +80,7 @@
 
 #define PTRACE_SINGLEBLOCK	33	/* resume execution until next branch */
 
+#ifdef __KERNEL__
 #ifdef CONFIG_X86_PTRACE_BTS
 
 #ifndef __ASSEMBLY__
@@ -141,5 +142,6 @@ struct ptrace_bts_config {
    Returns number of BTS records drained.
 */
 #endif /* CONFIG_X86_PTRACE_BTS */
+#endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_PTRACE_ABI_H */
Index: linux-2.6.git/arch/x86/include/asm/setup.h
===================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/setup.h
+++ linux-2.6.git/arch/x86/include/asm/setup.h
@@ -3,6 +3,8 @@
 
 #define COMMAND_LINE_SIZE 2048
 
+#ifdef __KERNEL__
+
 #ifndef __ASSEMBLY__
 
 /* Interrupt control for vSMPowered x86_64 systems */
@@ -56,8 +58,6 @@ extern unsigned long saved_video_mode;
 #endif
 #endif /* __ASSEMBLY__ */
 
-#ifdef __KERNEL__
-
 #ifdef __i386__
 
 #include <linux/pfn.h>
Index: linux-2.6.git/arch/x86/include/asm/sigcontext32.h
===================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/sigcontext32.h
+++ linux-2.6.git/arch/x86/include/asm/sigcontext32.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_X86_SIGCONTEXT32_H
 #define _ASM_X86_SIGCONTEXT32_H
 
+#include <linux/types.h>
+
 /* signal context for 32bit programs. */
 
 #define X86_FXSR_MAGIC		0x0000

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Harvey Harrison]

On Tue, 2009-01-13 at 21:34 +0300, Cyrill Gorcunov wrote:
> Impact: cleanup

> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
>    could use it.

Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
polluting the namespace, not sure it can be changed though as the
horse is already out of the barn.

Harvey

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[H. Peter Anvin]

Harvey Harrison wrote:
> On Tue, 2009-01-13 at 21:34 +0300, Cyrill Gorcunov wrote:
>> Impact: cleanup
> 
>> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
>>    could use it.
> 
> Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
> polluting the namespace, not sure it can be changed though as the
> horse is already out of the barn.

No, this is not one of those cases, but it's worth explaining why.

You can introduce symbols into the general namespace if *and only if*
they are in a header file that is invoked directly by the user.  In
other words, such a header file is unusable by libc, but setup.h doesn't
contain anything needed by libc in the first place.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[Harvey Harrison - Tue, Jan 13, 2009 at 10:37:12AM -0800]
| On Tue, 2009-01-13 at 21:34 +0300, Cyrill Gorcunov wrote:
| > Impact: cleanup
| 
| > 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
| >    could use it.
| 
| Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
| polluting the namespace, not sure it can be changed though as the
| horse is already out of the barn.
| 
| Harvey
| 

I was concerning more about lilo side, is it use this param.
So here is a link

	http://lists.linuxcoding.com/kernel/2006-q3/msg18665.html

is seems LILO has it's own definition for COMMAND_LINE_SIZE.
On the other hand it touches boot protocol. Peter should know
if it safe to hide/change COMMAND_LINE_SIZE. Peter?

		- Cyrill -

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[H. Peter Anvin - Tue, Jan 13, 2009 at 10:49:24AM -0800]
| Harvey Harrison wrote:
| > On Tue, 2009-01-13 at 21:34 +0300, Cyrill Gorcunov wrote:
| >> Impact: cleanup
| > 
| >> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
| >>    could use it.
| > 
| > Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
| > polluting the namespace, not sure it can be changed though as the
| > horse is already out of the barn.
| 
| No, this is not one of those cases, but it's worth explaining why.
| 
| You can introduce symbols into the general namespace if *and only if*
| they are in a header file that is invoked directly by the user.  In
| other words, such a header file is unusable by libc, but setup.h doesn't
| contain anything needed by libc in the first place.
| 
| 	-hpa
| 
| -- 
| H. Peter Anvin, Intel Open Source Technology Center
| I work for Intel.  I don't speak on their behalf.
| 

So we could just fence it by __KERNEL__?

		- Cyrill -

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[H. Peter Anvin]

Cyrill Gorcunov wrote:
> 
> I was concerning more about lilo side, is it use this param.
> So here is a link
> 
> 	http://lists.linuxcoding.com/kernel/2006-q3/msg18665.html
> 
> is seems LILO has it's own definition for COMMAND_LINE_SIZE.
> On the other hand it touches boot protocol. Peter should know
> if it safe to hide/change COMMAND_LINE_SIZE. Peter?
> 

Current x86 kernels export the command line size through the bzImage
header, and as such COMMAND_LINE_SIZE should not be used by userspace.

I can't speak for other architectures.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[H. Peter Anvin]

Cyrill Gorcunov wrote:
> | > 
> | >> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
> | >>    could use it.
> | > 
> | > Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
> | > polluting the namespace, not sure it can be changed though as the
> | > horse is already out of the barn.
> | 
> | No, this is not one of those cases, but it's worth explaining why.
> | 
> | You can introduce symbols into the general namespace if *and only if*
> | they are in a header file that is invoked directly by the user.  In
> | other words, such a header file is unusable by libc, but setup.h doesn't
> | contain anything needed by libc in the first place.
> | 
> | 	-hpa
> | 
> 
> So we could just fence it by __KERNEL__?
> 

We might, as userspace shouldn't need COMMAND_LINE_SIZE anyway (see
other post), but I'm rather confused as how you got that from what I
wrote above.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[H. Peter Anvin - Tue, Jan 13, 2009 at 10:54:35AM -0800]
| Cyrill Gorcunov wrote:
| > 
| > I was concerning more about lilo side, is it use this param.
| > So here is a link
| > 
| > 	http://lists.linuxcoding.com/kernel/2006-q3/msg18665.html
| > 
| > is seems LILO has it's own definition for COMMAND_LINE_SIZE.
| > On the other hand it touches boot protocol. Peter should know
| > if it safe to hide/change COMMAND_LINE_SIZE. Peter?
| > 
| 
| Current x86 kernels export the command line size through the bzImage
| header, and as such COMMAND_LINE_SIZE should not be used by userspace.
| 
| I can't speak for other architectures.
| 
| 	-hpa
| 
| -- 
| H. Peter Anvin, Intel Open Source Technology Center
| I work for Intel.  I don't speak on their behalf.
| 

Thanks Peter!

		- Cyrill -

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[H. Peter Anvin - Tue, Jan 13, 2009 at 10:55:30AM -0800]
| Cyrill Gorcunov wrote:
| > | > 
| > | >> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
| > | >>    could use it.
| > | > 
| > | > Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
| > | > polluting the namespace, not sure it can be changed though as the
| > | > horse is already out of the barn.
| > | 
| > | No, this is not one of those cases, but it's worth explaining why.
| > | 
| > | You can introduce symbols into the general namespace if *and only if*
| > | they are in a header file that is invoked directly by the user.  In
| > | other words, such a header file is unusable by libc, but setup.h doesn't
| > | contain anything needed by libc in the first place.
| > | 
| > | 	-hpa
| > | 
| > 
| > So we could just fence it by __KERNEL__?
| > 
| 
| We might, as userspace shouldn't need COMMAND_LINE_SIZE anyway (see
| other post), but I'm rather confused as how you got that from what I
| wrote above.
| 
| 	-hpa
| 
| -- 
| H. Peter Anvin, Intel Open Source Technology Center
| I work for Intel.  I don't speak on their behalf.
| 

The thing is that kernel headers are not only touched by libc.
Someone could write a program and include setup.h there.
Or I translated you wrong :)

		- Cyrill -

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[H. Peter Anvin]

Cyrill Gorcunov wrote:
> | > | 
> | > | You can introduce symbols into the general namespace if *and only if*
> | > | they are in a header file that is invoked directly by the user.  In
> | > | other words, such a header file is unusable by libc, but setup.h doesn't
> | > | contain anything needed by libc in the first place.
> | > | 
> | > | 	-hpa
> | > | 
> | > 
> | > So we could just fence it by __KERNEL__?
> | > 
> | 
> | We might, as userspace shouldn't need COMMAND_LINE_SIZE anyway (see
> | other post), but I'm rather confused as how you got that from what I
> | wrote above.
> | 
> 
> The thing is that kernel headers are not only touched by libc.
> Someone could write a program and include setup.h there.
> Or I translated you wrong :)
> 

My whole point was that there are classes of symbols which may be
legitimately used by userspace *applications*, but not by libc.  Those
can live in the general namespace since they are included by explicit
user command.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Harvey Harrison]

On Tue, 2009-01-13 at 10:49 -0800, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> > On Tue, 2009-01-13 at 21:34 +0300, Cyrill Gorcunov wrote:
> >> Impact: cleanup
> > 
> >> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
> >>    could use it.
> > 
> > Doesn't this need to be (at least) _COMMAND_LINE_SIZE to avoid
> > polluting the namespace, not sure it can be changed though as the
> > horse is already out of the barn.
> 
> No, this is not one of those cases, but it's worth explaining why.
> 
> You can introduce symbols into the general namespace if *and only if*
> they are in a header file that is invoked directly by the user.  In
> other words, such a header file is unusable by libc, but setup.h doesn't
> contain anything needed by libc in the first place.
> 

Thanks for the explanation, while I was aware of that, I hadn't actually
looked if libc pulled this in...thinking a bit more it should have been
obvious libc wouldn't be interested in this header.

Thanks.

Harvey

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[H. Peter Anvin - Tue, Jan 13, 2009 at 11:03:03AM -0800]
| Cyrill Gorcunov wrote:
| > | > | 
| > | > | You can introduce symbols into the general namespace if *and only if*
| > | > | they are in a header file that is invoked directly by the user.  In
| > | > | other words, such a header file is unusable by libc, but setup.h doesn't
| > | > | contain anything needed by libc in the first place.
| > | > | 
| > | > | 	-hpa
| > | > | 
| > | > 
| > | > So we could just fence it by __KERNEL__?
| > | > 
| > | 
| > | We might, as userspace shouldn't need COMMAND_LINE_SIZE anyway (see
| > | other post), but I'm rather confused as how you got that from what I
| > | wrote above.
| > | 
| > 
| > The thing is that kernel headers are not only touched by libc.
| > Someone could write a program and include setup.h there.
| > Or I translated you wrong :)
| > 
| 
| My whole point was that there are classes of symbols which may be
| legitimately used by userspace *applications*, but not by libc.  Those
| can live in the general namespace since they are included by explicit
| user command.
| 
| 	-hpa
| 
| -- 
| H. Peter Anvin, Intel Open Source Technology Center
| I work for Intel.  I don't speak on their behalf.
| 

That is why I didn't fence COMMAND_LINE_SIZE by __KERNEL__ initialy
and thought about if LILO could had been using it. Then I found a
post in old-dated LKML that LILO has its own definition for
such a symbol, then I asked you about boot protocol. I just
didn't understand why you're confused but nevermind :)

		- Cyrill -

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[H. Peter Anvin]

Cyrill Gorcunov wrote:
> Impact: cleanup
> 
> 'make headers_check' warn us about leaking of kernel private
> (mostly compile time vars) data to userspace in headers. Fix it.
> 
> More detailed report for easier reviewing:
> 
> 1) boot.h - neither BOOT_HEAP_SIZE, BOOT_STACK_SIZE refs
>    was found by searching thru net (ie in user-space area).
> 
> 2) prctl.h - sys_arch_prctl is completely removed from
>    header since frankly I don't even understand why we
>    describe it here. It is described like
>     __SYSCALL(__NR_arch_prctl, sys_arch_prctl) in unistd_64.h
>    and implemented in process_64.c. User-mode linux involved?
>    So this one in fact is suspicious.
> 
> 3) ptrace-abi.h - ptrace_bts_config struct is wrapped
>    by __KERNEL__ -- not sure if it was ever proposed for
>    userland.
> 
> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
>    could use it.
> 
> 5) sigcontext32.h - we really need linux/types.h here
>    since we use __u... types.
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>

Hi Cyrill; in addition to nonexporting COMMAND_LINE_SIZE, could you 
submit this as a patchset to make post-integration bisect easier?

	-hpa

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[H. Peter Anvin - Wed, Jan 14, 2009 at 11:42:56AM -0800]
> Cyrill Gorcunov wrote:
>> Impact: cleanup
>>
>> 'make headers_check' warn us about leaking of kernel private
>> (mostly compile time vars) data to userspace in headers. Fix it.
>>
>> More detailed report for easier reviewing:
>>
>> 1) boot.h - neither BOOT_HEAP_SIZE, BOOT_STACK_SIZE refs
>>    was found by searching thru net (ie in user-space area).
>>
>> 2) prctl.h - sys_arch_prctl is completely removed from
>>    header since frankly I don't even understand why we
>>    describe it here. It is described like
>>     __SYSCALL(__NR_arch_prctl, sys_arch_prctl) in unistd_64.h
>>    and implemented in process_64.c. User-mode linux involved?
>>    So this one in fact is suspicious.
>>
>> 3) ptrace-abi.h - ptrace_bts_config struct is wrapped
>>    by __KERNEL__ -- not sure if it was ever proposed for
>>    userland.
>>
>> 4) setup.h - COMMAND_LINE_SIZE saved for userspace, bootloaders
>>    could use it.
>>
>> 5) sigcontext32.h - we really need linux/types.h here
>>    since we use __u... types.
>>
>> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>
> Hi Cyrill; in addition to nonexporting COMMAND_LINE_SIZE, could you  
> submit this as a patchset to make post-integration bisect easier?
>
> 	-hpa
>

Hi Peter, to be sure -- you mean to make patchset with 5 patches?

		- Cyrill -

Re: [PATCH -tip] x86: headers - fix export private data to userspace

[Cyrill Gorcunov]

[Cyrill Gorcunov - Wed, Jan 14, 2009 at 10:49:33PM +0300]
...
| >
| > Hi Cyrill; in addition to nonexporting COMMAND_LINE_SIZE, could you  
| > submit this as a patchset to make post-integration bisect easier?
| >
| > 	-hpa
| >
| 
| Hi Peter, to be sure -- you mean to make patchset with 5 patches?
| 
| 		- Cyrill -

Of course you mean that, i need some coffee :)
Will do soon.

		- Cyrill -