From: Evgeniy Baskov <baskov@ispras.ru>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alexey Khoroshilov <khoroshilov@ispras.ru>,
lvc-project@linuxtesting.org, x86@kernel.org,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 06/16] x86/boot: Setup memory protection for bzImage code
Date: Thu, 20 Oct 2022 15:07:16 +0300 [thread overview]
Message-ID: <e4774b9c13a2bbb9f976dd0e00bebd07@ispras.ru> (raw)
In-Reply-To: <CAMj1kXG59mtzbJoREgr4GA9QJkORcYb-XuDr3VoZ-3XYLy7k2g@mail.gmail.com>
On 2022-10-19 10:17, Ard Biesheuvel wrote:
> On Tue, 6 Sept 2022 at 12:42, Evgeniy Baskov <baskov@ispras.ru> wrote:
>>
>> Use previously added code to use 4KB pages for mapping. Map compressed
>> and uncompressed kernel with appropriate memory protection attributes.
>> For compressed kernel set them up manually. For uncompressed kernel
>> used flags specified in ELF header.
>>
>> Signed-off-by: Evgeniy Baskov <baskov@ispras.ru>
...
>>
>> /*
>> * Locally defined symbols should be marked hidden:
>> @@ -578,6 +578,7 @@ SYM_FUNC_START_LOCAL_NOALIGN(.Lrelocated)
>> pushq %rsi
>> call load_stage2_idt
>>
>> + call startup32_enable_nx_if_supported
>> /* Pass boot_params to initialize_identity_maps() */
>> movq (%rsp), %rdi
>> call initialize_identity_maps
>> @@ -602,6 +603,28 @@ SYM_FUNC_START_LOCAL_NOALIGN(.Lrelocated)
>> jmp *%rax
>> SYM_FUNC_END(.Lrelocated)
>>
>> +SYM_FUNC_START_LOCAL_NOALIGN(startup32_enable_nx_if_supported)
>
> Why the startup32_ prefix for this function name?
Oh, right there is no reasons, I will remove it.
...
>> /*
>> * Adds the specified range to the identity mappings.
>> */
>> -void kernel_add_identity_map(unsigned long start, unsigned long end)
>> +unsigned long kernel_add_identity_map(unsigned long start,
>> + unsigned long end,
>> + unsigned int flags)
>> {
>> int ret;
>>
>> /* Align boundary to 2M. */
>> - start = round_down(start, PMD_SIZE);
>> - end = round_up(end, PMD_SIZE);
>> + start = round_down(start, PAGE_SIZE);
>> + end = round_up(end, PAGE_SIZE);
>> if (start >= end)
>> - return;
>> + return start;
>> +
>> + /* Enforce W^X -- just stop booting with error on violation.
>> */
>> + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) &&
>> + (flags & (MAP_EXEC | MAP_WRITE)) == (MAP_EXEC |
>> MAP_WRITE))
>> + error("Error: W^X violation\n");
>> +
>
> Do we need to add a new failure mode here?
It seems reasonable to me to leave it here to avoid unintentionally
introducing
RWX mappings. And this function can already fail on OOM situation.
I can change it to warning if failure is too harsh in this situation.
>
>> + bool nx = !(flags & MAP_EXEC) && has_nx;
>> + bool ro = !(flags & MAP_WRITE);
>> +
...
>> - kernel_add_identity_map((unsigned long)_head, (unsigned
>> long)_end);
>> - boot_params = rmode;
>> - kernel_add_identity_map((unsigned long)boot_params, (unsigned
>> long)(boot_params + 1));
>> + extern char _head[], _ehead[];
>
> Please move these extern declarations out of the function scope (at
> the very least)
I will move it to misc.h then, there are already some of these
declarations present.
>
>> + kernel_add_identity_map((unsigned long)_head,
>> + (unsigned long)_ehead, MAP_EXEC |
>> MAP_NOFLUSH);
>> +
>> + extern char _compressed[], _ecompressed[];
>> + kernel_add_identity_map((unsigned long)_compressed,
>> + (unsigned long)_ecompressed, MAP_WRITE
>> | MAP_NOFLUSH);
>> +
>> + extern char _text[], _etext[];
>> + kernel_add_identity_map((unsigned long)_text,
>> + (unsigned long)_etext, MAP_EXEC |
>> MAP_NOFLUSH);
>> +
>> + extern char _rodata[], _erodata[];
>> + kernel_add_identity_map((unsigned long)_rodata,
>> + (unsigned long)_erodata, MAP_NOFLUSH);
>> +
>
> Same question as before: do we really need three different regions for
> rodata+text here?
As I already told, I think, its undesirable to leave compressed kernel
blob
(and .rodata) executable, as it it will provide higher attack surface if
some
control flow interception vulnerability in this code would be
discovered,
and though I am not aware of such vulnerabilities to be present
currently,
I think, additional security is not redundant, since it can be provided
almost
for free.
I can merge these regions, if you think it does not worth it.
>
...
>> + /*
>> + * Simultaneously readable and writable
>> segments are
>> + * violating W^X, and should not be present in
>> vmlinux image.
>> + */
>> + if ((phdr->p_flags & (PF_X | PF_W)) == (PF_X |
>> PF_W))
>> + error("W^X violation for ELF
>> segment");
>> +
>
> Can we catch this at build time instead?
Thanks, thats great idea! I will implement that in tools/build.c
>
...
>> +#else
>> +static inline unsigned long kernel_add_identity_map(unsigned long
>> start,
>> + unsigned long end,
>> + unsigned int
>> flags)
>> +{
>> + (void)flags;
>> + (void)end;
>
> Why these (void) casts? Can we just drop them?
>
Unused parameters used to cause warnings for me here somehow...
I will drop them.
next prev parent reply other threads:[~2022-10-20 12:07 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 10:41 [PATCH 00/16] x86_64: Improvements at compressed kernel stage Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 01/16] x86/boot: Align vmlinuz sections on page size Evgeniy Baskov
2022-10-19 7:01 ` Ard Biesheuvel
2022-10-20 11:13 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 02/16] x86/build: Remove RWX sections and align on 4KB Evgeniy Baskov
2022-10-19 7:04 ` Ard Biesheuvel
2022-10-20 11:15 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 03/16] x86/boot: Set cr0 to known state in trampoline Evgeniy Baskov
2022-10-19 7:06 ` Ard Biesheuvel
2022-10-20 11:23 ` Evgeniy Baskov
2022-10-19 7:44 ` Andrew Cooper
2022-10-20 13:25 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 04/16] x86/boot: Increase boot page table size Evgeniy Baskov
2022-10-19 7:08 ` Ard Biesheuvel
2022-10-20 11:29 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 05/16] x86/boot: Support 4KB pages for identity mapping Evgeniy Baskov
2022-10-19 7:11 ` Ard Biesheuvel
2022-10-20 11:30 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 06/16] x86/boot: Setup memory protection for bzImage code Evgeniy Baskov
2022-10-19 7:17 ` Ard Biesheuvel
2022-10-20 12:07 ` Evgeniy Baskov [this message]
2022-10-19 7:57 ` Andrew Cooper
2022-10-20 13:30 ` Evgeniy Baskov
2022-10-20 16:51 ` Andrew Cooper
2022-09-06 10:41 ` [PATCH 07/16] x86/boot: Map memory explicitly Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 08/16] x86/boot: Remove mapping from page fault handler Evgeniy Baskov
2022-10-19 7:20 ` Ard Biesheuvel
2022-09-06 10:41 ` [PATCH 09/16] efi/libstub: Move helper function to related file Evgeniy Baskov
2022-10-19 7:21 ` Ard Biesheuvel
2022-09-06 10:41 ` [PATCH 10/16] x86/boot: Make console interface more abstract Evgeniy Baskov
2022-10-19 7:23 ` Ard Biesheuvel
2022-10-20 12:10 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 11/16] x86/boot: Split trampoline and pt init code Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 12/16] x86/boot: Add EFI kernel extraction interface Evgeniy Baskov
2022-10-19 7:27 ` Ard Biesheuvel
2022-10-20 12:14 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 13/16] efi/x86: Support extracting kernel from libstub Evgeniy Baskov
2022-10-19 7:35 ` Ard Biesheuvel
2022-10-20 12:36 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 14/16] x86/build: Make generated PE more spec compliant Evgeniy Baskov
2022-10-19 7:39 ` Ard Biesheuvel
2022-10-20 13:07 ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 15/16] efi/libstub: Add memory attribute protocol definitions Evgeniy Baskov
2022-10-19 7:39 ` Ard Biesheuvel
2022-09-06 10:41 ` [PATCH 16/16] efi/libstub: Use memory attribute protocol Evgeniy Baskov
2022-10-18 20:51 ` [PATCH] efi/libstub: make memory protection warnings include newlines Peter Jones
2022-10-19 7:44 ` Ard Biesheuvel
2022-10-19 7:42 ` [PATCH 16/16] efi/libstub: Use memory attribute protocol Ard Biesheuvel
2022-10-20 13:13 ` Evgeniy Baskov
2022-10-18 21:04 ` [PATCH 00/16] x86_64: Improvements at compressed kernel stage Peter Jones
2022-10-20 11:05 ` Evgeniy Baskov
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=e4774b9c13a2bbb9f976dd0e00bebd07@ispras.ru \
--to=baskov@ispras.ru \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=khoroshilov@ispras.ru \
--cc=linux-efi@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).