> 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:     dera...@cvs.openbsd.org 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
>     r...@beagle3.east.rtk0.net:/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

Reply via email to