From owner-freebsd-hackers@freebsd.org Thu Mar 30 03:25:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98986D17918; Thu, 30 Mar 2017 03:25:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0ACF769C; Thu, 30 Mar 2017 03:25:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2U3PSAv094977 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 06:25:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2U3PSAv094977 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2U3PSPq094976; Thu, 30 Mar 2017 06:25:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Mar 2017 06:25:28 +0300 From: Konstantin Belousov To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <20170330032528.GT43712@kib.kiev.ua> References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 03:25:34 -0000 On Mon, Mar 27, 2017 at 01:54:44PM -0400, Eric McCorkle wrote: > As background, the ELF file format has a number of different section > types, only some of which comprise the program/library/module's runtime > state. The ELF specification and tools provide some "standard" sections > with defined meanings, but nothing stops anyone from adding their own > sections. The ELF file format is quite flexible, and it is not > difficult to add custom metadata to an ELF file. [0] > > In this proposal, cryptographic signatures would be stored in a > .signature (or .sig) section. This section would contain an array of > signature constructs: one for each loadable segment in the ELF file. > Signatures are computed for the contents of the segment's file data (ie. > the data from p_offset to p_filesz, for the corresponding program header > entry) along with all data from its program header entry except for > p_offset and p_filesz. This scheme allows the actual data to be moved > around in the file, so long as it (or the relevant program header data) > isn't modified. First, you mix or do not understand a difference between section and segment. Second, this scheme allows to add loadable segments after signing. Third, most important, it has zero chances of working for amd64 modules.