* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:24 ` Ingo Molnar
@ 2017-03-24 9:36 ` Borislav Petkov
2017-03-24 9:37 ` Ard Biesheuvel
2017-03-24 11:52 ` Baoquan He
2 siblings, 0 replies; 16+ messages in thread
From: Borislav Petkov @ 2017-03-24 9:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Dave Young, Baoquan He, linux-kernel, stable, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86, linux-efi, Thomas Garnier,
Kees Cook, Andrew Morton, Masahiro Yamada, Bhupesh Sharma
On Fri, Mar 24, 2017 at 10:24:34AM +0100, Ingo Molnar wrote:
> Preserving virtual addresses for kexec is a red herring: the randomized offset
> could be passed to the kexec-ed kernel just fine.
Not only that - kexec'ed kernel gets the addresses from sysfs so we can randomize.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:24 ` Ingo Molnar
2017-03-24 9:36 ` Borislav Petkov
@ 2017-03-24 9:37 ` Ard Biesheuvel
2017-03-24 9:40 ` Borislav Petkov
2017-03-24 10:36 ` Ingo Molnar
2017-03-24 11:52 ` Baoquan He
2 siblings, 2 replies; 16+ messages in thread
From: Ard Biesheuvel @ 2017-03-24 9:37 UTC (permalink / raw)
To: Ingo Molnar
Cc: Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Borislav Petkov, Andrew Morton,
Masahiro Yamada, Bhupesh Sharma
On 24 March 2017 at 09:24, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Dave Young <dyoung@redhat.com> wrote:
>
>> > > So I applied this kexec fix and extended the changelog to clearly show why
>> > > this fix matters in practice.
>> >
>> > I thought it only impacts kexec, but Dave thought it will impact 1st kenrel
>> > either.
>>
>> Yes, I think no need to mention kexec, it is a general issue.
>>
>> First, the space is reserved for EFI, so kernel should not use it for kaslr.
>
> It's the kernel's EFI code, and we map whatever address we want (and then pass
> that to the EFI runtime), so wether it's randomized or not is the Linux kernel's
> policy decision...
>
No. It is the firmware's EFI code, and the virtual translation applied
by the OS is made known to the firmware by means of a call into the
runtime service SetVirtualAddressMap(). This service can only be
called once after each boot, and so kexec kernels are forced to use
the same VA mapping for runtime services as the first kernel. This is
the whole point of having a VA region reserved for this, so that kexec
kernels are guaranteed to be able to use the same VA mapping.
> So that's my question: can these memory regions include security sensitive data,
> and if yes, how can we best randomize it while kexec and other kernel and EFI
> features still work?
>
> Preserving virtual addresses for kexec is a red herring: the randomized offset
> could be passed to the kexec-ed kernel just fine.
>
> Thanks,
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:37 ` Ard Biesheuvel
@ 2017-03-24 9:40 ` Borislav Petkov
2017-03-24 9:42 ` Ard Biesheuvel
2017-03-24 10:36 ` Ingo Molnar
1 sibling, 1 reply; 16+ messages in thread
From: Borislav Petkov @ 2017-03-24 9:40 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Ingo Molnar, Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Andrew Morton, Masahiro Yamada,
Bhupesh Sharma
On Fri, Mar 24, 2017 at 09:37:36AM +0000, Ard Biesheuvel wrote:
> No. It is the firmware's EFI code, and the virtual translation applied
> by the OS is made known to the firmware by means of a call into the
> runtime service SetVirtualAddressMap().
We can still randomize within those 64G before calling
SetVirtualAddressMap(). The question is, do we want to or need to, even?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:40 ` Borislav Petkov
@ 2017-03-24 9:42 ` Ard Biesheuvel
2017-03-24 9:46 ` Borislav Petkov
0 siblings, 1 reply; 16+ messages in thread
From: Ard Biesheuvel @ 2017-03-24 9:42 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ingo Molnar, Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Andrew Morton, Masahiro Yamada,
Bhupesh Sharma
On 24 March 2017 at 09:40, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Mar 24, 2017 at 09:37:36AM +0000, Ard Biesheuvel wrote:
>> No. It is the firmware's EFI code, and the virtual translation applied
>> by the OS is made known to the firmware by means of a call into the
>> runtime service SetVirtualAddressMap().
>
> We can still randomize within those 64G before calling
> SetVirtualAddressMap(). The question is, do we want to or need to, even?
>
That is a different matter. If the regions are only mapped while
runtime services invocations are in progress (as we do on ARM), I am
not sure if it matters that much, given how rarely that occurs in
normal use.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:42 ` Ard Biesheuvel
@ 2017-03-24 9:46 ` Borislav Petkov
2017-03-24 9:52 ` Ard Biesheuvel
0 siblings, 1 reply; 16+ messages in thread
From: Borislav Petkov @ 2017-03-24 9:46 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Ingo Molnar, Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Andrew Morton, Masahiro Yamada,
Bhupesh Sharma
On Fri, Mar 24, 2017 at 09:42:40AM +0000, Ard Biesheuvel wrote:
> That is a different matter. If the regions are only mapped while
> runtime services invocations are in progress (as we do on ARM), I am
> not sure if it matters that much, given how rarely that occurs in
> normal use.
Question is, is there anything worth protecting with ASLR or we don't
care? I wanna say, we should randomize just in case, especially as it
shouldn't be that expensive to do.
Also, how does the whole EFI-in-the-kexec-ed-kernel work on ARM? Runtime
services get mapped on-demand in the kexec-ed kernel too?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:46 ` Borislav Petkov
@ 2017-03-24 9:52 ` Ard Biesheuvel
0 siblings, 0 replies; 16+ messages in thread
From: Ard Biesheuvel @ 2017-03-24 9:52 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ingo Molnar, Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Andrew Morton, Masahiro Yamada,
Bhupesh Sharma
On 24 March 2017 at 09:46, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Mar 24, 2017 at 09:42:40AM +0000, Ard Biesheuvel wrote:
>> That is a different matter. If the regions are only mapped while
>> runtime services invocations are in progress (as we do on ARM), I am
>> not sure if it matters that much, given how rarely that occurs in
>> normal use.
>
> Question is, is there anything worth protecting with ASLR or we don't
> care? I wanna say, we should randomize just in case, especially as it
> shouldn't be that expensive to do.
>
Well, given that in many cases, these pages are mapped R+W+X, I would
say that there is a risk involved in having these data structures at
fixed offsets.
Since UEFI v2.6, we have a new firmware table that describes strict
permission attributes for these regions, so everything can be mapped
writable or executable but never both. (Sai wired up the support for
this for x86 in v4.10)
> Also, how does the whole EFI-in-the-kexec-ed-kernel work on ARM? Runtime
> services get mapped on-demand in the kexec-ed kernel too?
>
Yes. On ARM, we use an ordinary mm_struct and just do a switch_mm()
with preemption disabled. So there is no need to reserve kernel VA
ranges, all UEFI runtime mappings are in the user area.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:37 ` Ard Biesheuvel
2017-03-24 9:40 ` Borislav Petkov
@ 2017-03-24 10:36 ` Ingo Molnar
2017-03-24 10:42 ` Ard Biesheuvel
1 sibling, 1 reply; 16+ messages in thread
From: Ingo Molnar @ 2017-03-24 10:36 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Borislav Petkov, Andrew Morton,
Masahiro Yamada, Bhupesh Sharma
* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> No. It is the firmware's EFI code, and the virtual translation applied by the OS
> is made known to the firmware by means of a call into the runtime service
> SetVirtualAddressMap(). This service can only be called once after each boot,
> and so kexec kernels are forced to use the same VA mapping for runtime services
> as the first kernel. This is the whole point of having a VA region reserved for
> this, so that kexec kernels are guaranteed to be able to use the same VA
> mapping.
Yes, but it's the kernel's EFI code that determines the area! So my suggestion:
> > Preserving virtual addresses for kexec is a red herring: the randomized offset
> > could be passed to the kexec-ed kernel just fine.
Would solve the kexec problem, right?
I.e. the first kernel that boots randomizes the address range - and passes that
offset off to any subsequent kernels.
Turning KASLR off actively degrades that randomization of the kernel virtual
addresses.
Am I missing anything?
Thanks,
Ingo
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 10:36 ` Ingo Molnar
@ 2017-03-24 10:42 ` Ard Biesheuvel
2017-03-24 10:54 ` Ingo Molnar
0 siblings, 1 reply; 16+ messages in thread
From: Ard Biesheuvel @ 2017-03-24 10:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Borislav Petkov, Andrew Morton,
Masahiro Yamada, Bhupesh Sharma
On 24 March 2017 at 10:36, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> No. It is the firmware's EFI code, and the virtual translation applied by the OS
>> is made known to the firmware by means of a call into the runtime service
>> SetVirtualAddressMap(). This service can only be called once after each boot,
>> and so kexec kernels are forced to use the same VA mapping for runtime services
>> as the first kernel. This is the whole point of having a VA region reserved for
>> this, so that kexec kernels are guaranteed to be able to use the same VA
>> mapping.
>
> Yes, but it's the kernel's EFI code that determines the area!
Indeed. It seems I misunderstood you there.
There are some known limitations, though, which prevent us from using
userland mappings on x86 like we do on ARM (Macs don't support it),
but I don't think randomizing the mappings inside this 64 GB window is
going to trigger any latent firmware bugs.
> So my suggestion:
>
>> > Preserving virtual addresses for kexec is a red herring: the randomized offset
>> > could be passed to the kexec-ed kernel just fine.
>
> Would solve the kexec problem, right?
>
> I.e. the first kernel that boots randomizes the address range - and passes that
> offset off to any subsequent kernels.
>
Yes, that sounds feasible to me.
> Turning KASLR off actively degrades that randomization of the kernel virtual
> addresses.
>
> Am I missing anything?
>
No, I think you are right. UEFI runtime services region are likely to
consist of R+W+X mappings for the foreseeable future on x86, and the
more we tighten down security in other places, the more appealing the
UEFI regions become for exploitation (even if they are only mapped
while runtime services calls are in progress).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 10:42 ` Ard Biesheuvel
@ 2017-03-24 10:54 ` Ingo Molnar
0 siblings, 0 replies; 16+ messages in thread
From: Ingo Molnar @ 2017-03-24 10:54 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Dave Young, Baoquan He, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, linux-efi@vger.kernel.org,
Thomas Garnier, Kees Cook, Borislav Petkov, Andrew Morton,
Masahiro Yamada, Bhupesh Sharma
* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Turning KASLR off actively degrades that randomization of the kernel virtual
> > addresses.
> >
> > Am I missing anything?
> >
>
> No, I think you are right. UEFI runtime services region are likely to consist of
> R+W+X mappings for the foreseeable future on x86, and the more we tighten down
> security in other places, the more appealing the UEFI regions become for
> exploitation (even if they are only mapped while runtime services calls are in
> progress).
Ok, so I'm fine with the current proposed patch as a temporary workaround, but
only if we are going to get a real fix as well, ASAP.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization
2017-03-24 9:24 ` Ingo Molnar
2017-03-24 9:36 ` Borislav Petkov
2017-03-24 9:37 ` Ard Biesheuvel
@ 2017-03-24 11:52 ` Baoquan He
2 siblings, 0 replies; 16+ messages in thread
From: Baoquan He @ 2017-03-24 11:52 UTC (permalink / raw)
To: Ingo Molnar
Cc: Dave Young, linux-kernel, stable, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-efi, Thomas Garnier, Kees Cook,
Borislav Petkov, Andrew Morton, Masahiro Yamada, Bhupesh Sharma
On 03/24/17 at 10:24am, Ingo Molnar wrote:
>
> * Dave Young <dyoung@redhat.com> wrote:
>
> > > > So I applied this kexec fix and extended the changelog to clearly show why
> > > > this fix matters in practice.
> > >
> > > I thought it only impacts kexec, but Dave thought it will impact 1st kenrel
> > > either.
> >
> > Yes, I think no need to mention kexec, it is a general issue.
> >
> > First, the space is reserved for EFI, so kernel should not use it for kaslr.
>
> It's the kernel's EFI code, and we map whatever address we want (and then pass
> that to the EFI runtime), so wether it's randomized or not is the Linux kernel's
> policy decision...
>
> So that's my question: can these memory regions include security sensitive data,
> and if yes, how can we best randomize it while kexec and other kernel and EFI
> features still work?
It doesn't corrupt kernel possibly because:
1) there's espfixup stack region between them if CONFIG_X86_ESPFIX64 is
enabled, then the upper limit of kaslr VA space for randomization could be
ESPFIX_BASE_ADDR. Fedora default to enable ESPFIX_BASE_ADDR.
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ...
ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
... unused hole ...
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
... unused hole ...
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
2) Though ESPFIX_BASE_ADDR is disabled, efi region is included into
kaslr mm va space, efi is allocated top-down in 64G, while vmemmap is 1T
large and allocated bottom-up, it rarely used up 1TB space to map struct
page.
3) most of the time, it might not randomize vmemmap to occupy the efi
region.
So up to now, no corruption is heard about this bug.
Thanks
Baoquan
^ permalink raw reply [flat|nested] 16+ messages in thread