From owner-freebsd-ppc@freebsd.org Mon Jun 10 14:37:30 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 8DD9715C0D7A; Mon, 10 Jun 2019 14:37:30 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DD23760FB; Mon, 10 Jun 2019 14:37:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f179.google.com with SMTP id m3so13629830itl.1; Mon, 10 Jun 2019 07:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=K+bRhC4gixUlUgBIyTPWieIOkecQGcFgRpJlZAizZvk=; b=nbjZlvJ31VKE/7ZJ28GMrZ3RhwrAULI2VFJbWkoQ4ktbteJXkNXkZKpju3s8ayEovS mBmOBJemKO1kUeNBdNYfabNDzU09u6Ztcd5N9MKUUQYIVEDazKhq4+Dz9vXj8ZJoAof0 PLELsVwtkcT4rwHSpixU3V6ZBsz1MXcE2VhKtS3FgTrI7PYH8BxdnDRaqxLlePjWMx0v 86lfy3ypOWHxShrgCz2j4z7JTiqTxellY7DRpPoCHWgaJaCck6jWkpX4nLQOftScdtD1 ZTGYT6vp8+ocIGHwUpyAVIDFTUOjJuw2bfYQ11Luuhdyvmn3OrUdCgi85Mw0VGB5Ssbs cyYg== X-Gm-Message-State: APjAAAXCtILqf7+csKf5/wfy/szsCXqpGiJ0Zjjj9fwJzuzwRezqtdrf CuMuiXsDIbHrtBrMxhkGl4hmzUN2 X-Google-Smtp-Source: APXvYqyTDc0eYM8I6wf+c+OyCaO+7SrKn8hwB7hru5oBCHfdKz9tswSzUPaZ+3oR0h/GLMOgw1cKEA== X-Received: by 2002:a24:240c:: with SMTP id f12mr14071978ita.14.1560177443082; Mon, 10 Jun 2019 07:37:23 -0700 (PDT) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id m129sm4957061itd.6.2019.06.10.07.37.22 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 07:37:22 -0700 (PDT) Received: by mail-it1-f182.google.com with SMTP id m187so13627998ite.3; Mon, 10 Jun 2019 07:37:22 -0700 (PDT) X-Received: by 2002:a24:a43:: with SMTP id 64mr14907281itw.100.1560177442118; Mon, 10 Jun 2019 07:37:22 -0700 (PDT) MIME-Version: 1.0 References: <1464D960-A1D6-404A-BB10-E615E2D14C1D@yahoo.com> In-Reply-To: <1464D960-A1D6-404A-BB10-E615E2D14C1D@yahoo.com> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 10 Jun 2019 07:37:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ? To: Mark Millard Cc: FreeBSD Hackers , freeBSD PowerPC ML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7DD23760FB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; IP_SCORE(-2.55)[ip: (-6.98), ipnet: 209.85.128.0/17(-3.40), asn: 15169(-2.28), country: US(-0.06)]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; 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]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[] 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: Mon, 10 Jun 2019 14:37:30 -0000 Hi Mark, On Sun, Jun 9, 2019 at 11:17 PM Mark Millard via freebsd-hackers wrote: > ... > 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 : > ... > The comment indicates that areas of "sub-DEV_BSIZE" > should have been handled previously by > vm_page_set_validclean . Or another VM routine, yes (e.g., vm_page_set_valid_range). The valid and dirty bitmasks in vm_page only have a single bit per DEV_BSIZE region, so care must be taken when marking any sub-DEV_BSIZE region as valid to zero out the rest of the DEV_BSIZE region. This is part of the VM page contract. I'm not sure it's related to the BSS, though. > 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? It is required to be zeroed, yes. If not, there is a bug. If FileSz covers BSS, that's a bug in the linker. Either the trailing bytes of the corresponding page in the executable should be zero (wasteful; on amd64 ".comment" is packed in there instead), or the linker/loader must zero them at initialization. I'm not familiar with the particular details here, but if you are interested I would suggest looking at __elfN(load_section) in sys/kern/imgact_elf.c. > 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 : > ... Your 2nd LOAD phdr's FileSiz matches up exactly with Segment .sbss Offset minus Segment .tdata Offset, i.e., none of the FileSiz corresponds to the (s)bss regions. (Good! At least the static linker part looks sane.) That said, the boundary is not page-aligned and the section alignment requirement is much lower than page_size, so the beginning of bss will share a file page with some data. Something should zero it at image activation. (Tangent: sbss/bss probably do not need to be RWE on PPC! On amd64, init has three LOAD segments rather than two: one for rodata (R), one for .text, .init, etc (RX); and one for .data (RW).) Best, Conrad