Re: svn commit: r239598 - head/etc/rc.d

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=
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"