Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750991AbdHQFKO (ORCPT ); Thu, 17 Aug 2017 01:10:14 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:37934 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750738AbdHQFKN (ORCPT ); Thu, 17 Aug 2017 01:10:13 -0400 Message-ID: <1502946611.3986.48.camel@gmail.com> Subject: Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline From: Daniel Micay To: Kees Cook , Nick Kralevich Cc: Laura Abbott , "kernel-hardening@lists.openwall.com" , lkml , Linux-MM , Andrew Morton Date: Thu, 17 Aug 2017 01:10:11 -0400 In-Reply-To: References: <20170816224650.1089-1-labbott@redhat.com> <20170816224650.1089-3-labbott@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1661 Lines: 40 On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote: > On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich > wrote: > > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott > > wrote: > > > From: Daniel Micay > > > > > > Existing Android bootloaders usually pass data useful as early > > > entropy > > > on the kernel command-line. It may also be the case on other > > > embedded > > > systems. Sample command-line from a Google Pixel running > > > CopperheadOS: > > > > > > > Why is it better to put this into the kernel, rather than just rely > > on > > the existing userspace functionality which does exactly the same > > thing? This is what Android already does today: > > https://android-review.googlesource.com/198113 > > That's too late for setting up the kernel stack canary, among other > things. The kernel will also be generating some early secrets for slab > cache canaries, etc. That all needs to happen well before init is > started. > > -Kees > It's also unfortunately the kernel's global stack canary for the entire boot since unlike x86 there aren't per-task canaries. GCC / Clang access it via a segment register on x86 vs. a global on other architectures. In theory it could be task-local elsewhere but doing it efficiently would imply reserving a register to store the random value. I think that may actually end up helping performance more than it hurts by not needing to read the global stack canary value from cache repeatedly. If stack canaries were augmented into something more (XOR in the retaddr and offer the option of more coverage than STRONG) it would be more important.