Re: CVS: cvs.openbsd.org: src

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Brandon Bergren


On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:

> CVSROOT: /cvs
> Module name: src
> Changes by: [hidden email] 2018/02/08 20:01:24
>
> Modified files:
> sys/dev        : rnd.c
>
> Log message:
> Situation occur where bootloader cannot supply kernel with early
> random data. But a new source of entropy arrived a few months ago
> -- KARL generates highly disturbed images for some kernels (well,
> not for bsd.rd)
> This assumes the tail of text (just before etext[]) is readable.
> We are trying to use a portable symbol name, and also avoid reading
> a locore0 which has been unmapped...
> ok mortimer
>

I'm seeing an unaligned access fault on armv7. But should etext be aligned, or should the code using it take alignment into account?

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Theo de Raadt-2
> On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > CVSROOT: /cvs
> > Module name: src
> > Changes by: [hidden email] 2018/02/08 20:01:24
> >
> > Modified files:
> > sys/dev        : rnd.c
> >
> > Log message:
> > Situation occur where bootloader cannot supply kernel with early
> > random data. But a new source of entropy arrived a few months ago
> > -- KARL generates highly disturbed images for some kernels (well,
> > not for bsd.rd)
> > This assumes the tail of text (just before etext[]) is readable.
> > We are trying to use a portable symbol name, and also avoid reading
> > a locore0 which has been unmapped...
> > ok mortimer
> >
>
> I'm seeing an unaligned access fault on armv7. But should etext be aligned, or should the code using it take alignment into account?

Please add printf's and figure out what is going on.


Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Brandon Bergren


On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote:

> > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: [hidden email] 2018/02/08 20:01:24
> > >
> > > Modified files:
> > > sys/dev        : rnd.c
> > >
> > > Log message:
> > > Situation occur where bootloader cannot supply kernel with early
> > > random data. But a new source of entropy arrived a few months ago
> > > -- KARL generates highly disturbed images for some kernels (well,
> > > not for bsd.rd)
> > > This assumes the tail of text (just before etext[]) is readable.
> > > We are trying to use a portable symbol name, and also avoid reading
> > > a locore0 which has been unmapped...
> > > ok mortimer
> > >
> >
> > I'm seeing an unaligned access fault on armv7. But should etext be aligned, or should the code using it take alignment into account?
>
> Please add printf's and figure out what is going on.
>
>

etext is coming from the linker script, and as such isn't necessarily aligned like clang assumes it is. So clang generates LDR instead of LDRB and loses.

I have also been seeing other similar problems for a while now (relinked kernels getting stuck in early boot, crashes before going multiuser, etc.) on armv7 that I think might also be alignment problems. I've been digging around in it for a while now but don't have it 100% nailed yet.

I will continue to look into this.

Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
** Unable to read file uEnv.txt **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /am335x-boneblack.dtb
35930 bytes read in 9 ms (3.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 2 not found
MMC Device 3 not found
Found 6 disks
reading efi/boot/bootarm.efi
76528 bytes read in 14 ms (5.2 MiB/s)
## Starting EFI application at 82000000 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot>  
booting sd0a:/bsd: 4535443+206344+562616 [277544+90+282224+244902]=0x5d8520

OpenBSD/armv7 booting ...
arg0 0xc08d8520 arg1 0xe05 arg2 0x88000000
Allocating page tables
freestart = 0x808d9000, free_pages = 128807 (0x0001f727)
IRQ stack: p0x80907000 v0xc0907000
ABT stack: p0x80908000 v0xc0908000
UND stack: p0x80909000 v0xc0909000
SVC stack: p0x8090a000 v0xc090a000
Creating L1 page table at 0x808dc000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 805216 bytes of bsd ELF symbol table ]
board type: 3589
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.2-current (GENERIC) #1: Sun Jan 28 16:48:36 CST 2018
    [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 516878336 (492MB)
Fatal kernel mode data abort: 'Alignment fault'
trapframe: 0xc090bf38
DFSR=00000001, DFAR=c0733493, spsr=20000193
r0 =c0733493, r1 =00000800, r2 =c07efcdc, r3 =c073b234
r4 =c07acce0, r5 =00000005, r6 =00000007, r7 =00000006
r8 =c07d3288, r9 =00000332, r10=0000019a, r11=c090bfa8
r12=0000000b, ssp=c090bf8c, slr=c05da2e4, pc =c05d8f50

Stopped at      add_entropy_words+0x5c: ldr     r8, [r0], #0x004
ddb> show registers
spsr          0x20000193
r0            0xc0733493        ieee80211_mira_valid_tx_mcs.max_mcs+0xf8b
r1                 0x800        fiqvector+0x7e4
r2            0xc07efcdc        entropy_add_ptr
r3            0xc073b234        add_entropy_words.twist_table
r4            0xc07acce0        entropy_pool
r5                   0x5
r6                   0x7
r7                   0x6
r8            0xc07d3288        cpu_info_primary
r9                 0x332        fiqvector+0x316
r10                0x19a        fiqvector+0x17e
r11           0xc090bfa8        _bss_end__+0xf83e8
r12                  0xb
usr_sp                 0
usr_lr                 0
svc_sp        0xc090bf8c        _bss_end__+0xf83cc
svc_lr        0xc05da2e4        random_start+0x8c
pc            0xc05d8f50        add_entropy_words+0x5c
und_sp        0xc090a000        _bss_end__+0xf6440
abt_sp        0xc0909000        _bss_end__+0xf5440
irq_sp        0xc0908000        _bss_end__+0xf4440
add_entropy_words+0x5c: ldr     r8, [r0], #0x004


-------------

This patch fixes the abort for me.


Index: sys/arch/arm/conf/ldscript.tail
===================================================================
RCS file: /cvs/src/sys/arch/arm/conf/ldscript.tail,v
retrieving revision 1.5
diff -u -p -u -r1.5 ldscript.tail
--- sys/arch/arm/conf/ldscript.tail 26 Oct 2017 19:01:06 -0000 1.5
+++ sys/arch/arm/conf/ldscript.tail 9 Feb 2018 23:28:43 -0000
@@ -1,5 +1,6 @@
 /*     $OpenBSD: ldscript.tail,v 1.5 2017/10/26 19:01:06 kettenis Exp $         */
   } =0
+  . = ALIGN(4);
   PROVIDE (__etext = .);
   PROVIDE (_etext = .);
   PROVIDE (etext = .);

Reply | Threaded
Open this post in threaded view
|

Re: CVS: cvs.openbsd.org: src

Theo de Raadt-2
> On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote:
> > > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > > > CVSROOT: /cvs
> > > > Module name: src
> > > > Changes by: [hidden email] 2018/02/08 20:01:24
> > > >
> > > > Modified files:
> > > > sys/dev        : rnd.c
> > > >
> > > > Log message:
> > > > Situation occur where bootloader cannot supply kernel with early
> > > > random data. But a new source of entropy arrived a few months ago
> > > > -- KARL generates highly disturbed images for some kernels (well,
> > > > not for bsd.rd)
> > > > This assumes the tail of text (just before etext[]) is readable.
> > > > We are trying to use a portable symbol name, and also avoid reading
> > > > a locore0 which has been unmapped...
> > > > ok mortimer
> > > >
> > >
> > > I'm seeing an unaligned access fault on armv7. But should etext be aligned, or should the code using it take alignment into account?
> >
> > Please add printf's and figure out what is going on.
> >
> >
>
> etext is coming from the linker script, and as such isn't necessarily aligned like clang assumes it is. So clang generates LDR instead of LDRB and loses.
>
> I have also been seeing other similar problems for a while now (relinked kernels getting stuck in early boot, crashes before going multiuser, etc.) on armv7 that I think might also be alignment problems. I've been digging around in it for a while now but don't have it 100% nailed yet.
>
> I will continue to look into this.
>
> Press SPACE to abort autoboot in 2 seconds
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> ** Unable to read file boot.scr **
> ** Unable to read file uEnv.txt **
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /am335x-boneblack.dtb
> 35930 bytes read in 9 ms (3.8 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> Scanning disks on usb...
> Scanning disks on mmc...
> MMC Device 2 not found
> MMC Device 3 not found
> Found 6 disks
> reading efi/boot/bootarm.efi
> 76528 bytes read in 14 ms (5.2 MiB/s)
> ## Starting EFI application at 82000000 ...
> >> OpenBSD/armv7 BOOTARM 1.0
> boot>  
> booting sd0a:/bsd: 4535443+206344+562616 [277544+90+282224+244902]=0x5d8520
>
> OpenBSD/armv7 booting ...
> arg0 0xc08d8520 arg1 0xe05 arg2 0x88000000
> Allocating page tables
> freestart = 0x808d9000, free_pages = 128807 (0x0001f727)
> IRQ stack: p0x80907000 v0xc0907000
> ABT stack: p0x80908000 v0xc0908000
> UND stack: p0x80909000 v0xc0909000
> SVC stack: p0x8090a000 v0xc090a000
> Creating L1 page table at 0x808dc000
> Mapping kernel
> Constructing L2 page tables
> undefined page pmap [ using 805216 bytes of bsd ELF symbol table ]
> board type: 3589
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org
>
> OpenBSD 6.2-current (GENERIC) #1: Sun Jan 28 16:48:36 CST 2018
>     [hidden email]:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 536870912 (512MB)
> avail mem = 516878336 (492MB)
> Fatal kernel mode data abort: 'Alignment fault'
> trapframe: 0xc090bf38
> DFSR=00000001, DFAR=c0733493, spsr=20000193
> r0 =c0733493, r1 =00000800, r2 =c07efcdc, r3 =c073b234
> r4 =c07acce0, r5 =00000005, r6 =00000007, r7 =00000006
> r8 =c07d3288, r9 =00000332, r10=0000019a, r11=c090bfa8
> r12=0000000b, ssp=c090bf8c, slr=c05da2e4, pc =c05d8f50
>
> Stopped at      add_entropy_words+0x5c: ldr     r8, [r0], #0x004
> ddb> show registers
> spsr          0x20000193
> r0            0xc0733493        ieee80211_mira_valid_tx_mcs.max_mcs+0xf8b
> r1                 0x800        fiqvector+0x7e4
> r2            0xc07efcdc        entropy_add_ptr
> r3            0xc073b234        add_entropy_words.twist_table
> r4            0xc07acce0        entropy_pool
> r5                   0x5
> r6                   0x7
> r7                   0x6
> r8            0xc07d3288        cpu_info_primary
> r9                 0x332        fiqvector+0x316
> r10                0x19a        fiqvector+0x17e
> r11           0xc090bfa8        _bss_end__+0xf83e8
> r12                  0xb
> usr_sp                 0
> usr_lr                 0
> svc_sp        0xc090bf8c        _bss_end__+0xf83cc
> svc_lr        0xc05da2e4        random_start+0x8c
> pc            0xc05d8f50        add_entropy_words+0x5c
> und_sp        0xc090a000        _bss_end__+0xf6440
> abt_sp        0xc0909000        _bss_end__+0xf5440
> irq_sp        0xc0908000        _bss_end__+0xf4440
> add_entropy_words+0x5c: ldr     r8, [r0], #0x004
>
>
> -------------
>
> This patch fixes the abort for me.
>
>
> Index: sys/arch/arm/conf/ldscript.tail
> ===================================================================
> RCS file: /cvs/src/sys/arch/arm/conf/ldscript.tail,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 ldscript.tail
> --- sys/arch/arm/conf/ldscript.tail 26 Oct 2017 19:01:06 -0000 1.5
> +++ sys/arch/arm/conf/ldscript.tail 9 Feb 2018 23:28:43 -0000
> @@ -1,5 +1,6 @@
>  /*     $OpenBSD: ldscript.tail,v 1.5 2017/10/26 19:01:06 kettenis Exp $         */
>    } =0
> +  . = ALIGN(4);
>    PROVIDE (__etext = .);
>    PROVIDE (_etext = .);
>    PROVIDE (etext = .);
>

Amusing.  I'll let arm people decide which way they want this,
or tell if if the rnd.c code should force an alignment