Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious

[Artyom Tarasenko]

On Sat, Apr 6, 2013 at 3:57 AM, Artyom Tarasenko  wrote:
> Signed-off-by: Artyom Tarasenko
>
> arch/sparc32/lib.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/sparc32/lib.c b/arch/sparc32/lib.c
> index 483069c..215ddcc 100644
> --- a/arch/sparc32/lib.c
> +++ b/arch/sparc32/lib.c
> @@ -19,6 +19,8 @@
>
> #define NCTX_SWIFT  0x100
>  #define LOWMEMSZ 32 * 1024 * 1024
> +/* Avoid mapping the first page to make NULL-dereferencing more obvious */
> +#define LOWMEM_START PAGE_SIZE
>
> #ifdef CONFIG_DEBUG_MEM
>  #define DPRINTF(fmt, args...)                   \
> @@ -403,7 +405,8 @@ init_mmu_swift(void)
>      ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa));
>  // 1:1 mapping for RAM
> ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0));
>
> ofmem_arch_map_pages(LOWMEM_START, LOWMEM_START, LOWMEMSZ,
>                     ofmem_arch_default_translation_mode(LOWMEM_START));
>
> /*
>     * Flush cache

Found one bug in Forth code using this patch:

0 > debug (.property-by-name)
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
 ok
0 > cd /  ok
0 > .properties
name
: (.property-by-name)  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 )
ffd30c00: 2over  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e398 4 )
ffd30c04: (")  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e398 4 ffd30c0c 3 )
ffd30c10: strcmp  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 1 )
ffd30c14: 0=  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 )
ffd30c18: do?branch  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 )
ffd30c38: active-package  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e318 )
ffd30c3c: get-nodename  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd3872c 13 )
ffd30c40: (")  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd3872c 13 ffd30c48 6 )
ffd30c50: strcmp  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 1 )
ffd30c54: 0=  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 )
ffd30c58: do?branch  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 )
ffd30ca0: (")  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd30ca8 7 )
ffd30cb0: find-dev  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ffffffff )
ffd30cb4: do?branch  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 )
ffd30cbc: (")  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ffd30cc4 3 )
ffd30cc8: rot  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd30cc4 3 ffd2e6f8 )
ffd30ccc: get-package-property  ( ffd2e398 4 ffd2e398 4 ffd3872c 14
ffd2e7c4 4 0 )
ffd30cd0: 0=  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 ffffffff )
ffd30cd4: do?branch  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 )
ffd30cdc: decode-int  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c8 0 0 )
ffd30ce0: nip  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c8 0 )
ffd30ce4: nip  ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 )

^^^^ here we have a null-pointer de-referencing.

ffd30ce8: ihandle>phandle
Unhandled Exception 0x00000009
PC = 0xffd07f74 NPC = 0xffd07f78

I guess ihandle>phandle shouldn't be called for the root entry. What
do you think?

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu