CAN-2005-0204 and 2.4

CAN-2005-0204 and 2.4

[Horms]

On Wed, Sep 21, 2005 at 01:31:37PM +0300, Nikos Ntarmos wrote:
> Package: kernel-source-2.4.27
> Version: 2.4.27-11.hls.2005082200
> Severity: important
> Justification: fails to build from source
> 
> Patch 143_outs.diff.bz2 breaks the kernel compilation on x86_64. The
> problem is that it uses the IO_BITMAP_BYTES macro which is defined for
> i386 (in linux/include/asm-i386/processor.h) but not for x86_64.
> Reverting the patch lets the kernel build again, although I guess the
> correct solution would be to add an appropriate IO_BITMAP_BYTES to
> linux/include/asm-x86_64/processor.h as well.

Hi Nikos,

First up, thanks for testing out my prebuild kernels.  For the
uninitiated they are snapshots of what is in the deabian kernel-team's
SVN and live in http://packages.vergenet.net/testing/

The problem that you see is a patch that was included in
2.4.27-11 (the current version in sid), though it isn't built
for amd64.

Could you see if the following patch works for you.  I've CCed lkml and
Marcelo for their consideration.  It seems to me that 2.4 is indeed
vulnerable to CAN-2005-0204, perhaps someone can shed some light on
this.

-- 
Horms

Description: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction
Patch author: Suresh Siddha (suresh.b.siddha@intel.com)
Upstream status: not applied
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146244
Patch source: Micah Anderson <micah@riseup.net> (debian-kernel)

Added definition of IO_BITMAP_BYTES for Debian's 2.4.27 and
submitted upstream for consideration for inclusion in 2.4 -- Horms
 
--- a/include/asm-x86_64/desc.h	2005-02-24 19:51:26.000000000 +0900
+++ b/include/asm-x86_64/desc.h	2005-02-24 19:52:40.000000000 +0900
@@ -128,7 +128,7 @@
 
 static inline void set_tss_desc(unsigned n, void *addr)
 { 
-	set_tssldt_descriptor((void *)&gdt_table + __CPU_DESC_INDEX(n,tss), (unsigned long)addr, DESC_TSS, sizeof(struct tss_struct)); 
+	set_tssldt_descriptor((void *)&gdt_table + __CPU_DESC_INDEX(n,tss), (unsigned long)addr, DESC_TSS, IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7); 
 } 
 
 static inline void set_ldt_desc(unsigned n, void *addr, int size)
--- a/include/asm-x86_64/processor.h	2005-09-22 11:12:40.000000000 +0900
+++ b/include/asm-x86_64/processor.h	2005-09-22 11:12:43.000000000 +0900
@@ -260,6 +260,7 @@
  * Size of io_bitmap in longwords: 32 is ports 0-0x3ff.
  */
 #define IO_BITMAP_SIZE	32
+#define IO_BITMAP_BYTES (IO_BITMAP_SIZE * sizeof(u32))
 #define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap)
 #define INVALID_IO_BITMAP_OFFSET 0x8000
 

Re: CAN-2005-0204 and 2.4

[Nikos Ntarmos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there.

On Thu, Sep 22, 2005 at 11:30:25AM +0900, Horms wrote:
> The problem that you see is a patch that was included in 2.4.27-11
> (the current version in sid), though it isn't built for amd64.
> 
> Could you see if the following patch works for you.

Yes it does. That's exactly what I also did to make it build, but I
didn't send in a patch as I wasn't sure that 4 (sizeof(u32)) is the
right factor for a 64-bit arch.

> I've CCed lkml and Marcelo for their consideration.  It seems to me
> that 2.4 is indeed vulnerable to CAN-2005-0204, perhaps someone can
> shed some light on this.

My intuition agrees with yours. However, as also stated in #329355 by
fs, "the amd64 port does not support 2.4 kernels, and there are no plans
to change this", so I guess this is not-a-bug for debian/x86_64.

\n\n
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Nikos "Nikolai" Ntarmos <ntarmos@ceid.upatras.gr>

iD8DBQFDMrgIm6J1ac+VFgoRAhbeAKCF2R6VkcHCsTYalKNnuvZeILlfMwCeMQDu
0C9BehFcgeBdor2abF+2wmo=
=Ihfo
-----END PGP SIGNATURE-----

Re: CAN-2005-0204 and 2.4

[Horms]

On Thu, Sep 22, 2005 at 04:56:24PM +0300, Nikos Ntarmos wrote:
> Hi there.
> 
> On Thu, Sep 22, 2005 at 11:30:25AM +0900, Horms wrote:
> > The problem that you see is a patch that was included in 2.4.27-11
> > (the current version in sid), though it isn't built for amd64.
> > 
> > Could you see if the following patch works for you.
> 
> Yes it does. That's exactly what I also did to make it build, but I
> didn't send in a patch as I wasn't sure that 4 (sizeof(u32)) is the
> right factor for a 64-bit arch.
> 
> > I've CCed lkml and Marcelo for their consideration.  It seems to me
> > that 2.4 is indeed vulnerable to CAN-2005-0204, perhaps someone can
> > shed some light on this.
> 
> My intuition agrees with yours. However, as also stated in #329355 by
> fs, "the amd64 port does not support 2.4 kernels, and there are no plans
> to change this", so I guess this is not-a-bug for debian/x86_64.

Well, its not a Debian bug as such, but it was an upstream
bug which has now been fixed and should appear in 2.4.32.
So your efforts weren't entirely in vain.

-- 
Horms

Re: CAN-2005-0204 and 2.4

[Marcelo Tosatti]

On Thu, Sep 22, 2005 at 11:30:25AM +0900, Horms wrote:
> On Wed, Sep 21, 2005 at 01:31:37PM +0300, Nikos Ntarmos wrote:
> > Package: kernel-source-2.4.27
> > Version: 2.4.27-11.hls.2005082200
> > Severity: important
> > Justification: fails to build from source
> > 
> > Patch 143_outs.diff.bz2 breaks the kernel compilation on x86_64. The
> > problem is that it uses the IO_BITMAP_BYTES macro which is defined for
> > i386 (in linux/include/asm-i386/processor.h) but not for x86_64.
> > Reverting the patch lets the kernel build again, although I guess the
> > correct solution would be to add an appropriate IO_BITMAP_BYTES to
> > linux/include/asm-x86_64/processor.h as well.
> 
> Hi Nikos,
> 
> First up, thanks for testing out my prebuild kernels.  For the
> uninitiated they are snapshots of what is in the deabian kernel-team's
> SVN and live in http://packages.vergenet.net/testing/
> 
> The problem that you see is a patch that was included in
> 2.4.27-11 (the current version in sid), though it isn't built
> for amd64.
> 
> Could you see if the following patch works for you.  I've CCed lkml and
> Marcelo for their consideration.  It seems to me that 2.4 is indeed
> vulnerable to CAN-2005-0204, perhaps someone can shed some light on
> this.
> 
> -- 
> Horms
> 
> Description: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction
> Patch author: Suresh Siddha (suresh.b.siddha@intel.com)
> Upstream status: not applied
> URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146244
> Patch source: Micah Anderson <micah@riseup.net> (debian-kernel)
> 
> Added definition of IO_BITMAP_BYTES for Debian's 2.4.27 and
> submitted upstream for consideration for inclusion in 2.4 -- Horms

And v2.6 does not seem to have been updated either, or a different form of 
the fix has been deployed? 

130 static inline void set_tss_desc(unsigned cpu, void *addr)
131 {
132 	set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
133 	DESC_TSS,
134 	sizeof(struct tss_struct) - 1);
135 } 

[patch] x86_64: fix tss limit (was Re: CAN-2005-0204 and 2.4)

[Siddha, Suresh B]

On Thu, Sep 22, 2005 at 05:04:46PM -0300, Marcelo Tosatti wrote:
> 
> On Thu, Sep 22, 2005 at 11:30:25AM +0900, Horms wrote:
> > On Wed, Sep 21, 2005 at 01:31:37PM +0300, Nikos Ntarmos wrote:
> > > Package: kernel-source-2.4.27
> > > Version: 2.4.27-11.hls.2005082200
> > > Severity: important
> > > Justification: fails to build from source
> > > 
> > > Patch 143_outs.diff.bz2 breaks the kernel compilation on x86_64. The
> > > problem is that it uses the IO_BITMAP_BYTES macro which is defined for
> > > i386 (in linux/include/asm-i386/processor.h) but not for x86_64.
> > > Reverting the patch lets the kernel build again, although I guess the
> > > correct solution would be to add an appropriate IO_BITMAP_BYTES to
> > > linux/include/asm-x86_64/processor.h as well.
> > 
> > Hi Nikos,
> > 
> > First up, thanks for testing out my prebuild kernels.  For the
> > uninitiated they are snapshots of what is in the deabian kernel-team's
> > SVN and live in http://packages.vergenet.net/testing/
> > 
> > The problem that you see is a patch that was included in
> > 2.4.27-11 (the current version in sid), though it isn't built
> > for amd64.
> > 
> > Could you see if the following patch works for you.  I've CCed lkml and
> > Marcelo for their consideration.  It seems to me that 2.4 is indeed
> > vulnerable to CAN-2005-0204, perhaps someone can shed some light on
> > this.
> > 
> > -- 
> > Horms
> > 
> > Description: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction
> > Patch author: Suresh Siddha (suresh.b.siddha@intel.com)
> > Upstream status: not applied
> > URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146244
> > Patch source: Micah Anderson <micah@riseup.net> (debian-kernel)
> > 
> > Added definition of IO_BITMAP_BYTES for Debian's 2.4.27 and
> > submitted upstream for consideration for inclusion in 2.4 -- Horms
> 
> And v2.6 does not seem to have been updated either, or a different form of 
> the fix has been deployed? 
> 
> 130 static inline void set_tss_desc(unsigned cpu, void *addr)
> 131 {
> 132 	set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
> 133 	DESC_TSS,
> 134 	sizeof(struct tss_struct) - 1);
> 135 } 

Marcelo, This particular vulnerability is not present in 2.6 base. As I
mentioned in that bugzilla, 2.6 base increased IO_BITMAP_BITS  to 65536
and the kernel initializes this bitmap pointer during boot appropriately.

But in general the specified limit is wrong and needs to be fixed.

Appended patch will fix the tss limit. Andrew, please apply. Thanks.
--

Fix the x86_64 TSS limit in TSS descriptor.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>

--- linux-2.6.14-rc1/include/asm-x86_64/desc.h.orig	2005-09-12 20:12:09.000000000 -0700
+++ linux-2.6.14-rc1/include/asm-x86_64/desc.h	2005-09-23 12:50:58.210135128 -0700
@@ -129,7 +129,7 @@ static inline void set_tss_desc(unsigned
 { 
 	set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr, 
 			      DESC_TSS,
-			      sizeof(struct tss_struct) - 1);
+			      IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
 } 
 
 static inline void set_ldt_desc(unsigned cpu, void *addr, int size)

Re: [patch] x86_64: fix tss limit (was Re: CAN-2005-0204 and 2.4)

[Jesper Juhl]

On 9/24/05, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
[snip]
>
> Fix the x86_64 TSS limit in TSS descriptor.
>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
>
> --- linux-2.6.14-rc1/include/asm-x86_64/desc.h.orig     2005-09-12 20:12:09.000000000 -0700
> +++ linux-2.6.14-rc1/include/asm-x86_64/desc.h  2005-09-23 12:50:58.210135128 -0700
> @@ -129,7 +129,7 @@ static inline void set_tss_desc(unsigned
>  {
>         set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
>                               DESC_TSS,
> -                             sizeof(struct tss_struct) - 1);
> +                             IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
>  }
>
[snip]

Is it just me, or would it be nice with a symbolic name for this "7" ?
For someone reading the code for the first time it seems to me that
it's non-obvious why the 7 is there, and why it's 7 exactely - a
define would make it clearer as I see it.


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [patch] x86_64: fix tss limit (was Re: CAN-2005-0204 and 2.4)

[Siddha, Suresh B]

On Sat, Sep 24, 2005 at 12:55:41AM +0200, Jesper Juhl wrote:
> On 9/24/05, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> >         set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
> >                               DESC_TSS,
> > -                             sizeof(struct tss_struct) - 1);
> > +                             IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
> >  }
> >
> [snip]
> 
> Is it just me, or would it be nice with a symbolic name for this "7" ?
> For someone reading the code for the first time it seems to me that
> it's non-obvious why the 7 is there, and why it's 7 exactely - a
> define would make it clearer as I see it.

Andrew please apply this updated patch. Thanks.

--
Fix the x86_64 TSS limit in TSS descriptor.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>

--- linux-2.6.14-rc1/include/asm-x86_64/desc.h.orig	2005-09-12 20:12:09.000000000 -0700
+++ linux-2.6.14-rc1/include/asm-x86_64/desc.h	2005-09-23 15:41:28.103954880 -0700
@@ -127,9 +127,16 @@ static inline void set_tssldt_descriptor
 
 static inline void set_tss_desc(unsigned cpu, void *addr)
 { 
+	/*
+	 * sizeof(unsigned long) coming from an extra "long" at the end
+	 * of the iobitmap. See tss_struct definition in processor.h
+	 * 
+	 * -1? seg base+limit should be pointing to the address of the
+	 * last valid byte
+	 */
 	set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr, 
 			      DESC_TSS,
-			      sizeof(struct tss_struct) - 1);
+			      IO_BITMAP_OFFSET + IO_BITMAP_BYTES + sizeof(unsigned long) - 1);
 } 
 
 static inline void set_ldt_desc(unsigned cpu, void *addr, int size)

Re: [patch] x86_64: fix tss limit (was Re: CAN-2005-0204 and 2.4)

[Jesper Juhl]

On 9/24/05, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> On Sat, Sep 24, 2005 at 12:55:41AM +0200, Jesper Juhl wrote:
> > On 9/24/05, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> > >         set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
> > >                               DESC_TSS,
> > > -                             sizeof(struct tss_struct) - 1);
> > > +                             IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
> > >  }
> > >
> > [snip]
> >
> > Is it just me, or would it be nice with a symbolic name for this "7" ?
> > For someone reading the code for the first time it seems to me that
> > it's non-obvious why the 7 is there, and why it's 7 exactely - a
> > define would make it clearer as I see it.
>
> Andrew please apply this updated patch. Thanks.
>
[snip]

That change makes me happy :)

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html