Date: Thu, 6 Sep 2012 19:31:08 -0600 From: Warner Losh <imp@bsdimp.com> To: obrien@freebsd.org Cc: Arthur Mesh <arthurmesh@gmail.com>, Ian Lepore <freebsd@damnhippie.dyndns.org>, Doug Barton <dougb@freebsd.org>, freebsd-rc@freebsd.org, freebsd-security@freebsd.org Subject: Re: svn commit: r239598 - head/etc/rc.d Message-ID: <1A362209-58C1-47A0-A10D-F68359051312@bsdimp.com> In-Reply-To: <20120906190239.GG13179@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <1346951961.59094.158.camel@revolution.hippie.lan> <20120906190239.GG13179@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 6, 2012, at 1:02 PM, David O'Brien wrote: > On Thu, Sep 06, 2012 at 11:19:21AM -0600, Ian Lepore wrote: >> The kenv application may be available, but on any platform that >> lacks /boot/loader it's likely to produce empty output. Because the >> kernel environment is typically empty, an embedded system may not = even >> have the kenv binary installed. =20 >=20 > The FreeBSD kernel expects to be loaded by /boot/loader and for it to > provided a suitable environment. >=20 > If one has chosen to not use /boot/loader (or include 'kenv' on their > embedded boot media), they're already gone so far down the path of > customization that hacking 'initrandom' should be expected. Really? I don't think so. Most of the ARM and MIPS ports can't be = loaded by /boot/loader, the notable exception being the Marvell ARM = stuff. And even if they were, they lack the code to get the metadata = blobs you need to recover the kenv. It is typical in the embedded space = not to be loaded by /boot/loader. Your gear from $WORK is atypical = here. Besides, kenv typically is static for any given machine, so is = not a good 'randomization' vector. >> I should note that I don't think the needs of embedded systems should >> carry so much weight in this discussion that it leads to jumping = through >> major hoops. >=20 > :-) >=20 >> I think the most important point would be "Let failures be >> soft ones" -- things you may think of as basic tools always available = on >> a minimal installation may not be there on a stripped down embedded >> system; no big deal, just don't hang the system or anything else dire = in >> that case. >=20 > I think that just adds to needless cruft in /etc/rc.d scripts that is > hard to test and keep working -- as committers will 99.9999% time be > in a full FreeBSD environment. >=20 > I don't want to see every command in better_than_nothing() turn into > "test -x ___ && ___". Since kenv is a bad source of entropy, I'm kinda guessing this is moot. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A362209-58C1-47A0-A10D-F68359051312>