KASLR support on ARM with Kernel 4.9 and 4.14

KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

Hi All,

This is regarding the KASLR feature support on ARM for the kernel
version 4.9 and 4.14.

Is KASLR supported on ARM-32 Linux 4.9 and above ?
Is it dependent on CONFIG_RANDOMIZE_BASE or
/proc/sys/kernel/randomize_va_space ?
Is there any relation between these two?
Is the changing kernel symbols (in every boot), only possible if KASLR
is enabled, or there is another way it can happen?

I have these queries because,
In one of the arm-32 devices with Kernel 4.14, I observed that
CONFIG_RANDOMIZE_BASE is not available.
But /proc/sys/kernel/randomize_va_space is set to 2.
However, I also observed that symbol addresses are changing in every boot.

1st boot cycle:
[root ~]# cat /proc/kallsyms | grep "sys_open"
a5b4de92 T sys_open
[root@sa515m ~]#

2nd boot cycle:
[root ~]# cat /proc/kallsyms | grep "sys_open"
f546ed66 T sys_open

So, I am wondering how this is possible without KASLR
(CONFIG_RANDOMIZE_BASE) support in Kernel ?

Similarly, with Kernel 4.9 and CONFIG_RANDOMIZE_BASE is not available
but /proc/sys/kernel/randomize_va_space is set to 2.
But here, the addresses are remaining same.

1st Run:
[root~]# cat /proc/kallsyms | grep "sys_open"
c01ed68c T sys_open
[root ~]#

*** reboot ***
[root ~]# cat /proc/kallsyms | grep "sys_open"
c01ed68c T sys_open


Is there any other difference between these two kernel versions with
respect to changing symbol addresses ?

Thanks,
Pintu

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Kees Cook]

On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> This is regarding the KASLR feature support on ARM for the kernel
> version 4.9 and 4.14.
> 
> Is KASLR supported on ARM-32 Linux 4.9 and above ?

Sorry, this feature did not yet land in upstream:
https://github.com/KSPP/linux/issues/3

Here was the earlier effort:
https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/

> Is it dependent on CONFIG_RANDOMIZE_BASE or

CONFIG_RANDOMIZE_BASE is what is used on other architectures to control
the feature.

> /proc/sys/kernel/randomize_va_space ?
> Is there any relation between these two?

No, the latter is about userspace addresses.

> Is the changing kernel symbols (in every boot), only possible if KASLR
> is enabled, or there is another way it can happen?

I think you meant kernel symbol addresses (not the symbols themselves).
But yes, I wouldn't expect the addresses to move if you didn't either
rebuild the kernel or had something else moving the kernel at boot (i.e.
the boot loader).

> I have these queries because,
> In one of the arm-32 devices with Kernel 4.14, I observed that
> CONFIG_RANDOMIZE_BASE is not available.
> But /proc/sys/kernel/randomize_va_space is set to 2.
> However, I also observed that symbol addresses are changing in every boot.
> 
> 1st boot cycle:
> [root ~]# cat /proc/kallsyms | grep "sys_open"
> a5b4de92 T sys_open
> [root@sa515m ~]#
> 
> 2nd boot cycle:
> [root ~]# cat /proc/kallsyms | grep "sys_open"
> f546ed66 T sys_open
> 
> So, I am wondering how this is possible without KASLR
> (CONFIG_RANDOMIZE_BASE) support in Kernel ?

What device is this? Is it a stock kernel?

> Similarly, with Kernel 4.9 and CONFIG_RANDOMIZE_BASE is not available
> but /proc/sys/kernel/randomize_va_space is set to 2.
> But here, the addresses are remaining same.
> 
> 1st Run:
> [root~]# cat /proc/kallsyms | grep "sys_open"
> c01ed68c T sys_open
> [root ~]#
> 
> *** reboot ***
> [root ~]# cat /proc/kallsyms | grep "sys_open"
> c01ed68c T sys_open
> 
> 
> Is there any other difference between these two kernel versions with
> respect to changing symbol addresses ?

Is the boot loader changing the base address? (What boot loader are you
using?)

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Ard Biesheuvel]

On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> > This is regarding the KASLR feature support on ARM for the kernel
> > version 4.9 and 4.14.
> >
> > Is KASLR supported on ARM-32 Linux 4.9 and above ?
>
> Sorry, this feature did not yet land in upstream:
> https://github.com/KSPP/linux/issues/3
>
> Here was the earlier effort:
> https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/
>
> > Is it dependent on CONFIG_RANDOMIZE_BASE or
>
> CONFIG_RANDOMIZE_BASE is what is used on other architectures to control
> the feature.
>
> > /proc/sys/kernel/randomize_va_space ?
> > Is there any relation between these two?
>
> No, the latter is about userspace addresses.
>
> > Is the changing kernel symbols (in every boot), only possible if KASLR
> > is enabled, or there is another way it can happen?
>
> I think you meant kernel symbol addresses (not the symbols themselves).
> But yes, I wouldn't expect the addresses to move if you didn't either
> rebuild the kernel or had something else moving the kernel at boot (i.e.
> the boot loader).
>
> > I have these queries because,
> > In one of the arm-32 devices with Kernel 4.14, I observed that
> > CONFIG_RANDOMIZE_BASE is not available.
> > But /proc/sys/kernel/randomize_va_space is set to 2.
> > However, I also observed that symbol addresses are changing in every boot.
> >
> > 1st boot cycle:
> > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > a5b4de92 T sys_open
> > [root@sa515m ~]#
> >
> > 2nd boot cycle:
> > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > f546ed66 T sys_open
> >
> > So, I am wondering how this is possible without KASLR
> > (CONFIG_RANDOMIZE_BASE) support in Kernel ?
>

Those addresses were obfuscated by kptr_restrict

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Kees Cook]

On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote:
> On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> > > This is regarding the KASLR feature support on ARM for the kernel
> > > version 4.9 and 4.14.
> > >
> > > Is KASLR supported on ARM-32 Linux 4.9 and above ?
> >
> > Sorry, this feature did not yet land in upstream:
> > https://github.com/KSPP/linux/issues/3
> >
> > Here was the earlier effort:
> > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/
> >
> > > Is it dependent on CONFIG_RANDOMIZE_BASE or
> >
> > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control
> > the feature.
> >
> > > /proc/sys/kernel/randomize_va_space ?
> > > Is there any relation between these two?
> >
> > No, the latter is about userspace addresses.
> >
> > > Is the changing kernel symbols (in every boot), only possible if KASLR
> > > is enabled, or there is another way it can happen?
> >
> > I think you meant kernel symbol addresses (not the symbols themselves).
> > But yes, I wouldn't expect the addresses to move if you didn't either
> > rebuild the kernel or had something else moving the kernel at boot (i.e.
> > the boot loader).
> >
> > > I have these queries because,
> > > In one of the arm-32 devices with Kernel 4.14, I observed that
> > > CONFIG_RANDOMIZE_BASE is not available.
> > > But /proc/sys/kernel/randomize_va_space is set to 2.
> > > However, I also observed that symbol addresses are changing in every boot.
> > >
> > > 1st boot cycle:
> > > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > > a5b4de92 T sys_open
> > > [root@sa515m ~]#
> > >
> > > 2nd boot cycle:
> > > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > > f546ed66 T sys_open
> > >
> > > So, I am wondering how this is possible without KASLR
> > > (CONFIG_RANDOMIZE_BASE) support in Kernel ?
> 
> Those addresses were obfuscated by kptr_restrict

Is that true? kptr_restrict zeros (rather than hashing) the kallsyms
view. And besides, the %p hashing was added in v4.15 (but also doesn't
touch kallsyms, which does all-or-nothing to avoid breaking stuff
like perf).

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Ard Biesheuvel]

On Fri, 25 Sep 2020 at 22:47, Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote:
> > On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote:
> > >
> > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> > > > This is regarding the KASLR feature support on ARM for the kernel
> > > > version 4.9 and 4.14.
> > > >
> > > > Is KASLR supported on ARM-32 Linux 4.9 and above ?
> > >
> > > Sorry, this feature did not yet land in upstream:
> > > https://github.com/KSPP/linux/issues/3
> > >
> > > Here was the earlier effort:
> > > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/
> > >
> > > > Is it dependent on CONFIG_RANDOMIZE_BASE or
> > >
> > > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control
> > > the feature.
> > >
> > > > /proc/sys/kernel/randomize_va_space ?
> > > > Is there any relation between these two?
> > >
> > > No, the latter is about userspace addresses.
> > >
> > > > Is the changing kernel symbols (in every boot), only possible if KASLR
> > > > is enabled, or there is another way it can happen?
> > >
> > > I think you meant kernel symbol addresses (not the symbols themselves).
> > > But yes, I wouldn't expect the addresses to move if you didn't either
> > > rebuild the kernel or had something else moving the kernel at boot (i.e.
> > > the boot loader).
> > >
> > > > I have these queries because,
> > > > In one of the arm-32 devices with Kernel 4.14, I observed that
> > > > CONFIG_RANDOMIZE_BASE is not available.
> > > > But /proc/sys/kernel/randomize_va_space is set to 2.
> > > > However, I also observed that symbol addresses are changing in every boot.
> > > >
> > > > 1st boot cycle:
> > > > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > > > a5b4de92 T sys_open
> > > > [root@sa515m ~]#
> > > >
> > > > 2nd boot cycle:
> > > > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > > > f546ed66 T sys_open
> > > >
> > > > So, I am wondering how this is possible without KASLR
> > > > (CONFIG_RANDOMIZE_BASE) support in Kernel ?
> >
> > Those addresses were obfuscated by kptr_restrict
>
> Is that true? kptr_restrict zeros (rather than hashing) the kallsyms
> view. And besides, the %p hashing was added in v4.15 (but also doesn't
> touch kallsyms, which does all-or-nothing to avoid breaking stuff
> like perf).
>

Ah yes, good point. But it does look suspiciously like they are being
mangled in a similar way.

For a 3/1 split ARM kernel of the typical size, all kernel virtual
addresses start with 0xc0, and given that the kernel is located at the
start of the linear map, those addresses cannot change even if you
move the kernel around in physical memory.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Kees Cook]

On Fri, Sep 25, 2020 at 11:09:10PM +0200, Ard Biesheuvel wrote:
> On Fri, 25 Sep 2020 at 22:47, Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote:
> > > >
> > > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote:
> > > > > This is regarding the KASLR feature support on ARM for the kernel
> > > > > version 4.9 and 4.14.
> > > > >
> > > > > Is KASLR supported on ARM-32 Linux 4.9 and above ?
> > > >
> > > > Sorry, this feature did not yet land in upstream:
> > > > https://github.com/KSPP/linux/issues/3
> > > >
> > > > Here was the earlier effort:
> > > > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/
> > > >
> > > > > Is it dependent on CONFIG_RANDOMIZE_BASE or
> > > >
> > > > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control
> > > > the feature.
> > > >
> > > > > /proc/sys/kernel/randomize_va_space ?
> > > > > Is there any relation between these two?
> > > >
> > > > No, the latter is about userspace addresses.
> > > >
> > > > > Is the changing kernel symbols (in every boot), only possible if KASLR
> > > > > is enabled, or there is another way it can happen?
> > > >
> > > > I think you meant kernel symbol addresses (not the symbols themselves).
> > > > But yes, I wouldn't expect the addresses to move if you didn't either
> > > > rebuild the kernel or had something else moving the kernel at boot (i.e.
> > > > the boot loader).
> > > >
> > > > > I have these queries because,
> > > > > In one of the arm-32 devices with Kernel 4.14, I observed that
> > > > > CONFIG_RANDOMIZE_BASE is not available.
> > > > > But /proc/sys/kernel/randomize_va_space is set to 2.
> > > > > However, I also observed that symbol addresses are changing in every boot.
> > > > >
> > > > > 1st boot cycle:
> > > > > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > > > > a5b4de92 T sys_open
> > > > > [root@sa515m ~]#
> > > > >
> > > > > 2nd boot cycle:
> > > > > [root ~]# cat /proc/kallsyms | grep "sys_open"
> > > > > f546ed66 T sys_open
> > > > >
> > > > > So, I am wondering how this is possible without KASLR
> > > > > (CONFIG_RANDOMIZE_BASE) support in Kernel ?
> > >
> > > Those addresses were obfuscated by kptr_restrict
> >
> > Is that true? kptr_restrict zeros (rather than hashing) the kallsyms
> > view. And besides, the %p hashing was added in v4.15 (but also doesn't
> > touch kallsyms, which does all-or-nothing to avoid breaking stuff
> > like perf).
> >
> 
> Ah yes, good point. But it does look suspiciously like they are being
> mangled in a similar way.
> 
> For a 3/1 split ARM kernel of the typical size, all kernel virtual
> addresses start with 0xc0, and given that the kernel is located at the
> start of the linear map, those addresses cannot change even if you
> move the kernel around in physical memory.

I wonder if this is an Android Common kernel? I think there was %p
hashing in there before v4.15, but with a different implementation...

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Sat, 26 Sep 2020 at 05:17, Kees Cook <keescook@chromium.org> wrote:
> >
> > For a 3/1 split ARM kernel of the typical size, all kernel virtual
> > addresses start with 0xc0, and given that the kernel is located at the
> > start of the linear map, those addresses cannot change even if you
> > move the kernel around in physical memory.
>
> I wonder if this is an Android Common kernel? I think there was %p
> hashing in there before v4.15, but with a different implementation...
>

Hi,
Thank you all for all your reply and comments so far!
Here are some follow-up replies.

>> What device is this? Is it a stock kernel?
This is a Qualcomm Snapdragon Automotive board one with Linux Kernel
4.9 and one with 4.14.

>> Is the boot loader changing the base address? (What boot loader are you
>> using?)
Ohh I did not knew that the bootloader can also change the base address.
I think it uses UEFI.
How to check if bootloader is doing this ?
BTW, both 4.9 board and 4.14 board, uses same bootloader.

>> I wonder if this is an Android Common kernel?
It uses the below kernel for 4.14:
https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
similar branch).
==> The case where symbol addresses are changing.

kptr_restrict is set to 2 by default:
/ # cat /proc/sys/kernel/kptr_restrict
2

Basically, the goal is:
* To understand how addresses are changing in 4.14 Kernel (without
KASLR support)?
* Is it possible to support the same in 4.9 Kernel ?

--
Thanks,
Pintu

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Kees Cook]

On Sat, Sep 26, 2020 at 01:28:02PM +0530, Pintu Agarwal wrote:
> On Sat, 26 Sep 2020 at 05:17, Kees Cook <keescook@chromium.org> wrote:
> > >
> > > For a 3/1 split ARM kernel of the typical size, all kernel virtual
> > > addresses start with 0xc0, and given that the kernel is located at the
> > > start of the linear map, those addresses cannot change even if you
> > > move the kernel around in physical memory.
> >
> > I wonder if this is an Android Common kernel? I think there was %p
> > hashing in there before v4.15, but with a different implementation...
> >
> 
> Hi,
> Thank you all for all your reply and comments so far!
> Here are some follow-up replies.
> 
> >> What device is this? Is it a stock kernel?
> This is a Qualcomm Snapdragon Automotive board one with Linux Kernel
> 4.9 and one with 4.14.
> 
> >> Is the boot loader changing the base address? (What boot loader are you
> >> using?)
> Ohh I did not knew that the bootloader can also change the base address.
> I think it uses UEFI.
> How to check if bootloader is doing this ?
> BTW, both 4.9 board and 4.14 board, uses same bootloader.
> 
> >> I wonder if this is an Android Common kernel?
> It uses the below kernel for 4.14:
> https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
> similar branch).

Okay, so yes. And this appears to have the hashing of %p backported. I
cannot, however, explain why it's showing hashed pointers instead of
just NULL, though.

It might be related to these commits but they're not in that kernel:
3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")

> ==> The case where symbol addresses are changing.
> 
> kptr_restrict is set to 2 by default:
> / # cat /proc/sys/kernel/kptr_restrict
> 2
> 
> Basically, the goal is:
> * To understand how addresses are changing in 4.14 Kernel (without
> KASLR support)?
> * Is it possible to support the same in 4.9 Kernel ?

Try setting kptr_restrict to 0 and see if the symbol addresses change? I
suspect Ard is correct: there's no KASLR here, just hashed pointers
behaving weird on an old non-stock kernel. :)

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Sat, 26 Sep 2020 at 22:10, Kees Cook <keescook@chromium.org> wrote:

> > >> I wonder if this is an Android Common kernel?
> > It uses the below kernel for 4.14:
> > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
> > similar branch).
>
> Okay, so yes. And this appears to have the hashing of %p backported. I
> cannot, however, explain why it's showing hashed pointers instead of
> just NULL, though.
>
> It might be related to these commits but they're not in that kernel:
> 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
>
> > ==> The case where symbol addresses are changing.
> >
> > kptr_restrict is set to 2 by default:
> > / # cat /proc/sys/kernel/kptr_restrict
> > 2
> >
> > Basically, the goal is:
> > * To understand how addresses are changing in 4.14 Kernel (without
> > KASLR support)?
> > * Is it possible to support the same in 4.9 Kernel ?
>
> Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> suspect Ard is correct: there's no KASLR here, just hashed pointers
> behaving weird on an old non-stock kernel. :)
>

Okay. Thank you so much for your comments and suggestions.
You mean to say, setting kptr_restrict to 0 may avoid changing symbol
addresses in 4.14 ?
And, sorry, I could not understand the thing about this "hashed pointers".
How can I check this behavior in source code to understand better?
Is it possible to give some reference ?
I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
Also if possible, we would like to make this similar change on 4.9
kernel as well.


Thanks,
Pintu

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Mon, 28 Sep 2020 at 19:15, Pintu Agarwal <pintu.ping@gmail.com> wrote:
>
> On Sat, 26 Sep 2020 at 22:10, Kees Cook <keescook@chromium.org> wrote:
>
> > > >> I wonder if this is an Android Common kernel?
> > > It uses the below kernel for 4.14:
> > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
> > > similar branch).
> >
> > Okay, so yes. And this appears to have the hashing of %p backported. I
> > cannot, however, explain why it's showing hashed pointers instead of
> > just NULL, though.
> >
> > It might be related to these commits but they're not in that kernel:
> > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
> >
> > > ==> The case where symbol addresses are changing.
> > >
> > > kptr_restrict is set to 2 by default:
> > > / # cat /proc/sys/kernel/kptr_restrict
> > > 2
> > >
> > > Basically, the goal is:
> > > * To understand how addresses are changing in 4.14 Kernel (without
> > > KASLR support)?
> > > * Is it possible to support the same in 4.9 Kernel ?
> >
> > Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> > suspect Ard is correct: there's no KASLR here, just hashed pointers
> > behaving weird on an old non-stock kernel. :)
> >
>
> Okay. Thank you so much for your comments and suggestions.
> You mean to say, setting kptr_restrict to 0 may avoid changing symbol
> addresses in 4.14 ?
> And, sorry, I could not understand the thing about this "hashed pointers".
> How can I check this behavior in source code to understand better?
> Is it possible to give some reference ?
> I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
> Also if possible, we would like to make this similar change on 4.9
> kernel as well.
>

Okay, I found these changes in 4.14 kernel:
https://gitlab.com/quicla/kernel/msm-4.14/-/commit/e63732dbfe017aa0dbabac9d096b5fde8afbd395

Are we talking about this?
I cound not find this in 4.9 kernel.

I will disable kptr_restrict and check or, I will enable
CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check.


Thanks,
Pintu

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Kees Cook]

On Mon, Sep 28, 2020 at 07:41:13PM +0530, Pintu Agarwal wrote:
> On Mon, 28 Sep 2020 at 19:15, Pintu Agarwal <pintu.ping@gmail.com> wrote:
> >
> > On Sat, 26 Sep 2020 at 22:10, Kees Cook <keescook@chromium.org> wrote:
> >
> > > > >> I wonder if this is an Android Common kernel?
> > > > It uses the below kernel for 4.14:
> > > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5  (or
> > > > similar branch).
> > >
> > > Okay, so yes. And this appears to have the hashing of %p backported. I
> > > cannot, however, explain why it's showing hashed pointers instead of
> > > just NULL, though.
> > >
> > > It might be related to these commits but they're not in that kernel:
> > > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> > > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
> > >
> > > > ==> The case where symbol addresses are changing.
> > > >
> > > > kptr_restrict is set to 2 by default:
> > > > / # cat /proc/sys/kernel/kptr_restrict
> > > > 2
> > > >
> > > > Basically, the goal is:
> > > > * To understand how addresses are changing in 4.14 Kernel (without
> > > > KASLR support)?
> > > > * Is it possible to support the same in 4.9 Kernel ?
> > >
> > > Try setting kptr_restrict to 0 and see if the symbol addresses change? I
> > > suspect Ard is correct: there's no KASLR here, just hashed pointers
> > > behaving weird on an old non-stock kernel. :)
> > >
> >
> > Okay. Thank you so much for your comments and suggestions.
> > You mean to say, setting kptr_restrict to 0 may avoid changing symbol
> > addresses in 4.14 ?
> > And, sorry, I could not understand the thing about this "hashed pointers".
> > How can I check this behavior in source code to understand better?
> > Is it possible to give some reference ?
> > I wanted to disable this hash pointer on 4.14 kernel and check the behavior.
> > Also if possible, we would like to make this similar change on 4.9
> > kernel as well.
> >
> 
> Okay, I found these changes in 4.14 kernel:
> https://gitlab.com/quicla/kernel/msm-4.14/-/commit/e63732dbfe017aa0dbabac9d096b5fde8afbd395

That's an out-of-tree patch. The one that was backported to 4.14 from
4.15 that does %p hashing is this one:
https://gitlab.com/quicla/kernel/msm-4.14/-/commit/ad67b74d2469d9b82aaa572d76474c95bc484d57

> Are we talking about this?
> I cound not find this in 4.9 kernel.

Note that I still can't explain what you're seeing. /proc/kallsyms
shouldn't be affected by these patches -- I would expect it to either
report the true value or 00s.

> I will disable kptr_restrict and check or, I will enable
> CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check.

I would start with kptr_restrict=0 and see if that changes the contents
of /proc/kallsyms. If it does, then it is the hashing. If it doesn't,
well, we're back to square one. :)

-- 
Kees Cook

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: KASLR support on ARM with Kernel 4.9 and 4.14

[Pintu Agarwal]

On Tue, 29 Sep 2020 at 01:20, Kees Cook <keescook@chromium.org> wrote:

> Note that I still can't explain what you're seeing. /proc/kallsyms
> shouldn't be affected by these patches -- I would expect it to either
> report the true value or 00s.
>
> > I will disable kptr_restrict and check or, I will enable
> > CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check.
>
> I would start with kptr_restrict=0 and see if that changes the contents
> of /proc/kallsyms. If it does, then it is the hashing. If it doesn't,
> well, we're back to square one. :)

Actually in that board, the kptr_restrict=0 already in both case: 4.9
and 4.14 Kernel boards.
In another board with 4.14 and kptr_restrict=2, I see that the
addresses are 00 always.

I further checked that when I enable this config:
CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS,
then the addresses are remaining the same in every boot.
But this particular config is not present in 4.9 Kernel.
So, I think it is controlled using this config.

--
Pintu

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies