From: Kees Cook <keescook@chromium.org> To: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org>, Baoquan He <bhe@redhat.com>, Yinghai Lu <yinghai@kernel.org>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Matt Redfearn <matt.redfearn@imgtec.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>, Andy Lutomirski <luto@kernel.org>, lasse.collin@tukaani.org, Andrew Morton <akpm@linux-foundation.org>, Dave Young <dyoung@redhat.com>, kernel-hardening@lists.openwall.com, LKML <linux-kernel@vger.kernel.org> Subject: [PATCH v5 06/21] x86, KASLR: Update description for decompressor worst case size Date: Thu, 14 Apr 2016 15:28:59 -0700 [thread overview] Message-ID: <1460672954-32567-7-git-send-email-keescook@chromium.org> (raw) In-Reply-To: <1460672954-32567-1-git-send-email-keescook@chromium.org> From: Baoquan He <bhe@redhat.com> The comment that describes the analysis for the size of the decompressor code only took gzip into account (there are 6 other decompressors that could be used). The actual z_extract_offset calculation in code was already handling the correct maximum size, but this documentation hadn't been updated. This updates the documentation and fixes several typos. Signed-off-by: Baoquan He <bhe@redhat.com> [kees: rewrote changelog, cleaned up comment style] Signed-off-by: Kees Cook <keescook@chromium.org> --- 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 e2a998f8c304..31e2d6155643 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.6.3
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org> To: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org>, Baoquan He <bhe@redhat.com>, Yinghai Lu <yinghai@kernel.org>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Matt Redfearn <matt.redfearn@imgtec.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>, Andy Lutomirski <luto@kernel.org>, lasse.collin@tukaani.org, Andrew Morton <akpm@linux-foundation.org>, Dave Young <dyoung@redhat.com>, kernel-hardening@lists.openwall.com, LKML <linux-kernel@vger.kernel.org> Subject: [kernel-hardening] [PATCH v5 06/21] x86, KASLR: Update description for decompressor worst case size Date: Thu, 14 Apr 2016 15:28:59 -0700 [thread overview] Message-ID: <1460672954-32567-7-git-send-email-keescook@chromium.org> (raw) In-Reply-To: <1460672954-32567-1-git-send-email-keescook@chromium.org> From: Baoquan He <bhe@redhat.com> The comment that describes the analysis for the size of the decompressor code only took gzip into account (there are 6 other decompressors that could be used). The actual z_extract_offset calculation in code was already handling the correct maximum size, but this documentation hadn't been updated. This updates the documentation and fixes several typos. Signed-off-by: Baoquan He <bhe@redhat.com> [kees: rewrote changelog, cleaned up comment style] Signed-off-by: Kees Cook <keescook@chromium.org> --- 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 e2a998f8c304..31e2d6155643 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.6.3
next prev parent reply other threads:[~2016-04-14 22:32 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-14 22:28 [PATCH v5 00/21] x86, boot: KASLR cleanup and 64-bit improvements Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 01/21] x86, KASLR: Remove unneeded boot_params argument Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 7:29 ` Ingo Molnar 2016-04-15 7:29 ` [kernel-hardening] " Ingo Molnar 2016-04-15 18:55 ` Kees Cook 2016-04-15 18:55 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 02/21] x86, KASLR: Handle kernel relocation above 2G Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 7:47 ` Ingo Molnar 2016-04-15 7:47 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:01 ` Kees Cook 2016-04-15 19:01 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` [PATCH v5 03/21] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 8:07 ` Ingo Molnar 2016-04-15 8:07 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:12 ` Kees Cook 2016-04-15 19:12 ` [kernel-hardening] " Kees Cook 2016-04-16 8:42 ` Ingo Molnar 2016-04-16 8:42 ` [kernel-hardening] " Ingo Molnar 2016-04-14 22:28 ` [PATCH v5 04/21] x86, boot: Move compressed kernel to end of decompression buffer Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 8:09 ` Ingo Molnar 2016-04-15 8:09 ` [kernel-hardening] " Ingo Molnar 2016-04-18 16:50 ` Kees Cook 2016-04-18 16:50 ` [kernel-hardening] " Kees Cook 2016-04-15 9:05 ` Ingo Molnar 2016-04-15 9:05 ` [kernel-hardening] " Ingo Molnar 2016-04-14 22:28 ` [PATCH v5 05/21] x86, boot: Calculate decompression size during boot not build Kees Cook 2016-04-14 22:28 ` [kernel-hardening] " Kees Cook 2016-04-15 8:12 ` Ingo Molnar 2016-04-15 8:12 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:14 ` Kees Cook 2016-04-15 19:14 ` [kernel-hardening] " Kees Cook 2016-04-14 22:28 ` Kees Cook [this message] 2016-04-14 22:28 ` [kernel-hardening] [PATCH v5 06/21] x86, KASLR: Update description for decompressor worst case size Kees Cook 2016-04-15 16:17 ` Lasse Collin 2016-04-15 16:17 ` [kernel-hardening] " Lasse Collin 2016-04-14 22:29 ` [PATCH v5 07/21] x86, boot: Fix run_size calculation Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-15 8:31 ` Ingo Molnar 2016-04-15 8:31 ` [kernel-hardening] " Ingo Molnar 2016-04-15 19:26 ` Kees Cook 2016-04-15 19:26 ` [kernel-hardening] " Kees Cook 2016-04-16 9:00 ` Ingo Molnar 2016-04-16 9:00 ` [kernel-hardening] " Ingo Molnar 2016-04-14 22:29 ` [PATCH v5 08/21] x86, KASLR: Clean up unused code from old run_size Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 09/21] x86, KASLR: Correctly bounds-check relocations Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 10/21] x86, KASLR: Consolidate mem_avoid entries Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 11/21] x86, boot: Split out kernel_ident_mapping_init Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 12/21] x86, 64bit: Set ident_mapping for KASLR Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 13/21] x86, boot: Report overlap failures in memcpy Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-15 14:42 ` Lasse Collin 2016-04-15 14:42 ` [kernel-hardening] " Lasse Collin 2016-04-15 19:28 ` Kees Cook 2016-04-15 19:28 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 14/21] x86, KASLR: Add slot_area to manage random slots Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 15/21] x86, KASLR: Add slot_area support functions Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 16/21] x86, KASLR: Add virtual address choosing function Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 17/21] x86, KASLR: Clarify purpose of each get_random_long Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 18/21] x86, KASLR: Randomize virtual address separately Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 20/21] x86, KASLR: Remove unused slot tracking code Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook 2016-04-14 22:29 ` [PATCH v5 21/21] x86, KASLR: Allow randomization below load address Kees Cook 2016-04-14 22:29 ` [kernel-hardening] " Kees Cook
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=1460672954-32567-7-git-send-email-keescook@chromium.org \ --to=keescook@chromium.org \ --cc=akpm@linux-foundation.org \ --cc=ard.biesheuvel@linaro.org \ --cc=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=dyoung@redhat.com \ --cc=hpa@zytor.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=lasse.collin@tukaani.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=matt.redfearn@imgtec.com \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=vgoyal@redhat.com \ --cc=x86@kernel.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.