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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170330032528.GT43712>