DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)

DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)

[saikia.partha]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

Hi,

We have two Freescale PowerPC boards on which we're trying to enable
DEBUG_PAGEALLOC with the hope that we'll see an exception whenever some
code tries to modify a page that's been already freed. To test it, we wrote
this sample code -

===
#define BUF_SIZE    4096
void
pagealloc_test(void)
{
    char *buf = kmalloc(BUF_SIZE, GFP_KERNEL);

    if (!buf) {
        printk("%s[%d] - alloc failed!\n", __func__, __LINE__);
        return;
    }
    printk("%s[%d] - alloc'd\n", __func__, __LINE__);
    memset(&buf[0], 0, BUF_SIZE);
    printk("%s[%d] - memset'd\n", __func__, __LINE__);
    kfree(buf);
    printk("%s[%d] - free'd\n", __func__, __LINE__);
    memset(&buf[0], 1, BUF_SIZE);
    printk("%s[%d] - memset'd after free!\n", __func__, __LINE__);
}
===

Here, the last memset() should generate an exception if PAGEALLOC code
correctly unmapped the page during kfree(). However, kernel is happily
running after the memset post-free. Any clue?
Also, the 2nd board has Book-E which has a different MMU architecture.
Here, I saw that the function __change_page_attr() always returns as the
condition v_mapped_by_tlbcam() is true. How do we remove the pte entry from
the TLB in this case?  Has anyone tried DEBUG_PAGEALLOC on Book-E?

Please find the board details below -
Board 1: CPU - e300c4, kernel 2.6-25
==============================
======
CONFIG_6xx=y
CONFIG_PPC_FPU=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_IRQ_PER_CPU=y
CONFIG_PPC=y

Board 2: CPU - e500v2, kernel 3.0-34
====================================
# CONFIG_PPC_BOOK3S_32 is not set
CONFIG_PPC_85xx=y
CONFIG_E500=y
# CONFIG_PPC_E500MC is not set
CONFIG_FSL_EMB_PERFMON=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
CONFIG_PPC_FSL_BOOK3E=y
# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
CONFIG_PPC_MMU_NOHASH=y
CONFIG_PPC_MMU_NOHASH_32=y
CONFIG_PPC_BOOK3E_MMU=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PPC32=y
CONFIG_32BIT=y
CONFIG_WORD_SIZE=32
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_MMU=y
CONFIG_NR_IRQS=512
CONFIG_PPC=y

Regards,
Partha

[-- Attachment #2: Type: text/html, Size: 2605 bytes --]

Re: DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)

[Scott Wood]

On 06/19/2013 08:09:44 AM, saikia.partha wrote:
> Hi,
>=20
> We have two Freescale PowerPC boards on which we're trying to enable
> DEBUG_PAGEALLOC with the hope that we'll see an exception whenever =20
> some
> code tries to modify a page that's been already freed. To test it, we =20
> wrote
> this sample code -
>=20
> =3D=3D=3D
> #define BUF_SIZE    4096
> void
> pagealloc_test(void)
> {
>     char *buf =3D kmalloc(BUF_SIZE, GFP_KERNEL);
>=20
>     if (!buf) {
>         printk("%s[%d] - alloc failed!\n", __func__, __LINE__);
>         return;
>     }
>     printk("%s[%d] - alloc'd\n", __func__, __LINE__);
>     memset(&buf[0], 0, BUF_SIZE);
>     printk("%s[%d] - memset'd\n", __func__, __LINE__);
>     kfree(buf);
>     printk("%s[%d] - free'd\n", __func__, __LINE__);
>     memset(&buf[0], 1, BUF_SIZE);
>     printk("%s[%d] - memset'd after free!\n", __func__, __LINE__);
> }
> =3D=3D=3D
>=20
> Here, the last memset() should generate an exception if PAGEALLOC code
> correctly unmapped the page during kfree(). However, kernel is happily
> running after the memset post-free. Any clue?
> Also, the 2nd board has Book-E which has a different MMU architecture.
> Here, I saw that the function __change_page_attr() always returns as =20
> the
> condition v_mapped_by_tlbcam() is true. How do we remove the pte =20
> entry from
> the TLB in this case?  Has anyone tried DEBUG_PAGEALLOC on Book-E?

This is not supported on booke -- the tlbcam mapping is required for =20
all lowmem.

> Please find the board details below -
> Board 1: CPU - e300c4, kernel 2.6-25

For e300, I think I had it working at one point a few years ago (see =20
commit bde6c6e16aa489ea76c762fb7ffb0abb48660dd8).

The reason we can do it on e300 and not on booke is because e300 takes =20
exceptions in real mode.  On e500 the MMU is always enabled, so we need =20
bolted TLB1 entries that cover at least all exception code (up to the =20
point where a TLB miss could safely be taken) and all page tables (in =20
practice, we just bolt all lowmem) and other data that can be =20
referenced from said exception code.  There are not enough TLB1 entries =20
to do this on a fine-grained basis.

-Scott=

Re: DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)

[perth1415]

Hi Scott,

Thanks for the reply, though a bit disheartening :-)
My understanding on e500 MMU is not clear. It'd be nice if I could find some
way (may be ad-hoc) to debug some use-after-free page corruptions. SLAB
debug tells me the page was modified by someone after it was freed but
DEBUG_PAGEALLOC would have been more specific, as to tell me where exactly
it was getting modified.
Any debugging clues will be much appreciated.

Regards,
Partha



--
View this message in context: http://linuxppc.10917.n7.nabble.com/DEBUG-PAGEALLOC-on-PPC-not-working-kernels-2-6-25-3-0-34-tp72536p72625.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)

[Scott Wood]

On 06/20/2013 05:42:40 AM, perth1415 wrote:
> Hi Scott,
>=20
> Thanks for the reply, though a bit disheartening :-)
> My understanding on e500 MMU is not clear. It'd be nice if I could =20
> find some
> way (may be ad-hoc) to debug some use-after-free page corruptions. =20
> SLAB
> debug tells me the page was modified by someone after it was freed but
> DEBUG_PAGEALLOC would have been more specific, as to tell me where =20
> exactly
> it was getting modified.
> Any debugging clues will be much appreciated.

If you know an exact address that's being corrupted, you could set a =20
data breakpoint (by manually setting the registers, and making sure =20
that the exception handler will produce a dump and not ignore it as a =20
spurious event).  You could add code to periodically check for =20
corruption (from a timer, from codepaths which you suspect, =20
before/after IRQ handlers, etc).  If you have specific code that you =20
suspect may be responsible, you can have it check for poison values =20
before writing.  I'm not sure if slab debugging already does this, but =20
if not you could have it record the address of the code that last =20
allocated and freed the corrupted memory chunk.

If you have access to a tool such as Virtutech Simics, you could use =20
reverse execution to find the corruption.

Or you could find a way to separate the code/data needed by exceptions =20
(including page tables, kernel stacks, etc) from everything else, and =20
only pin the former, but that's probably a lot of work.

-Scott=

DEBUG_PAGEALLOC on PPC not working (kernels 2.6-25, 3.0-34)

[saikia.partha]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

Hi,

We have two Freescale PowerPC boards on which we're trying to enable
DEBUG_PAGEALLOC with the hope that we'll see an exception whenever some
code tries to modify a page that's been already freed. To test it, we wrote
this sample code -

===
#define BUF_SIZE    4096
void
pagealloc_test(void)
{
    char *buf = kmalloc(BUF_SIZE, GFP_KERNEL);

    if (!buf) {
        printk("%s[%d] - alloc failed!\n", __func__, __LINE__);
        return;
    }
    printk("%s[%d] - alloc'd\n", __func__, __LINE__);
    memset(&buf[0], 0, BUF_SIZE);
    printk("%s[%d] - memset'd\n", __func__, __LINE__);
    kfree(buf);
    printk("%s[%d] - free'd\n", __func__, __LINE__);
    memset(&buf[0], 1, BUF_SIZE);
    printk("%s[%d] - memset'd after free!\n", __func__, __LINE__);
}
===

Here, the last memset() should generate an exception if PAGEALLOC code
correctly unmapped the page during kfree(). However, kernel is happily
running after the memset post-free. Any clue?
Also, the 2nd board has Book-E which has a different MMU architecture.
Here, I saw that the function __change_page_attr() always returns as the
condition v_mapped_by_tlbcam() is true. How do we remove the pte entry from
the TLB in this case?  Has anyone tried DEBUG_PAGEALLOC on Book-E?

Please find the board details below -
Board 1: CPU - e300c4, kernel 2.6-25
====================================
CONFIG_6xx=y
CONFIG_PPC_FPU=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_IRQ_PER_CPU=y
CONFIG_PPC=y

Board 2: CPU - e500v2, kernel 3.0-34
====================================
# CONFIG_PPC_BOOK3S_32 is not set
CONFIG_PPC_85xx=y
CONFIG_E500=y
# CONFIG_PPC_E500MC is not set
CONFIG_FSL_EMB_PERFMON=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
CONFIG_PPC_FSL_BOOK3E=y
# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
CONFIG_PPC_MMU_NOHASH=y
CONFIG_PPC_MMU_NOHASH_32=y
CONFIG_PPC_BOOK3E_MMU=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PPC32=y
CONFIG_32BIT=y
CONFIG_WORD_SIZE=32
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_MMU=y
CONFIG_NR_IRQS=512
CONFIG_PPC=y

Regards,
Partha

[-- Attachment #2: Type: text/html, Size: 2558 bytes --]