From owner-freebsd-security@FreeBSD.ORG Thu Sep 20 17:47:01 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE44D106566B; Thu, 20 Sep 2012 17:47:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEF908FC0C; Thu, 20 Sep 2012 17:47:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07A44B982; Thu, 20 Sep 2012 13:47:01 -0400 (EDT) From: John Baldwin To: freebsd-security@freebsd.org, obrien@freebsd.org Date: Thu, 20 Sep 2012 08:44:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120919220819.GB25606@dragon.NUXI.org> In-Reply-To: <20120919220819.GB25606@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209200844.10470.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 20 Sep 2012 13:47:01 -0400 (EDT) Cc: Arthur Mesh , Ian Lepore , Doug Barton , Ben Laurie , RW Subject: Re: Proposed fix; stage 1 (Was: svn commit: r239569 - head/etc/rc.d) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:47:02 -0000 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