From owner-freebsd-hackers@freebsd.org Tue Jun 12 18:10:18 2018 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 04FD4100E9E2 for ; Tue, 12 Jun 2018 18:10:18 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43C39727AF; Tue, 12 Jun 2018 18:10:16 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id E188F5A9F12; Tue, 12 Jun 2018 18:10:09 +0000 (UTC) Date: Tue, 12 Jun 2018 18:10:09 +0000 From: Brooks Davis To: Warner Losh Cc: Mark Johnston , "freebsd-hackers@freebsd.org" Subject: Re: specifying alignment of loader files Message-ID: <20180612181009.GA11238@spindle.one-eyed-alien.net> References: <20180612170420.GD56138@raichu> <20180612171649.GE56138@raichu> <20180612175130.GF56138@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 18:10:18 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 12, 2018 at 11:55:27AM -0600, Warner Losh wrote: > On Tue, Jun 12, 2018 at 11:51 AM, Mark Johnston wrote: >=20 > > On Tue, Jun 12, 2018 at 11:45:01AM -0600, Warner Losh wrote: > > > On Tue, Jun 12, 2018 at 11:16 AM, Mark Johnston > > wrote: > > > > > > > On Tue, Jun 12, 2018 at 11:11:25AM -0600, Warner Losh wrote: > > > > > On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm writing some code which processes a file loaded by the > > loader. I > > > > > > want the file's contents to be available at a certain alignment= in > > > > > > memory, and as far as I can see, the loader provides no alignme= nt > > > > > > guarantees today. The access will happen early enough during b= oot > > that > > > > > > making an aligned copy of the data will be awkward, so I'd like= the > > > > > > loader to provide the desired alignment. > > > > > > > > > > > > I'm considering adding a new "module_align" variable that would > > specify > > > > > > the alignment for a given file type, and plumb that through to > > > > > > command_load(). Does anyone have an alternate suggestion, or an > > > > > > objection to my proposal? > > > > > > > > > > > > > > > > I thought the loader already did that for ELF sections... Why not > > wrap > > > > your > > > > > file in such a segment? > > > > > > > > In this case it's a raw binary file (CPU microcode), and I want to = be > > > > able to load it without any modifications or wrappers. > > > > > > > > > > How do you identify the type then? I'm ok in theory with this (though= a > > > variable is more flexible than needed), but that's my main concern. > > What's > > > the alignment required btw? > > > > It'd be a property of the type, e.g., > > > > cpu_ucode_name=3D/boot/firmware/... > > cpu_ucode_align=3D16 > > > > I do feel like having a separate variable is overkill, but I can't see > > a less invasive solution that isn't hacky. > > > > The required alignment for Intel is 16 bytes; I'm not yet sure whether > > AMD has a required alignment. > > >=20 > OK. That seems sane. I was thinking it was more general than this, but I'm > cool with what you've outlined. >=20 > OTOH, wouldn't just loading all files on page boundaries suffice? Page boundaries might be too much on very small systems, but there's a principled argument for 8-bytes just based on the aligment of primative types so 16 (or even 64) isn't much of a stretch. 16-bytes would future-proof for the CHERI variants that are likely to make it to silicon. -- Brooks --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbIAyBAAoJEKzQXbSebgfApy4H/0i7/xXZV4ukxJ9QxcGZ07TP 1l25jQI5Kd0l96ERipNCZjHjnQx4/61PToVwQpx98NlIIKfYEAfLr1UxYPEUeFk6 90v/+Lvh8RV47MKXgPpv/qoRyg0R6NBUoOx//OW1/Qfz6qRwm48I5eilwQpikpAf SeiQBSW7W5dyQveh68HNox3keg0s+QeB9IXx34Neqfb4xHCcWrPgskmybkurZjXu V9gfmFcf9Uccs4XJ0qw694VH+tHiGz0x8j8JrtUmomglbVExxdfJzmhXaJw3H0G2 A57UcJIrCG5uyGuqjDrbOft/0q5zUCvrKeELHZmSyLccSP+xhcQ4tZo9vOVGZjg= =ZGER -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY--