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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > On Jul 22, 2015, at 4:53 PM, Jeff Roberson <jroberson@jroberson.net> wrote: > > On Wed, 22 Jul 2015, Mark R V Murray wrote: > >> >>> On 22 Jul 2015, at 22:42, Jeff Roberson <jroberson@jroberson.net> wrote: >>> >>> On Tue, 30 Jun 2015, Mark Murray wrote: >>> >>>> - Add harvesting of slab allocator events. This needs to be checked for >>>> weighing down the allocator code. >>> >>> 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. >> >> 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’m not sure I’m 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. >> >> 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. > > 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. > > 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’t care that much about entropy to leave performance on the table. Warner [-- Attachment #2 --] -----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-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FFFB06D7-164B-40B3-AFC3-A6630BCF074E>