mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: yinghai@kernel.org, keescook@chromium.org, hpa@zytor.com,
	mingo@redhat.com, bp@alien8.de, vgoyal@redhat.com,
	luto@kernel.org, lasse.collin@tukaani.org,
	akpm@linux-foundation.org, dyoung@redhat.com,
	Baoquan He <bhe@redhat.com>
Subject: [PATCH v4 05/20] x86, kaskr: Update the description for decompressor worst case
Date: Tue, 22 Mar 2016 15:32:02 +0800	[thread overview]
Message-ID: <1458631937-14593-6-git-send-email-bhe@redhat.com> (raw)
In-Reply-To: <1458631937-14593-1-git-send-email-bhe@redhat.com>

Current analysis is only for gzip decompressor only. In fact we can
support 6 different decompressor. Update the description to cover
all of them. Meanwhile fix several typos.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 arch/x86/boot/compressed/misc.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index e2a998f..e7c6fdf 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -19,11 +19,13 @@
  */
 
 /*
- * Getting to provable safe in place decompression is hard.
- * Worst case behaviours need to be analyzed.
- * Background information:
+ * Getting to provable safe in place decompression is hard. Worst case
+ * behaviours need be analyzed. Here let's take decompressing gzip-compressed
+ * kernel as example to illustrate it.
+ *
+ * The file layout of gzip compressed kernel is as follows. For more information,
+ * please refer to rfc 1951 and rfc 1952.
  *
- * The file layout is:
  *    magic[2]
  *    method[1]
  *    flags[1]
@@ -70,13 +72,13 @@
  * of 5 bytes per 32767 bytes.
  *
  * The worst case internal to a compressed block is very hard to figure.
- * The worst case can at least be boundined by having one bit that represents
+ * The worst case can at least be bounded by having one bit that represents
  * 32764 bytes and then all of the rest of the bytes representing the very
  * very last byte.
  *
  * All of which is enough to compute an amount of extra data that is required
  * to be safe.  To avoid problems at the block level allocating 5 extra bytes
- * per 32767 bytes of data is sufficient.  To avoind problems internal to a
+ * per 32767 bytes of data is sufficient.  To avoid problems internal to a
  * block adding an extra 32767 bytes (the worst case uncompressed block size)
  * is sufficient, to ensure that in the worst case the decompressed data for
  * block will stop the byte before the compressed data for a block begins.
@@ -88,11 +90,17 @@
  * Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
  * Adding 32768 instead of 32767 just makes for round numbers.
  *
+ * Above analysis is for decompressing gzip compressed kernel only. Up to
+ * now 6 different decompressor are supported all together. And among them
+ * xz stores data in chunks and has maximum chunk of 64K. Hence safety
+ * margin should be updated to cover all decompressors so that we don't
+ * need to deal with each of them separately. Please check
+ * the description in lib/decompressor_xxx.c for specific information.
+ *
+ * extra_bytes = (uncompressed_size >> 12) + 65536 + 128.
+ *
  */
 
-/*
- * gzip declarations
- */
 #define STATIC		static
 
 #undef memcpy
-- 
2.5.0

  parent reply	other threads:[~2016-03-22  7:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22  7:31 [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support Baoquan He
2016-03-22  7:31 ` [PATCH v4 01/20] x86, kaslr: Remove not needed parameter for choose_kernel_location Baoquan He
2016-03-22  7:31 ` [PATCH v4 02/20] x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G Baoquan He
2016-03-22  7:32 ` [PATCH v4 03/20] x86, boot: Move compressed kernel to end of buffer before decompressing Baoquan He
2016-03-22  7:32 ` [PATCH v4 04/20] x86, boot: Move z_extract_offset calculation to header.S Baoquan He
2016-03-22  7:32 ` Baoquan He [this message]
2016-03-22  7:32 ` [PATCH v4 06/20] x86, boot: Fix run_size calculation Baoquan He
2016-03-22 20:51   ` Kees Cook
2016-03-22  7:32 ` [PATCH v4 07/20] x86, kaslr: Clean up useless code related to run_size Baoquan He
2016-03-22 20:52   ` Kees Cook
2016-03-22  7:32 ` [PATCH v4 08/20] x86, kaslr: Get correct max_addr for relocs pointer Baoquan He
2016-03-22 20:52   ` Kees Cook
2016-03-22  7:32 ` [PATCH v4 09/20] x86, kaslr: Consolidate mem_avoid array filling Baoquan He
2016-03-22  7:32 ` [PATCH v4 10/20] x86, boot: Split kernel_ident_mapping_init to another file Baoquan He
2016-03-22  7:32 ` [PATCH v4 11/20] x86, 64bit: Set ident_mapping for kaslr Baoquan He
2016-04-13 10:05   ` Ingo Molnar
2016-03-22  7:32 ` [PATCH v4 12/20] x86, boot: Add checking for memcpy Baoquan He
2016-03-22  7:32 ` [PATCH v4 13/20] x86, kaslr: Introduce struct slot_area to manage randomization slot info Baoquan He
2016-03-22  7:32 ` [PATCH v4 14/20] x86, kaslr: Add two functions which will be used later Baoquan He
2016-03-22  7:32 ` [PATCH v4 15/20] x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text mapping address Baoquan He
2016-03-22  7:32 ` [PATCH v4 16/20] x86, kaslr: Randomize physical and virtual address of kernel separately Baoquan He
2016-03-22  7:32 ` [PATCH v4 17/20] x86, kaslr: Add support of kernel physical address randomization above 4G Baoquan He
2016-03-22  7:32 ` [PATCH v4 18/20] x86, kaslr: Remove useless codes Baoquan He
2016-03-22  7:32 ` [PATCH v4 19/20] x86, kaslr: Allow random address to be below loaded address Baoquan He
2016-03-22 19:54   ` Kees Cook
2016-03-23  1:41     ` Baoquan He
2016-03-23  8:59   ` [PATCH v5 " Baoquan He
2016-03-22  7:32 ` [PATCH v4 20/20] x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual randomization Baoquan He
2016-03-22 20:46   ` Kees Cook
2016-03-22 20:25 ` [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support Kees Cook
2016-03-23 22:40   ` Kees Cook
2016-04-05  1:56 ` Baoquan He
2016-04-05 20:00   ` Kees Cook
2016-04-13 10:19     ` Ingo Molnar
2016-04-13 14:11       ` Kees Cook
2016-04-14  6:02         ` Kees Cook
2016-04-14  6:24           ` Baoquan He
2016-04-14 15:06           ` Baoquan He
2016-04-14 17:56             ` Kees Cook
2016-04-15  4:08               ` Baoquan He
2016-04-15  4:52                 ` Kees Cook
2016-04-15  6:55                   ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1458631937-14593-6-git-send-email-bhe@redhat.com \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=lasse.collin@tukaani.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®