The linux kernel also has a shared DMA buffer system which might be able to
help with that latency, but that is a good point nonetheless.
Latency could probably also be helped further by splitting that procedure into
a collector and a processor/output function, to keep the overhead on DMA buffer
usage to a minimum. It'd have to use a little more memory as the tradeoff, and
preallocate that as much as possible to avoid losing that again on allocation,
but that'd probably be acceptable in most cases if implemented relatively
conservatively.
On May 9, 2016 3:16:34 PM PDT, Russell Leidich <pke...@gmail.com> wrote:
>"Interrupts don't need to be polled in a loop in the kernel, though. As
>long as the interrupt handler being used to collect the data is quick
>enough, it wouldn't necessarily need to be resource intensive. There
>are
>only going to be 15 or 24 interrupt lines on most x86 systems, anyway.
>All
>else being equal, such an interrupt handler in the kernel would
>actually
>probably hog less CPU cycles than it would in userspace just because it
>doesn't need to poll at all for that information."
>
>Correct, interrupts do not require polling (except in weird
>circumstances
>not relevant here). The tight loop I was referring to is required to
>extract randomness from DMA bursts to or from main memory by sampling
>the
>timedelta stream during said bursts. It's not really a polling loop
>because
>it's not waiting for anything to finish, but it creates a similar
>latency
>bottleneck because it must gather enough entropy before issuing an
>output.
>Nevertheless, doing so should be much faster than relying on interrupt
>timing alone. In principle, the latency could be truncated by doing
>little
>bursts here and there in between userspace time slices.
>
>Before you say this is all crap... The timedelta stream (and more
>simply,
>its histogram) is quite informative. At one point, I was able to
>determine
>that I was browsing the internet just by using timedeltaprofile. On
>further
>investigation, I found that I could identify which website I was
>looking at
>using a sufficent number of timedelta samples. I could even tell _which
>company_ I was reading about on a particular investment website,
>probably
>due to the characteristic differences in latency spikes between the
>pages
>in question. (I had to train myself on the histograms first, of course,
>so
>you couldn't use this as an attack if you knew nothing about the
>website
>being visited. It also required profiling during load, not after load.)
>This was all done from an orthogonal userspace with no kernel access.
>Spooky! Someone needs to virtualize userspace timestamp access before
>this
>becomes a problem, but I'm not holding my breath. I'm by no means the
>first
>person to discover this sort of thing, either. There are plenty of
>similar
>issues with Java or Javascript, for example.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>cryptography mailing list
>cryptography@randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography
--
Michael Greene
Software Engineer
mgre...@securityinnovation.com
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
