From owner-freebsd-ppc@freebsd.org Wed Jan 30 00:30:19 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E992714ADAD3 for ; Wed, 30 Jan 2019 00:30:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83767720E8 for ; Wed, 30 Jan 2019 00:30:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: eT_h9wkVM1ndEOyLXzYThNclygr.AK56sZNfH6CGW1RFkzfcnWzJ4zRwK9Zt8RF FtGJ6u6g4mtUcRLB8z3CdaCELLH4bNMlOcy8nOsI9DBX7fKqy20n7osuIoPUuwez54PEV_1o3ZSV PsnXfg92rocY9_z3qlb2bnmVp5oakxkB3Or2augazD2GtXqp2TjafqOIu13WLr7D8mlrgb7Gzu25 2gH8L..cQMaQBTgDatTGHQ6kR65JKP8yHcaClWMwFGNgNTnVdnERhjo3qIiuTAn1_Uw93DuBuWP8 6D7iBkI8ranks6JRp43XjEL8moN.yCO8mwJ4ZzWWO9.Qo8KvJLVQ7KOyK74S7R0sL42MiTL9RKos K6YJKewDKr6BiawFAFfXAaOlAE1BkXwQQoPevmp9L0.ISGvrQSnbtaqLA.IVNLJkIJ3O3JBOVlbQ jD0NdzmsTiKALJOOq_zdEfl8TBnzKZrUowNxTOmSvDq5cp6ZvUMW1hdX_snSMrlUjHzSJLK3yVcX I.hVaoZyLcvKGti4GWceNxtK57v3okTU.ukOP6FF4zO5Tf_Lg7gCZn4PcBqlnpxhPSzXTo8NReVB oeElUu75HO7Afa8lUChmgAJtWNXetV6iTiiVi6kfHZs1zODOGPfcdiKr7LVlrWjjnkjqIlWG62gO Rux6zGn2kjYL5iv5rFeJcPTsmbnLx2Cxv2nsKRDcsMBV4MuyRqUkgwiTZWIiY7XumCYBU2ErRfAE jc8NqQUE7DP.SehEXzYdr6lljhsCpgQYZFaobF8Ciflv_i8Vu9Tvzdy8RloDzXAWws0XJ.3ZIpFV 96YXXcpkxoXSA4W79TAIRqwsZBicYsTZcGEunS6l9mdc3LZ6OObJSiRWlUyK6YhKiFTC7XZqtXoP cG7KuJb.Ui4ycziGiOsuTBlrdo8fiOfHf81pF0B5oB2rasAO1uUot.Nj5XmAM0QURgfSyjw0oVXD o3277pEsudAicovdbyqer4wSuwQ.ZIkXeROD4.Z9V_jxkXReUQaKnu2UxLKQzimOv..ZsLAhTxuY evS9LE1BsD2SSpY4MmRPdHiwr7.PqNfgxBts02lUKhg03oufsYZxuirOu4BHGt9Cn9X98 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Jan 2019 00:30:08 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2cb752086447c3ca8b85ffa9300018c0; Wed, 30 Jan 2019 00:30:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Under usefdt=1 type of context for G5 "4 core" (system total): unload then boot /boot/kernel/kernel fails very early with: panic: Translation map has incorrect cell count (260/256) From: Mark Millard In-Reply-To: <9A6549AE-46FB-41B9-8F15-9E1AE3E16E2C@yahoo.com> Date: Tue, 29 Jan 2019 16:30:06 -0800 Cc: Justin Hibbits , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A6549AE-46FB-41B9-8F15-9E1AE3E16E2C@yahoo.com> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 83767720E8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-1.22)[ip: (-7.31), ipnet: 98.137.64.0/21(0.70), asn: 36647(0.56), country: US(-0.08)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 00:30:19 -0000 On 2019-Jan-28, at 23:42, Mark Millard wrote: > [The loader here has been modified to always do the usefdt=3D1 code. > The modern VM_MAX_KERNEL_ADDRESS is in the kernel.] >=20 > In trying to boot for other experiments I tried at the loader prompt: >=20 > unload > load /boot/kernel/kernel > boot >=20 > and: >=20 > unload > boot -v /boot/kernel/kernel >=20 > Such combinations produced (typed from a picture of the screen, > the missing text was really missing): >=20 > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > panic: Translation map has incorrect cell count (260/256) Note that 260 is a multiple of 5 and 4 but 256 is not a multiple of 5. Being a multiple of 5 is important for "acells=3D=3D2" contexts. Going through some of the code, first noting some context: struct ofw_map { cell_t om_va; cell_t om_len; uint64_t om_pa; cell_t om_mode; }; This has 4 fields but one appears to be bigger than cell_t if I understand right. This gets into if: OF_getencprop(OF_finddevice("/"), "#address-cells", &acells, sizeof(acells)); indicates 2 cells for om_pa (via acells=3D=3D2) or just 1 cell. So when acells=3D=3D2 there are 5 cells per, otherwise there are 4. Now to the routine in question: static void moea64_add_ofw_mappings(mmu_t mmup, phandle_t mmu, size_t sz) { struct ofw_map translations[sz/(4*sizeof(cell_t))]; /*>=3D 4 = cells per */ For acells=3D=3D2 the above potentially over allocates translations = some. Later it turns out that if it does that may prevent out of bounds writing into translations . pcell_t acells, trans_cells[sz/sizeof(cell_t)]; It turns out that sz/sizeof(cell_t) at this point ended up as a multiple of 4 but not of 5, despite acells=3D=3D2 being the case. Later this leads to out of bounds accesses for trans_cells . struct pvo_entry *pvo; register_t msr; vm_offset_t off; vm_paddr_t pa_base; int i, j; =20 bzero(translations, sz); OF_getencprop(OF_finddevice("/"), "#address-cells", &acells, sizeof(acells)); This ended up with acells=3D=3D2 --so 5 cells per translation entry. if (OF_getencprop(mmu, "translations", trans_cells, sz) =3D=3D = -1) panic("moea64_bootstrap: can't get ofw translations"); For acells=3D=3D2: sz/sizeof(cell_t) not being a multiple of 5 means either some unused trans_cell entries or access outside the trans_cells array in the loop below, depending on the loop test used. CTR0(KTR_PMAP, "moea64_add_ofw_mappings: translations"); sz /=3D sizeof(cell_t); sz here ended up as 256, not a multiple of 5. for (i =3D 0, j =3D 0; i < sz; j++) { The i < sz test is testing the first of the 4 or 5 being below sz instead of testing the last of the 4 or 5. This leads to out of bounds accesses into trans_cells below for the 256 with acells=3D=3D2 case. It also means that the last translations[j] ends up with some garbage content. translations[j].om_va =3D trans_cells[i++]; translations[j].om_len =3D trans_cells[i++]; translations[j].om_pa =3D trans_cells[i++]; if (acells =3D=3D 2) { translations[j].om_pa <<=3D 32; translations[j].om_pa |=3D trans_cells[i++]; } translations[j].om_mode =3D trans_cells[i++]; } The loop test for the above loop just looks wrong to me for avoid bad accesses. KASSERT(i =3D=3D sz, ("Translations map has incorrect cell count = (%d/%zd)", i, sz)); Having sz [ the original sz/sizeof(cell_t) ] not be a multiple of 5 for acells=3D=3D2 would fail this test even if the loop stopped without going out of bounds on trans_cells (so i=3D=3D255 instead of i=3D=3D260). For the original sz figure having sz/sizeof(cell_t) =3D=3D 256, the = original sz figure was not a multiple of 5 [presuming sizeof(cell_t) is not a multiple of 5]. My guess is that the original sz value was wrong after the unload and boot (reloading) and the loop structure should avoid going out of bounds on trans_cells anyway. > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > 0xc000000000f9e kdb_backtrace+0x60 > 0xc000000000f9e vpanic+0x258 > 0xc000000000f9e panic+0x3c > 0xc000000000f9e moea64_late_bootstrap+0x2c0 > 0xc000000000f9e moea64_bootstrap_native+0x20c > 0xc000000000f9e pmap_bootstrap_0xc8 > 0xc000000000f9e powerpc_init+0x440 > 0xc000000000f9efc0: at=20 >=20 > (And that is all.) The below tried to fix the loop to avoid out of bounds trans_cells accesses and to allow my context to not panic for the "multiple of 4 but not of 5" issue for the unload then reload/boot sequence. The bias was for the code changes to be easy to follow, given the earlier commentary. # svnlite diff /usr/src/sys/powerpc/aim/mmu_oea64.c | more = = Index: = /usr/src/sys/powerpc/aim/mmu_oea64.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/aim/mmu_oea64.c (revision 341836) +++ /usr/src/sys/powerpc/aim/mmu_oea64.c (working copy) @@ -502,7 +502,7 @@ register_t msr; vm_offset_t off; vm_paddr_t pa_base; - int i, j; + int i, istep, j; =20 bzero(translations, sz); OF_getencprop(OF_finddevice("/"), "#address-cells", &acells, @@ -512,7 +512,8 @@ =20 CTR0(KTR_PMAP, "moea64_add_ofw_mappings: translations"); sz /=3D sizeof(cell_t); - for (i =3D 0, j =3D 0; i < sz; j++) { + istep =3D (acells =3D=3D 2) ? 5 : 4; + for (i =3D 0, j =3D 0; i+istep-1 < sz; j++) { translations[j].om_va =3D trans_cells[i++]; translations[j].om_len =3D trans_cells[i++]; translations[j].om_pa =3D trans_cells[i++]; @@ -522,7 +523,7 @@ } translations[j].om_mode =3D trans_cells[i++]; } - KASSERT(i =3D=3D sz, ("Translations map has incorrect cell count = (%d/%zd)", + KASSERT(i+sz%istep =3D=3D sz, ("Translations map has incorrect = cell count (%d/%zd)", i, sz)); =20 sz =3D j; I do not claim the KASSERT should officially change but I expect that = the loop should. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)