From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CWJpi-0008Kv-Vw for qemu-devel@nongnu.org; Mon, 22 Nov 2004 14:26:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CWJph-0008KP-Sz for qemu-devel@nongnu.org; Mon, 22 Nov 2004 14:26:42 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CWJph-0008KE-Ln for qemu-devel@nongnu.org; Mon, 22 Nov 2004 14:26:41 -0500 Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CWJgb-000053-WA for qemu-devel@nongnu.org; Mon, 22 Nov 2004 14:17:18 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CWJga-0008R9-00 for ; Mon, 22 Nov 2004 20:17:16 +0100 Received: from c-24-6-66-193.client.comcast.net ([24.6.66.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 20:17:16 +0100 Received: from blp by c-24-6-66-193.client.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 20:17:16 +0100 From: Ben Pfaff Date: Mon, 22 Nov 2004 11:17:12 -0800 Message-ID: <87is7x4rt3.fsf@benpfaff.org> References: <87oehpn42u.fsf@benpfaff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: news Subject: [Qemu-devel] Re: valgrind functionality in qemu? Reply-To: blp@cs.stanford.edu, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Johannes Schindelin writes: > Unfortunately, you didn't publish the source code for TaintBochs. It's not very pretty. We're working on a nicer version that we might release later. > So how did you tackle following problems: > > - when deciding what to taint, you want to be as specific as possible. How > did you tell bochs what was tainted, and what not? This isn't really relevant for the purpose of doing valgrind-like functionality, for what it's worth. However, we used various methods. For example, for tainting passwords input from the keyboard we added a toggle switch to the Bochs interface that determined whether keypressed were considered tainted, and for tainting network input we did a simple string search in network packets (which is not very smart but worked okay for the simple case we wanted to try). > - when you tested inside bochs, you didn't have control over loading of > programs. How did bochs know where the code came from? We used Mission Critical's "crash" utility as a kernel debugger. We added a module to it that allowed us to generate a core dump of any process in the guest. When you combine a core dump with the program binary and the program source, gdb and addr2line can tell you everything you want to know. > - even more importantly, when you analyzed where tainting data was > propagated or freed, how did you find out which *source code* was > responsible for that? gdb and addr2line as above. I think all this is in the paper actually. We included a fair number of details of our implementation there. > I would do tha "just write some code" part, but I still look for > elegant solutions to those problems. -- "The road to hell is paved with convenient shortcuts." --Peter da Silva