Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754857AbbFONhN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 15 Jun 2015 09:37:13 -0400
Received: from mail-ig0-f182.google.com ([209.85.213.182]:33026 "EHLO
	mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753292AbbFONhF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 15 Jun 2015 09:37:05 -0400
MIME-Version: 1.0
In-Reply-To: <20150615131728.GK15793@thunk.org>
References: <20150615035051.GA2634@thunk.org>
	<CA+5PVA6t_dEQt1M7HkeHy9znFkPd-a7525vtFq-g4a6VKL+gLQ@mail.gmail.com>
	<20150615131728.GK15793@thunk.org>
Date: Mon, 15 Jun 2015 09:37:05 -0400
X-Google-Sender-Auth: wfK5CF-CfbiMRqxOFZzOAi8bHPI
Message-ID: <CA+5PVA6YKR_=uVpM2rW4et3YCJLh9c+uuxt2koH1Fy2ZuR7W-g@mail.gmail.com>
Subject: Re: kexec_load(2) bypasses signature verification
From: Josh Boyer <jwboyer@fedoraproject.org>
To: "Theodore Ts'o" <tytso@mit.edu>, Eric Biederman <ebiederm@xmission.com>,
        David Howells <dhowells@redhat.com>, kexec <kexec@lists.infradead.org>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1945
Lines: 40

On Mon, Jun 15, 2015 at 9:17 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
>> Yes, which is why most of the distro vendors carry an out-of-tree
>> patch that disables the old kexec in an SB setup.  It would be nice if
>> we could merge said patches.  However, they depend on Matthew's
>> secure_modules/trusted_kernel/<whatever name that works> patchset
>> which has gotten little movement since we came up with a tentative
>> agreement at LPC 2013.
>
> Signed modules is in, though, right?  And the fact that we have

Yes.

> CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
> signatures w/o using ELF, which I thought was the basis of Linus's
> accusation that Red Hat was performing intimate/physical acts with
> Microsoft.  :-)
>
> I would have thought those were the nasty bits to get in; out of
> curiosity, what's still missing?

The bits that actually read Secure Boot state out of the UEFI
variables, and apply protections to the machine to avoid compromise
under the SB threat model.  Things like disabling the old kexec,
enforcing module signatures at runtime, restricting various access
(like /dev/mem, /dev/kmem), adding certs in UEFI db to the system
keyring, and enforcing the UEFI dbx blacklist.  So most of the patches
in Matthew's set relate to enforcement using the bits of functionality
already merged.  They aren't even strictly tied to UEFI or SB, but
some of the other patches distos carry are.  We had tentative
agreement even from Linus on much of this (his words were along the
lines of "create a flag and use the flag"), but it's failed to
actually get carried in any tree for a few reasons.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/