From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 17 02:50:09 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F37482DA for ; Fri, 17 Apr 2015 02:50:09 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id DE8A2E17 for ; Fri, 17 Apr 2015 02:50:09 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3H2o9ot013486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 16 Apr 2015 19:50:09 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <553074DE.4070106@rawbw.com> Date: Thu, 16 Apr 2015 19:50:06 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: Is it possible to check the running kernel signature? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 02:50:10 -0000 I came across this horror story: https://pbs.twimg.com/media/Bd7LUMYCMAAJcqJ.jpg Three letter agencies subverted the BIOS manufacturers to produce BIOSes that were/are able to inject the malicious code right into the FreeBSD kernel during the final BIOS boot stage. This may well be going on with the modern FreeBSD versions. The idea that comes to mind is the ability to verify that the running kernel wasn't tampered with by comparing it with its disk image copy. Same with the kernel modules. Kernel can be verified through the memory mmapped to /dev/mem device. Is this idea feasible, and would it make sense to implement it? Yuri