Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753947AbdLGO1s (ORCPT ); Thu, 7 Dec 2017 09:27:48 -0500 Received: from www.llwyncelyn.cymru ([82.70.14.225]:56490 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753445AbdLGO1p (ORCPT ); Thu, 7 Dec 2017 09:27:45 -0500 Date: Thu, 7 Dec 2017 14:26:57 +0000 From: Alan Cox To: Gary Lin Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "H. Peter Anvin" , Thomas Gleixner , Ard Biesheuvel , Ingo Molnar , Matt Fleming , Catalin Marinas , Will Deacon , Joey Lee Subject: Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub Message-ID: <20171207142657.52e1363a@alans-desktop> In-Reply-To: <20171205100148.5757-1-glin@suse.com> References: <20171205100148.5757-1-glin@suse.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1176 Lines: 28 On Tue, 5 Dec 2017 18:01:46 +0800 Gary Lin wrote: > The series of patches introduce Security Version to EFI stub. > > Security Version is a monotonically increasing number and designed to > prevent the user from loading an insecure kernel accidentally. The > bootloader maintains a list of security versions corresponding to > different distributions. After fixing a critical vulnerability, the > distribution kernel maintainer bumps the "version", and the bootloader > updates the list automatically. This seems a mindbogglingly complicated way to implement something you could do with a trivial script in the package that updates the list of iffy kernels and when generating the new grub.conf puts them in a menu of 'old insecure' kernels. Why do you even need this in the EFI stub ? What happens if you want to invalidate an old kernel but not push a new one ? Today if you've got a package that maintains the list of 'iffy' kernels you can push a tiny package, under your scheme you've got to push new kernels which is an un-necessary and high risk OS change. It just feels like an attempt to solve the problem in completely the wrong place. Alan