From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 14E4AAF7 for ; Tue, 6 May 2014 13:16:58 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BF53A1FDEC for ; Tue, 6 May 2014 13:16:57 +0000 (UTC) Date: Tue, 6 May 2014 09:16:48 -0400 From: Dave Jones To: Jiri Kosina Message-ID: <20140506131648.GA16222@redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, May 06, 2014 at 09:05:53AM +0200, Jiri Kosina wrote: > On Mon, 5 May 2014, Kees Cook wrote: > > > I'm very interested in this, especially as it may relate to security > > exploit mitigation work, both in the sense of being able to arbitrarily > > patch the kernel against flaws, and to defend against attackers being > > able to ... er ... arbitrarily patch the kernel... :) > > :) Well, for performing the patching, the attacker would either have to be > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel > (criu-based solution). In either case, the system would be owned anyway > already, independently on any live patching mechanism. being root doesn't mean "can patch the kernel" if in secure boot mode. (Or at least is going to need special considerations regarding signing). Dave