lkml.org 
[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] mpparse: prevent table index out-of-bounds
    Date
    On Thursday 06 April 2006 13:18, Randy.Dunlap wrote:
    > On Thu, 6 Apr 2006 09:18:45 -0700 John Z. Bohach wrote:
    >
    > Re: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module)
    > kernel oops)
    >
    > > I found the root cause, but don't know if its worth fixing. If the board
    > > has more than 32 PCI busses on it, the mptable bus array will overwrite
    > > its bounds for the PCI busses, and stomp on anything that's after it. In
    > > this case, what got stomped on is the PAGE_KERNEL_EXEC variable, which
    > > changed the bit-field settings for the page tables (cleared the 'present'
    > > bit, and screwed up the rest), hence accounting for the page fault.
    >
    > Well, > 32 busses or just one busid value >= 32.
    >
    > > This can only happen if there are more than 32 PCI busses, so I'd say its
    > > an _extremely_ rare condition on a desktop system. At any rate, the fix
    > > would simply be to change the value of the #define in the mptable.h
    > > header file (I forget which exactly, but its easy to find) from 32 to
    > > 256. The side effect of that is that the kernel data area would grow, and
    > > mostly be a total waste, since I can't fathom a desktop system with more
    > > than 32 PCI busses. On arch's where more than 32 PCI busses are likely,
    > > the #define is already 256.
    >
    > I think that the kernel init code should detect and prevent the
    > data corruption. Here's a patch to do that, by ignoring busses
    > whose busid value is too large.

    Yeah, I follow your thinking, and was about to do the same thing, until
    I consulted the book of armaments, in this case, the MP Spec. ver. 1.4.

    Section 4.3.2, Bus Entries, Bus ID:

    "An integer that identifies the bus entry. The BIOS assigns identifiers
    starting at zero, sequentially."

    Given this, I considered the kernel adequate. Nevertheless, your patch is a good
    defensive programming method against buggy BIOS's. I haven't actually tested it,
    but it looks like it'll be okay.

    --john

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-07 07:36    [W:0.025 / U:29.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site