Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jul 2015 17:53:42 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        Mark R V Murray <markm@FreeBSD.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy...
Message-ID:  <FFFB06D7-164B-40B3-AFC3-A6630BCF074E@bsdimp.com>
In-Reply-To: <alpine.BSF.2.20.1507221249120.1071@desktop>
References:  <201506301700.t5UH0jPq001498@svn.freebsd.org> <alpine.BSF.2.20.1507221138360.1071@desktop> <FFAED695-145A-45F5-988D-B843EF5F544B@FreeBSD.org> <alpine.BSF.2.20.1507221249120.1071@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_76E4302A-79D1-46EF-8931-F01E6A8CEF5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 22, 2015, at 4:53 PM, Jeff Roberson <jroberson@jroberson.net> =
wrote:
>=20
> On Wed, 22 Jul 2015, Mark R V Murray wrote:
>=20
>>=20
>>> On 22 Jul 2015, at 22:42, Jeff Roberson <jroberson@jroberson.net> =
wrote:
>>>=20
>>> On Tue, 30 Jun 2015, Mark Murray wrote:
>>>=20
>>>> - Add harvesting of slab allocator events. This needs to be checked =
for
>>>>  weighing down the allocator code.
>>>=20
>>> Neither filesystem operations nor allocations are random events.  =
They are trivially influenced by user code.  A malicious attacker could =
create repeated patterns of allocations or filesystem activity through =
the syscall path to degrade your random sample source.
>>=20
>> I?m not sure I accept that - Fortuna is very careful about using =
non-reversible hashing in it?s accumulation, and countering such =
degradation is one of the algorithm?s strong points. There is perhaps =
risk of *no* entropy, but even the per-event timing jitter will be =
providing this, if nothing else.

I=E2=80=99m not sure I=E2=80=99m happy about this answer. Do you have =
some research backing up such cavalier claims?

>>> Perhaps more importantly to me, this is an unacceptable performance =
burden for the allocator.  At a minimum it should compile out by =
default. Great care has been taken to reduce the fast path of the =
allocator to the minimum number of cycles and even cache misses.
>>=20
>> As currently set up in etc/rc.d/* by default, there is a simple check =
at each UMA harvesting opportunity, and no further action. I asked =
Robert Watson if this was burdensome, and he said it was not.
>=20
> I find this burdensome.  You can easily add a macro around the calls =
or hide them in an inline with a default to off.  Even a function call =
that checks a global and does nothing else is a handful of new cache =
misses.  A microbenchmark will not realize the full cost of this.  You =
will instead get the dozen or so instructions of overhead which I still =
find objectionable.
>=20
> Kip's observations about packet cycle budgets in high-performance =
applications are accurate and this is something we have put great care =
into over time.

A certain video streaming company will be pushing the envelope to get to =
100Gbps very soon. Even a few extra instructions on every packet / =
allocation will be a killer. Especially if one is an almost guaranteed =
cache miss. This most certainly will be burdensome. There absolutely =
must be a way to turn this off at compile time. We don=E2=80=99t care =
that much about entropy to leave performance on the table.

Warner

--Apple-Mail=_76E4302A-79D1-46EF-8931-F01E6A8CEF5D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVsC0GAAoJEGwc0Sh9sBEABMoP/RS5nLpQWvFqcEvQxigQEJrz
nckGYKi9B849tjPIgfQnHbgrSLaME8IacCVLIE44UO3d3pAUd/xchKbY26ZNuTuO
1oVzxHDYyJ1IUYWBU2PYFe2LE87UkX7xf/Xd8M6i/2h5vxVhzWgQXm9XiKbiOLJm
TDUoMs8UIRmNlGgdc6a9fPTxrhUjfLH1Bf5tPa7htln0hfKqu7wshC4M7NyVf6Y5
ylDv6gwbUiU8qHYGLxss7A/9Q9u4T7ShG+YX2+R5+k+MkDM914MgEHA2HT7mTdGA
K4vaudFO2Rzr5dWfO9kLTY/TjphNB56XhQdHsF4sIvvpsLGaZvSNsRsLdkzhZmhn
fF6gM+zuaZktxNl+aBjpZ+l36MWCfZLrgW2wlJenlAFfxMVoRqTWTMTQPkmKk/tA
ycPBXdkNUeUbCzvOzsQJ5jBf+B328tqMvuYCeGwiFgtWrTO477fWUCzU1Q73Rvs6
JH4M5t7SVb6tj26U11msxZWbq7j3ceCmNR2DKrxCKooTytSmKL/wun754+UWdzje
q/QWpe5XvPlx949bZ89liWEDE+nqMn4RIQYh8Ep9Vz6pox3QIr+zKIEk+JrQWDVF
phdmv0TB1C765Me6Yz3CX3iWrMd2S9IxWWr1NWnr9Nx+3lduxLNJTf/6RKqZxn6O
crtholQuf7YtE61UsTC7
=5VD9
-----END PGP SIGNATURE-----

--Apple-Mail=_76E4302A-79D1-46EF-8931-F01E6A8CEF5D--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FFFB06D7-164B-40B3-AFC3-A6630BCF074E>