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 <[email protected]>
---
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
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
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.
[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 -
[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 -
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.
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.
[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 -
[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 -
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.
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
[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 -
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 <[email protected]>
Hi Cyrill; in addition to nonexporting COMMAND_LINE_SIZE, could you
submit this as a patchset to make post-integration bisect easier?
-hpa
[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 <[email protected]>
>
> 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 -
[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 -