lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20151007075339.GG17172@x1> Date: Wed, 7 Oct 2015 08:53:39 +0100 From: Lee Jones <lee.jones@...aro.org> To: Russell King - ARM Linux <linux@....linux.org.uk> Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, peter@...sgaard.com, kernel@...inux.com, daniel.thompson@...aro.org, pankaj.dev@...com, festevam@...il.com, herbert@...dor.apana.org.au Subject: Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout On Tue, 06 Oct 2015, Russell King - ARM Linux wrote: > On Tue, Oct 06, 2015 at 09:51:22PM +0100, Lee Jones wrote: > > On Tue, 06 Oct 2015, Russell King - ARM Linux wrote: > > > On Tue, Oct 06, 2015 at 03:44:00PM +0100, Lee Jones wrote: > > > > Samples are documented to be available every 0.667us, so in theory > > > > the 8 sample deep FIFO should take 5.336us to fill. However, during > > > > thorough testing, it became apparent that filling the FIFO actually > > > > takes closer to 12us. > > > > > > Is that measured? > > > > I measured it using ktime. Hopefully that was adequate. > > > > > > +/* > > > > + * Samples are documented to be available every 0.667us, so in theory > > > > + * the 8 sample deep FIFO should take 5.336us to fill. However, during > > > > + * thorough testing, it became apparent that filling the FIFO actually > > > > + * takes closer to 12us. > > > > + */ > > > > +#define ST_RNG_FILL_FIFO_TIMEOUT 12 > > > > > > I hope you're not using such a precise figure with udelay(). udelay() > > > is not guaranteed to give exactly (or even at least) the delay you > > > request. It's defined to give an approximate delay. > > > > > > Many people have a problem understanding that, so I won't explain why > > > it is that way, just accept that it is and move on... it's not going > > > to magically get "fixed" because someone has just learnt about this. :) > > > > Thanks for the info. I did do testing, again using ktime, to make > > sure and on our platform (is it platform specific?) I measured > > udelay(1) to be ~1100ns. After moving to a 12us timeout and reading > > many MBs of randomness I am yet to receive any more timeouts. > > If you happen to fall back to the software timing loop, udelay(1) will not > be >=1us anymore, but will be slightly shorter. > > That's because the loops_per_jiffy value is calculated as the number of > loops between each timer interrupt - so the period being measured is the > timer period, minus the time it takes for the timer interrupt to run. > The latter is indeterminant. Consequently, the loops_per_jiffy estimate > is always slightly under the real number of loops-per-jiffy, so delays > generated by udelay() and friends will always be slightly short. > > The faster your HZ value, the bigger the error. The longer the interrupt > handler takes, the bigger the error. Thanks for taking the time to explain. > IIRC, Linus recommends a x2 factor on delays, especially timeouts generated > by these functions. In this implementation it shouldn't matter too much either way. Even when the timeouts were prolific, bandwidth was not reduced due to the quick turn-round of the subsystem. I don't foresee any impact on bandwidth if we were to raise the timeout either; in fact, I doubt we'd ever see a timeout again. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists