Date: Thu, 30 Mar 2017 06:25:28 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Eric McCorkle <eric@metricspace.net> Cc: "freebsd-hackers@freebsd.org" <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> In-Reply-To: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170330032528.GT43712>