From owner-freebsd-hackers@freebsd.org Mon Jun 10 06:16:12 2019 Return-Path: Delivered-To: freebsd-hackers@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 CFEFA15B5389 for ; Mon, 10 Jun 2019 06:16:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (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 93CEA944FC for ; Mon, 10 Jun 2019 06:16:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 4XfBMCgVM1lOj19.HgnqGZkEE3sVY.sBuI.EuqPoiZFsY.oQW4Qg.O.b0gkuMau pRLc.0Kz2TAKXYcgAGU.N9OaU0l_OuSMp39ARckfmLUav_E0CvsuzRl25RxBC6ajbVQJ9uQdYFZ. .TojWMuJE4LLKOGr4XVEk1PtK7cklF9MkI7P9JL0KOhkFZbcH.Ib9YC.zssYVgwlDXVebel0Msgp q4qL.f3srp64PMkWhAXNyQlUBHBsQ96EM9ndolrZQOJFsoWE.mFk8X4R4614ZBDKCYv_SxukeFHC lohRZ87AGCyVn9yTJrsCA1L9eLIXC0npgKlRVetqP.xMBg2a31At92_LqUWnS9dTyXfXliVFQsUv luOHQ1vGrV78J5.9aU5mBvrE6D97xlrFniRmCROA3rpwd8XCk5BtAWLiUFL57iR275IDjsSRdOz3 WWtWmTvfe.Np57gX4B_5dKQYYt7_sa45SbloD6uu_D6rdVKFm4BWXPILeZ_Rm2U9OP1HxUd7KCPw 9M7bDGvpxU3YlASSG6A4LTrBnCN9k0gKiv0P3PuyeVIik6G1s0OTm7wUXZ8r9x.4q.EoZK8ei35r 4vU2PWTeFjFR22H0rw3Sll1FkC1XjTpi_er9HHNKct8BwxW57O5__BfQ4H1nfcZGJodVK6s9ZGy0 WMyWHU1fxxx0rNjaCKSMIc650C.x5P0i_p0w9vA3kRtVkCxZFsxG9D.aIMneprUBF4x8qxKe54Zw v3l4y1uG8Ee8NMSQrRNrCgP3GyAunlIY_voJJDOutlSiRaQ2.GACddPkmN0DXGdTa8NxBk1gbn1F H6xt55gY0sI9URXNS_POuT0MEkAcryMmY4Rhlxs3Mpk3EXnQWw3iEA2RjsMJJOapmhkgT9uD2aY6 NRN9YgNntcKJlk7necdDKsbOQiZyA0bPnVI9L9fmRYiXQFOSmsEChIt1M_VQnXiMvyGbkc4nk7H_ x7_7rGHti0cInjpbWuKzMEVXTC4bG4P9xg1hFdnoOPUYS9fWgsxMb5CyuoOLHGROBdmp.oiCCrfd PnPxoBBsVaCwA7DMmGKRlskIbCRm5agnas5G1qvocM..xUFmiWkscvKvFdB5E4bm7XB5_KlIlWJK Z0Xnn4u2d1twYdbtb83eFm.ACY3ILibGOuUlcTPwwk3pp4LzboVtJsAQo_uP4pcMbc1oWgFe9pOf etVpZDXK2HiAh4_64ZU46qlpkME8yhZ8RT_q__7e2Q_x1Ls7VrQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Mon, 10 Jun 2019 06:16:03 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fcd0bcfadef083087ebc234ddc7f4c70; Mon, 10 Jun 2019 06:16:00 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ? Message-Id: <1464D960-A1D6-404A-BB10-E615E2D14C1D@yahoo.com> Date: Sun, 9 Jun 2019 23:15:57 -0700 To: FreeBSD Hackers , freeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 93CEA944FC X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.16 / 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]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.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)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.947,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_MEDIUM(0.46)[0.465,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.87)[0.865,0]; RCVD_IN_DNSWL_NONE(0.00)[125.129.6.74.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[125.129.6.74.rep.mailspike.net : 127.0.0.17]; IP_SCORE(1.39)[ip: (4.27), ipnet: 74.6.128.0/21(1.53), asn: 26101(1.22), country: US(-0.06)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 06:16:12 -0000 This leads up to questioning if .sbss and .bss in /sbin/init are always correctly zeroed. But I may have missed something in the sequencing. (The code is not familiar material.) If I've tracked it down right: sys/kern/kern_exec.c uses kern_execve top deal with starting up /sbin/init. kern_execve uses do_execve. do_execve uses: /* * Each of the items is a pointer to a `const struct execsw', hence the * double pointer here. */ static const struct execsw **execsw; . . . /* * Loop through the list of image activators, calling each = one. * An activator returns -1 if there is no match, 0 on = success, * and an error otherwise. */ for (i =3D 0; error =3D=3D -1 && execsw[i]; ++i) { if (execsw[i]->ex_imgact =3D=3D NULL || execsw[i]->ex_imgact =3D=3D img_first) { continue; } error =3D (*execsw[i]->ex_imgact)(imgp); } /usr/src/sys/kern/imgact_elf.c has: /* * Tell kern_execve.c about it, with a little help from the linker. */ static struct execsw __elfN(execsw) =3D { .ex_imgact =3D __CONCAT(exec_, __elfN(imgact)), .ex_name =3D __XSTRING(__CONCAT(ELF, __ELF_WORD_SIZE)) }; EXEC_SET(__CONCAT(elf, __ELF_WORD_SIZE), __elfN(execsw)); __CONCAT(exec_, __elfN(imgact)) uses __elfN(load_sections) . __elfN(load_sections) uses __elfN(load_section). __elfN(load_section) uses vm_imgact_map_page to set up for its copyout. This appears to be how the FileSiz (not including .sbss or .bss) vs. MemSiz (including .sbss and .bss) is handled (attempted?). vm_imgact_map_page uses vm_imgact_hold_page. vm_imgact_hold_page uses vm_pager_get_pages. vm_pager_get_pages uses vm_page_zero_invalid to "Zero out partially filled data". But vm_page_zero_invalid does not zero every "invalid" byte but works in terms of units of DEV_BSIZE : void vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) { int b; int i; VM_OBJECT_ASSERT_WLOCKED(m->object); /* * Scan the valid bits looking for invalid sections that * must be zeroed. Invalid sub-DEV_BSIZE'd areas ( where the * valid bit may be set ) have already been zeroed by * vm_page_set_validclean(). */ for (b =3D i =3D 0; i <=3D PAGE_SIZE / DEV_BSIZE; ++i) { if (i =3D=3D (PAGE_SIZE / DEV_BSIZE) || (m->valid & ((vm_page_bits_t)1 << i))) { if (i > b) { pmap_zero_page_area(m, b << DEV_BSHIFT, (i - b) << = DEV_BSHIFT); } b =3D i + 1; } } /* * setvalid is TRUE when we can safely set the zero'd areas * as being valid. We can do this if there are no cache = consistancy * issues. e.g. it is ok to do with UFS, but not ok to do with = NFS. */ if (setvalid) m->valid =3D VM_PAGE_BITS_ALL; } The comment indicates that areas of "sub-DEV_BSIZE" should have been handled previously by vm_page_set_validclean . But no part of the sequence appears to use vm_page_set_validclean . So, if, say, char**environ ends up at the start of .sbss consistently, does environ always end up zeroed independently of FileSz for the PT_LOAD that spans them? The following is not necessarily an example of problematical figures but is just for showing an example structure of what FileSiz covers vs. MemSiz for PT_LOAD's that involve .sbss and .bss : Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg = Align LOAD 0x000000 0x01800000 0x01800000 0x1222dc 0x1222dc R E = 0x10000 LOAD 0x123000 0x01933000 0x01933000 0x0618c 0x32e88 RWE = 0x10000 NOTE 0x0000d4 0x018000d4 0x018000d4 0x00048 0x00048 R 0x4 TLS 0x123000 0x01933000 0x01933000 0x00b10 0x00b1d R 0x10 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 Section to Segment mapping: Segment Sections... 00 .note.tag .init .text .fini .rodata .eh_frame=20 01 .tdata .tbss .init_array .fini_array .ctors .dtors .jcr = .data.rel.ro .data .got .sbss .bss=20 02 .note.tag=20 03 .tdata .tbss=20 04 =20 There are 24 section headers, starting at offset 0x14eb20: Section Headers: [Nr] Name Type Addr Off Size ES Flg = Lk Inf Al [ 0] NULL 00000000 000000 000000 00 = 0 0 0 [ 1] .note.tag NOTE 018000d4 0000d4 000048 00 A = 0 0 4 [ 2] .init PROGBITS 0180011c 00011c 000034 00 AX = 0 0 4 [ 3] .text PROGBITS 01800150 000150 111e14 00 AX = 0 0 16 [ 4] .fini PROGBITS 01911f64 111f64 000030 00 AX = 0 0 4 [ 5] .rodata PROGBITS 01911fc0 111fc0 010318 00 A = 0 0 64 [ 6] .eh_frame PROGBITS 019222d8 1222d8 000004 00 A = 0 0 4 [ 7] .tdata PROGBITS 01933000 123000 000b10 00 WAT = 0 0 16 [ 8] .tbss NOBITS 01933b10 123b10 00000d 00 WAT = 0 0 4 [ 9] .init_array INIT_ARRAY 01933b10 123b10 000008 04 WA = 0 0 4 [10] .fini_array FINI_ARRAY 01933b18 123b18 000004 04 WA = 0 0 4 [11] .ctors PROGBITS 01933b1c 123b1c 000008 00 WA = 0 0 4 [12] .dtors PROGBITS 01933b24 123b24 000008 00 WA = 0 0 4 [13] .jcr PROGBITS 01933b2c 123b2c 000004 00 WA = 0 0 4 [14] .data.rel.ro PROGBITS 01933b30 123b30 002ee4 00 WA = 0 0 4 [15] .data PROGBITS 01936a18 126a18 002763 00 WA = 0 0 8 [16] .got PROGBITS 0193917c 12917c 000010 04 WAX = 0 0 4 [17] .sbss NOBITS 0193918c 12918c 0000b0 00 WA = 0 0 4 [18] .bss NOBITS 01939240 12918c 02cc48 00 WA = 0 0 64 [19] .comment PROGBITS 00000000 12918c 0073d4 01 MS = 0 0 1 [20] .gnu_debuglink PROGBITS 00000000 130560 000010 00 = 0 0 4 [21] .symtab SYMTAB 00000000 130570 00fc40 10 = 22 1681 4 [22] .strtab STRTAB 00000000 1401b0 00e8b3 00 = 0 0 1 [23] .shstrtab STRTAB 00000000 14ea63 0000bc 00 = 0 0 1 . . . 2652: 000000000193918c 4 OBJECT GLOBAL DEFAULT 17 environ =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)