Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031913AbdDTXVE (ORCPT ); Thu, 20 Apr 2017 19:21:04 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:33895 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S948022AbdDTXVB (ORCPT ); Thu, 20 Apr 2017 19:21:01 -0400 X-Greylist: delayed 445 seconds by postgrey-1.27 at vger.kernel.org; Thu, 20 Apr 2017 19:21:00 EDT X-ME-Sender: X-Sasl-enc: xP7y0FdIqDhm7iu/IQAcVTpGPs3LTDY+djDLiTAxnZ62 1492730014 Date: Thu, 20 Apr 2017 20:13:32 -0300 From: Henrique de Moraes Holschuh To: Mehmet Kayaalp Cc: David Howells , David Woodhouse , keyrings , LSM , kernel , Mimi Zohar , Stefan Berger , George Wilson Subject: Re: [PATCH v4 1/4] KEYS: Insert incompressible bytes to reserve space in bzImage Message-ID: <20170420231332.GA10262@khazad-dum.debian.net> References: <1492727320-26194-1-git-send-email-mkayaalp@linux.vnet.ibm.com> <1492727320-26194-2-git-send-email-mkayaalp@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1492727320-26194-2-git-send-email-mkayaalp@linux.vnet.ibm.com> X-GPG-Fingerprint1: 4096R/0x0BD9E81139CB4807: C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1088 Lines: 24 On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > Include a random filled binary in vmlinux at the space reserved with > CONFIG_SYSTEM_EXTRA_CERTIFICATE. This results in an uncompressed reserved Random data is not always going to be completely incompressible. And just how much it could be compressed also depends on the compression engine. Failures here would be quite annoying, even if they would be rare (not just due to the randomness factor, but also depending on just how overprovisioned the space reserved for the extra certificate was when compared with the real certificate size). Maybe it would be safer if you test it for incompressability once you generated the random data (using the same compression engine that the image will use)? If it fails, add some overprovisioning and retry... Alternatively, you could ship a static file with random data that has been tested to be uncompressible "enough" for every currently supported compression engine, maybe with a bit of a safety margin just in case a future compression engine does somewhat better... -- Henrique Holschuh