Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1298615 > unrolled thread

Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Arnd Bergmann <arnd@arndb.de> - 2015-12-28 13:00 +0100
    Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-12-28 13:10 +0100
      Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Arnd Bergmann <arnd@arndb.de> - 2015-12-28 15:20 +0100
        Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Mark Rutland <mark.rutland@arm.com> - 2016-01-03 16:00 +0100
          Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-01-03 16:30 +0100
          Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Arnd Bergmann <arnd@arndb.de> - 2016-01-04 13:30 +0100
            Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Mark Rutland <mark.rutland@arm.com> - 2016-01-04 13:40 +0100

#1298615 — Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
> @@ -75,8 +76,13 @@
>   * private definitions which should NOT be used outside memory.h
>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>   */
> -#define __virt_to_phys(x)      (((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET))
> +#define __virt_to_phys(x) ({                                           \
> +       phys_addr_t __x = (phys_addr_t)(x);                             \
> +       __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :        \
> +                            (__x - KIMAGE_VADDR + PHYS_OFFSET); })
> +
>  #define __phys_to_virt(x)      ((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
> +#define __phys_to_kimg(x)      ((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))

Having a conditional here is a bit unfortunate.

IIRC KASLR means something different depending on the architecture, we either randomize
the physical address, or the virtual address, or both, and that addresses different
attack scenarios. You seem to leave the physical address unchanged, which means that
an attacker that has gained access to a DMA master device can potentially still modify
the kernel without knowing the virtual address.
Similarly, you seem to leave the kernel mapped at the original virtual address and
just add a second map (or your __phys_to_virt is wrong), so if someone has the
ability to access a kernel virtual memory address from user space, they also don't
need the relocated address because they can potentially access the kernel .text
and .data through the linear mapping.

How about a different approach that keeps the relocatable kernel, but moves it in
physical memory with the same random offset as the virtual address? That way, both
would be random, and you can keep the simple virt_to_phys() function.

I suppose the downside of that is that the number of random bits is then limited
by the size of the first memblock, which is smaller than the vmalloc area.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1298617 — Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

On 28 December 2015 at 12:50, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
>> @@ -75,8 +76,13 @@
>>   * private definitions which should NOT be used outside memory.h
>>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>>   */
>> -#define __virt_to_phys(x)      (((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET))
>> +#define __virt_to_phys(x) ({                                           \
>> +       phys_addr_t __x = (phys_addr_t)(x);                             \
>> +       __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :        \
>> +                            (__x - KIMAGE_VADDR + PHYS_OFFSET); })
>> +
>>  #define __phys_to_virt(x)      ((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
>> +#define __phys_to_kimg(x)      ((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
>
> Having a conditional here is a bit unfortunate.
>

Yes. Unfortunately, the assumption that kernel symbols live in the
same address space as dynamic allocations in the linear mapping is
widespread throughout the code base, otherwise we could strictly
separate the two, and this would not be necessary. I played around
with adding another sparse address space for kernel addresses, but
that gives a lot of hits in generic code as well.

> IIRC KASLR means something different depending on the architecture, we either randomize
> the physical address, or the virtual address, or both, and that addresses different
> attack scenarios. You seem to leave the physical address unchanged, which means that
> an attacker that has gained access to a DMA master device can potentially still modify
> the kernel without knowing the virtual address.

Indeed. I did not mention it in the cover letter, but this work is
somewhat related to series I proposed which allows the kernel Image to
reside anywhere (i.e., at any 2 MB aligned offset + TEXT_OFFSET) in
physical memory. This is fairly straight forward once we have moved
the kernel virtual mapping out of the linear mapping, but since this
series has enough moving parts as it is, I omitted those pieces for
now.
http://thread.gmane.org/gmane.linux.ports.arm.kernel/455151

After Mark Rutland proposed his pagetable rework series, a lot of
those changes became much easier to implement, but did require rework,
and because of queries I received personally regarding KASLR, I
decided to focus on that part first.

> Similarly, you seem to leave the kernel mapped at the original virtual address and
> just add a second map (or your __phys_to_virt is wrong), so if someone has the
> ability to access a kernel virtual memory address from user space, they also don't
> need the relocated address because they can potentially access the kernel .text
> and .data through the linear mapping.
>

True. Catalin mentioned this as well in response to the series
mentioned above. Unmapping the kernel text in the linear mapping is an
important enhancement from security pov, but not essential from a
functionality pov.

> How about a different approach that keeps the relocatable kernel, but moves it in
> physical memory with the same random offset as the virtual address? That way, both
> would be random, and you can keep the simple virt_to_phys() function.
>
> I suppose the downside of that is that the number of random bits is then limited
> by the size of the first memblock, which is smaller than the vmalloc area.
>

I don't see a reason to use the same virtual and physical offset
(other than the conditional). On arm64, it would be up to the
bootloader to decide where to put the Image in physical memory, and it
would be up to the kernel to decide whether or not to virtually remap
itself.

Regards,
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1298654

On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote:
> On 28 December 2015 at 12:50, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
> > How about a different approach that keeps the relocatable kernel, but moves it in
> > physical memory with the same random offset as the virtual address? That way, both
> > would be random, and you can keep the simple virt_to_phys() function.
> >
> > I suppose the downside of that is that the number of random bits is then limited
> > by the size of the first memblock, which is smaller than the vmalloc area.
> >
> 
> I don't see a reason to use the same virtual and physical offset
> (other than the conditional). On arm64, it would be up to the
> bootloader to decide where to put the Image in physical memory, and it
> would be up to the kernel to decide whether or not to virtually remap
> itself.

I see. If we pull in the bootloader to the discussion, there are a couple
of related points that are not directly required for your series but that
we should keep in mind anyway:

- We need to implement the randomization for each boot loader separately.
  This is probably easy enough for grub, as it can tap the same random
  number source that you use here, but a little harder for u-boot (requiring
  to implement access to hardware rng separately on each platform) and
  much harder to get done consistently in UEFI for direct kernel loading
  since there is no common upstream.

- once we have a random number in the bootloader, we should also pass that
  through a DT property. This has been discussed multiple times in the past
  and I think we had reached consensus already but don't know if we had
  agreed on a specific DT property that contains the random number seed.

- For machines that don't have strong hardware RNG, or where we don't
  trust that hardware enough, we may want to have a way to feed back a
  random seed into the bootloader during shutdown, the equivalent of
  /etc/random-seed. On real Open Firmware, we'd do this through a
  nvram variable that gets copied into a /chosen DT property, but we don't
  have a generic way to do the same with u-boot. On UEFI we could probably
  do it through efivars, but I'm not sure if that's accessible early
  enough in the kernel, so we might need help from grub again.  

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300317 — Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

On Mon, Dec 28, 2015 at 03:11:25PM +0100, Arnd Bergmann wrote:
> On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote:
> > On 28 December 2015 at 12:50, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
> > > How about a different approach that keeps the relocatable kernel, but moves it in
> > > physical memory with the same random offset as the virtual address? That way, both
> > > would be random, and you can keep the simple virt_to_phys() function.
> > >
> > > I suppose the downside of that is that the number of random bits is then limited
> > > by the size of the first memblock, which is smaller than the vmalloc area.
> > >
> > 
> > I don't see a reason to use the same virtual and physical offset
> > (other than the conditional). On arm64, it would be up to the
> > bootloader to decide where to put the Image in physical memory, and it
> > would be up to the kernel to decide whether or not to virtually remap
> > itself.
> 
> I see. If we pull in the bootloader to the discussion, there are a couple
> of related points that are not directly required for your series but that
> we should keep in mind anyway:
> 
> - We need to implement the randomization for each boot loader separately.
>   This is probably easy enough for grub, as it can tap the same random
>   number source that you use here, but a little harder for u-boot (requiring
>   to implement access to hardware rng separately on each platform) and
>   much harder to get done consistently in UEFI for direct kernel loading
>   since there is no common upstream.

In the GRUB case the kernel is loaded as an EFI application -- as far as I am
aware, GRUB for arm64 doesn't know anything about the Linux kernel Image
binary.

When loaded as an EFI application the EFI stub can perform the relocation,
which it already does if the kernel was laoded at an address it cannot execute
from. It looks like Ard's implemented that for v2.

Being (cold) booted from EFI is likely to be the most consistent case as we
have complete control over where the kernel is placed, bar some limitations
imposed by prior EFI applications or EFI itself.

> - once we have a random number in the bootloader, we should also pass that
>   through a DT property. This has been discussed multiple times in the past
>   and I think we had reached consensus already but don't know if we had
>   agreed on a specific DT property that contains the random number seed.

Any links for this? I don't recall spotting this discussion.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300320 — Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

On 3 January 2016 at 15:50, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Dec 28, 2015 at 03:11:25PM +0100, Arnd Bergmann wrote:
>> On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote:
>> > On 28 December 2015 at 12:50, Arnd Bergmann <arnd@arndb.de> wrote:
>> > > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
>> > > How about a different approach that keeps the relocatable kernel, but moves it in
>> > > physical memory with the same random offset as the virtual address? That way, both
>> > > would be random, and you can keep the simple virt_to_phys() function.
>> > >
>> > > I suppose the downside of that is that the number of random bits is then limited
>> > > by the size of the first memblock, which is smaller than the vmalloc area.
>> > >
>> >
>> > I don't see a reason to use the same virtual and physical offset
>> > (other than the conditional). On arm64, it would be up to the
>> > bootloader to decide where to put the Image in physical memory, and it
>> > would be up to the kernel to decide whether or not to virtually remap
>> > itself.
>>
>> I see. If we pull in the bootloader to the discussion, there are a couple
>> of related points that are not directly required for your series but that
>> we should keep in mind anyway:
>>
>> - We need to implement the randomization for each boot loader separately.
>>   This is probably easy enough for grub, as it can tap the same random
>>   number source that you use here, but a little harder for u-boot (requiring
>>   to implement access to hardware rng separately on each platform) and
>>   much harder to get done consistently in UEFI for direct kernel loading
>>   since there is no common upstream.
>
> In the GRUB case the kernel is loaded as an EFI application -- as far as I am
> aware, GRUB for arm64 doesn't know anything about the Linux kernel Image
> binary.
>

No, it doesn't. Alexander Graf is even proposing a EFI compatible
runtime in U-boot so it can run EFI-GRUB as well, so it is unlikely
that something like that will get added soon. If he includes a
EFI_RNG_PROTOCOL implementation, we can run these patches on U-Boot as
well.

> When loaded as an EFI application the EFI stub can perform the relocation,
> which it already does if the kernel was laoded at an address it cannot execute
> from. It looks like Ard's implemented that for v2.
>

Indeed.

> Being (cold) booted from EFI is likely to be the most consistent case as we
> have complete control over where the kernel is placed, bar some limitations
> imposed by prior EFI applications or EFI itself.
>
>> - once we have a random number in the bootloader, we should also pass that
>>   through a DT property. This has been discussed multiple times in the past
>>   and I think we had reached consensus already but don't know if we had
>>   agreed on a specific DT property that contains the random number seed.
>
> Any links for this? I don't recall spotting this discussion.
>
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300703

On Sunday 03 January 2016 14:50:10 Mark Rutland wrote:
> 
> > - once we have a random number in the bootloader, we should also pass that
> >   through a DT property. This has been discussed multiple times in the past
> >   and I think we had reached consensus already but don't know if we had
> >   agreed on a specific DT property that contains the random number seed.
> 
> Any links for this? I don't recall spotting this discussion.

One discussion I found in the mail archives is in this thread
https://lkml.org/lkml/2014/2/12/518, I also remember discussing it in person
at some conference, obviously no archive of that.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300714 — Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

On Mon, Jan 04, 2016 at 01:21:05PM +0100, Arnd Bergmann wrote:
> On Sunday 03 January 2016 14:50:10 Mark Rutland wrote:
> > 
> > > - once we have a random number in the bootloader, we should also pass that
> > >   through a DT property. This has been discussed multiple times in the past
> > >   and I think we had reached consensus already but don't know if we had
> > >   agreed on a specific DT property that contains the random number seed.
> > 
> > Any links for this? I don't recall spotting this discussion.
> 
> One discussion I found in the mail archives is in this thread
> https://lkml.org/lkml/2014/2/12/518, I also remember discussing it in person
> at some conference, obviously no archive of that.

Thanks for the pointer!

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web