OpenBIOS April 2013

openbios@openbios.org

8 participants
89 discussions

[commit] r1112 - trunk/openbios-devel/packages
by repository service 06 Apr '13

06 Apr '13

Author: mcayland Date: Sat Apr 6 19:31:25 2013 New Revision: 1112 URL: http://tracker.coreboot.org/trac/openbios/changeset/1112 Log: sun-parts.c: Fix NULL-dereferencing in sunparts_open Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/packages/sun-parts.c Modified: trunk/openbios-devel/packages/sun-parts.c ============================================================================== --- trunk/openbios-devel/packages/sun-parts.c Fri Apr 5 12:34:38 2013 (r1111) +++ trunk/openbios-devel/packages/sun-parts.c Sat Apr 6 19:31:25 2013 (r1112) @@ -109,7 +109,7 @@ [(id)][,][filespec] */ - if ( strlen(str) ) { + if ( str && strlen(str) ) { /* Detect the arguments */ if ((*str >= '0' && *str <= '9') || (*str >= 'a' && *str < ('a' + 8)) || (*str == ',')) { push_str(str);

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 10:27 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sat, Apr 6, 2013 at 9:16 AM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> On 05/04/13 21:08, Tarl Neustaedter wrote: >> >>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>>> >>>> [...] >>>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 >>>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 >>>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc >>>> >>>> ^^^^ this one >>> >>> >>> Wherever that's coming from, that looks like an allocator doing >>> descending addresses. >>> >>>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 >>>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc >>>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 >>>> OFMEM: Non-free virtual memory claimed! >>>> >>>> ^^^^ overlaps with this one. >>> >>> >>> This allocator, whatever it is has been doing ascending addresses. This >>> actually looks like you simply ran out of room. >> >> >> Ah now I see. It looks as if kadb assumes that it has free use of the region >> from 0xffc00000 but the OFMEM allocator starts auto-allocating memory from >> beneath the internal heap which is below the ROM image at 0xffd00000. As >> Tarl rightly points out, as the allocations grow then kadb tries to grab an >> area of memory we have already claimed which causes the overlap error. >> >> Does the attached patch against SVN trunk enable you to get into kadb? It's >> the same as my last patch except for the following addition: >> >> --- a/openbios-devel/arch/sparc32/ofmem_sparc32.c >> +++ b/openbios-devel/arch/sparc32/ofmem_sparc32.c >> @@ -61,7 +61,7 @@ ucell ofmem_arch_get_heap_top(void) >> >> ucell ofmem_arch_get_virt_top(void) >> { >> - return (ucell)TOP_OF_RAM; >> + return (ucell)0xff000000; >> } >> >> So when we are auto-allocating from OFMEM, rather than starting from beneath >> the internal heap, we simply start auto-allocating from 0xff000000 downwards >> which should leave the 0xffc00000 region being used by kadb well alone. A >> quick test with the patch shows that my Solaris 8 image can still boot both >> normally and into kadb. > > Yes! In kadb I get! > > FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc > .vmunix loaded - 0x7c000 bytes used > > Unfortunately it's not as helpful as it became under Solaris 2.6+ : Especially when someone hasn't use it for the long time. Actually it's pretty good: kadb> :c OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc Begin traceback... sp = f0186b20 Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 f0186d88 f01e2ff4 Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 ff000008 ff000008 4400fe1 Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0 Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0 f01e2b1c ffffffff Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570 Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1 End traceback... fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874 stopped at 0: unimp 0x0 kadb> $c PR_BASE() + 0 kadb> f0054f44?ai _writekmsg+0x68: _writekmsg+0x68: call _mpprom_write_nl7 kadb> f0005250?ai _firsthighinstr+0xd8: _firsthighinstr+0xd8: call _early_startup kadb> Woo-hoo! -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 11:07 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>>> >>>> [...] >>>> >>>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 >>>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 >>>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc >>>> >>>> ^^^^ this one >>> >>> >>> Wherever that's coming from, that looks like an allocator doing descending >>> addresses. >>> >>> >>>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc >>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 >>>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc >>>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 >>>> OFMEM: Non-free virtual memory claimed! >>>> >>>> ^^^^ overlaps with this one. >>> >>> >>> This allocator, whatever it is has been doing ascending addresses. This >>> actually looks like you simply ran out of room. >> >> Ops. Good catch! >> Mark, can we just allocate more RAM, or do we have serious problem? >> >>> You might change that patch rather than rounding up to the next 2^n, don't >>> bother aligning to anything more than 0x2000. >> >> You mean >> >> } else if ( align > 0x2000) { >> align = 0x2000; >> } else { > > This would probably break allocation for IOMMU table, it needs to be > aligned (physically) to table size (like 32MB). Hmm. The successful log in the previous mail was produced with this code... Will remove it and test again. -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 09:27, Artyom Tarasenko wrote: > Unfortunately it's not as helpful as it became under Solaris 2.6+ : > > kadb> :c > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc > Begin traceback... sp = f0186b20 > Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 > Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 > f0186d88 f01e2ff4 > Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 > ff000008 ff000008 4400fe1 > Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 > Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 > Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 ^^^^^^^^ From memory the 0xf005... address range in Solaris 8 was used for dynamic kernel modules. So I'd start using kadb/remote GDB to poke around 0xf0054494 in memory until you find some strings that can help you identify which module it is for clues. BTW does "boot disk -v" give you any suitable output now? ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Blue Swirl 06 Apr '13

06 Apr '13

On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>> >>> [...] >>> >>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc >>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 >>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 >>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc >>> >>> ^^^^ this one >> >> >> Wherever that's coming from, that looks like an allocator doing descending >> addresses. >> >> >>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc >>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 >>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc >>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 >>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 >>> OFMEM: Non-free virtual memory claimed! >>> >>> ^^^^ overlaps with this one. >> >> >> This allocator, whatever it is has been doing ascending addresses. This >> actually looks like you simply ran out of room. > > Ops. Good catch! > Mark, can we just allocate more RAM, or do we have serious problem? > >> You might change that patch rather than rounding up to the next 2^n, don't >> bother aligning to anything more than 0x2000. > > You mean > > } else if ( align > 0x2000) { > align = 0x2000; > } else { This would probably break allocation for IOMMU table, it needs to be aligned (physically) to table size (like 32MB). > > ? Then it crashes allocating the same address (0xffc66000) as in the > previous log. > Or, don't bother at all? > > } else if ( align > 0x2000) { > align = 0; > } else { > > Then it dies pretty early: > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7f000 -> 006f7f000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7e000 -> 006f7e000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00000000 > OFMEM: ofmem_map_page_range 00000000 -> 006f60000 00014000 mode 000000bc > kmem_alloc failed, nbytes 81920 > kmem_alloc > boot-block startup failed > > Artyom > > -- > Regards, > Artyom Tarasenko > > linux/sparc and solaris/sparc under qemu blog: > http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 06 Apr '13

06 Apr '13

On 06/04/13 09:27, Artyom Tarasenko wrote: >> So when we are auto-allocating from OFMEM, rather than starting from beneath >> the internal heap, we simply start auto-allocating from 0xff000000 downwards >> which should leave the 0xffc00000 region being used by kadb well alone. A >> quick test with the patch shows that my Solaris 8 image can still boot both >> normally and into kadb. > > Yes! In kadb I get! Great - I'll spin up a couple of patches for this. > FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc > .vmunix loaded - 0x7c000 bytes used > > Unfortunately it's not as helpful as it became under Solaris 2.6+ : > > kadb> :c > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc > Begin traceback... sp = f0186b20 > Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 > Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 > f0186d88 f01e2ff4 > Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 > ff000008 ff000008 4400fe1 > Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 > Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 > Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 > Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0 > Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0 > f01e2b1c ffffffff > Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570 > Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1 > End traceback... > fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874 > stopped at 0: unimp 0x0 > kadb> bt > symbol not found > kadb> > > But still it's definitely a progress! Indeed :) I remember when I got this far with Solaris 8, my next step was to extract vmunix from the ISO image and run it through objdump - while it didn't contain full debug information, it did contain function name symbols which was enough for me to work out where the problem was. Note that it may be worth grabbing vmunix from the original boot CD and checking that too, just in case kernels with extra debug information are used for the installation media but not for a HD image. ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 06 Apr '13

06 Apr '13

On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: > [...] > OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 > OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc > > ^^^^ this one Wherever that's coming from, that looks like an allocator doing descending addresses. > OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 > OFMEM: Non-free virtual memory claimed! > > ^^^^ overlaps with this one. This allocator, whatever it is has been doing ascending addresses. This actually looks like you simply ran out of room. You might change that patch rather than rounding up to the next 2^n, don't bother aligning to anything more than 0x2000.

3 3

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 06 Apr '13

06 Apr '13

On 2013-Apr-5 21:50 , Artyom Tarasenko wrote: >> >You might change that patch rather than rounding up to the next 2^n, don't >> >bother aligning to anything more than 0x2000. > You mean > > } else if ( align > 0x2000) { > align = 0x2000; > } else { Yeah, that's what I meant. Evidently the extra storage you were consuming by rounding everything up to 2^n wasn't the problem.

1 0

[PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Artyom Tarasenko 06 Apr '13

06 Apr '13

Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> --- 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 -- 1.7.1

1 0

[PATCH 1/2] Fix NULL-dereferencing in sunparts_open
by Artyom Tarasenko 06 Apr '13

06 Apr '13

Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> --- packages/sun-parts.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/packages/sun-parts.c b/packages/sun-parts.c index 2ee9613..272f7c0 100644 --- a/packages/sun-parts.c +++ b/packages/sun-parts.c @@ -109,7 +109,7 @@ sunparts_open( sunparts_info_t *di ) [(id)][,][filespec] */ - if ( strlen(str) ) { + if ( str && strlen(str) ) { /* Detect the arguments */ if ((*str >= '0' && *str <= '9') || (*str >= 'a' && *str < ('a' + 8)) || (*str == ',')) { push_str(str); -- 1.7.1

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →