On Wednesday, September 19, 2012 6:08:19 pm David O'Brien wrote: > Also, I'm having trouble finding the source for 'swi' harvesting. > Do you know where it is? It has certainly not been used since 5.0. I wasn't able to find it in my limited grubbing around in 4.x sources either. The untested change below would add it so that all calls to swi_sched() would harvest something similar to what happens for hardware interrupts. Note that the current code already explicitly forbids INTR_ENTROPY from being set for swi handlers, so the current random_harvest() call in intr_schedule_thread() should never trigger for an swi. I just copied the random_harvest() code from the hardware interrupt case. I leave it up to someone else to explicitly ok that this data goes into the RANDOM_INTERRUPT queue with the claim of 2 bits of entropy: Index: sys/kern/kern_intr.c =================================================================== --- kern_intr.c (revision 240605) +++ kern_intr.c (working copy) @@ -1144,11 +1144,21 @@ swi_sched(void *cookie, int flags) { struct intr_handler *ih = (struct intr_handler *)cookie; struct intr_event *ie = ih->ih_event; + struct intr_entropy entropy; int error; CTR3(KTR_INTR, "swi_sched: %s %s need=%d", ie->ie_name, ih->ih_name, ih->ih_need); + if (harvest.swi) { + CTR3(KTR_INTR, "swi_sched: pid %d (%s) gathering entropy", + curproc->p_pid, curthread->td_name); + entropy.event = (uintptr_t)ih; + entropy.td = curthread; + random_harvest(&entropy, sizeof(entropy), 2, 0, + RANDOM_INTERRUPT); + } + /* * Set ih_need for this handler so that if the ithread is already * running it will execute this handler on the next pass. Otherwise, -- John Baldwin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"