From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967914Ab3HIPdE (ORCPT ); Fri, 9 Aug 2013 11:33:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56886 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965247Ab3HIPcu (ORCPT ); Fri, 9 Aug 2013 11:32:50 -0400 Date: Fri, 9 Aug 2013 11:32:26 -0400 From: Vivek Goyal To: Matthew Garrett Cc: "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] kexec: Disable at runtime if the kernel enforces module signing Message-ID: <20130809153225.GH12688@redhat.com> References: <1376033797-24970-1-git-send-email-matthew.garrett@nebula.com> <20130809110200.GA9631@redhat.com> <1376060830.2021.12.camel@x230> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1376060830.2021.12.camel@x230> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 09, 2013 at 03:07:13PM +0000, Matthew Garrett wrote: > On Fri, 2013-08-09 at 07:02 -0400, Vivek Goyal wrote: > > On Fri, Aug 09, 2013 at 03:36:37AM -0400, Matthew Garrett wrote: > > > kexec permits the loading and execution of arbitrary code in ring 0, which > > > is something that module signing enforcement is meant to prevent. It makes > > > sense to disable kexec in this situation. > > > > > > > But in the process we wipe out running kernel's context and boot into a new > > kernel. So how different it is than root booting a new kernel through BIOS > > which does not enforce module signing. > > What wipes the current kernel's context? KEXEC_JUMP is explicitly > designed to allow you to hop back and forth, but even without it you > should be able to reconstruct the original context. And there's no need > to boot a new kernel, either. All the attacker needs is the physical > address of the sig_enforce boolean, and then they launch a simple kexec > payload that simply flips that back and returns to the original kernel - > it's not like kexec limits you to booting Linux. > > > Also it would be nice if we introduce new features, then we make other > > features work with those new features instead of disabling existing > > features and leave it to other people to make them work. > > Sure, it'd be nice if security features got introduced with > consideration to other kernel features that allow them to be > circumvented, but this approach seems better than making them > incompatible at the Kconfig level. So how would one go about making kexec work when module signature enforcement is on? I guess same solution which is required to make it work with secureboot. Sign /sbin/kexec and let /sbin/kexec very signature of kernel. IOW, any code which runs at priviliged level should be signature verified with keys in system_keyring. Thanks Vivek