Re: [PATCH 0/4] support for text-relative kallsyms table

[Rusty Russell]

Ard Biesheuvel  writes:
> On 21 January 2016 at 07:45, Ard Biesheuvel  wrote:
>> On 21 January 2016 at 06:10, Rusty Russell  wrote:
>>> Ard Biesheuvel  writes:
 This implements text-relative kallsyms address tables. This was developed
 as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
 I think it may be beneficial to other architectures as well, so I am
 presenting it as a separate series.
>>>
>>> Nice work!
>>>
>>
>> Thanks
>>
>>> AFAICT this should work for every arch, as long as they start with _text
>>> (esp: data and init must be > _text).  In addition, it's not harmful on
>>> 32 bit archs.
>>>
>>> IOW, I'd like to turn it on for everyone and discard some code.  But
>>> it's easier to roll in like you've done first.
>>>
>>> Should we enable it by default for every arch for now, and see what
>>> happens?
>>>
>>
>> As you say, this only works if every symbol >= _text, which is
>> obviously not the case per the conditional in scripts/kallsyms.c,
>> which emits _text + n or _text - n depending on whether the symbol
>> precedes or follows _text. The git log tells me for which arch this
>> was originally implemented, but it does not tell me which other archs
>> have come to rely on it in the meantime.
>>
>> On top of that, ia64 fails to build with this option, since it has
>> some whitelisted absolute symbols that look suspiciously like they
>> could be emitted as _text relative (and it does not even matter in the
>> absence of CONFIG_RELOCATABLE on ia64, afaict) but I don't know
>> whether we can just override their types as T, since it would also
>> change the type in the contents of /proc/kallsyms. So some guidance
>> would be appreciated here.
>>
>
> Digging a little deeper, it appears that it would be non-trivial to
> port this to ia64:
>
> ...
> a0040720 A __kernel_syscall_via_break
> a0040740 A __kernel_sigtramp
> a0040a00 A __kernel_syscall_via_epc
> a001 T ia64_ivt
> a001 T __start_ivt_text
> a001 T _stext
> a001 T _text
> ...
>
> The top three symbols are the absolute symbols that are explicitly
> whitelisted by scripts/kallsyms.c, and they are too far from 0 and too
> far from _text to be representable in 32 bits

How annoying.  OK, until ia64 is removed, we'll leave the option.

Thanks,
Rusty.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] support for text-relative kallsyms table

[Ard Biesheuvel]

On 21 January 2016 at 07:45, Ard Biesheuvel  wrote:
> On 21 January 2016 at 06:10, Rusty Russell  wrote:
>> Ard Biesheuvel  writes:
>>> This implements text-relative kallsyms address tables. This was developed
>>> as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
>>> I think it may be beneficial to other architectures as well, so I am
>>> presenting it as a separate series.
>>
>> Nice work!
>>
>
> Thanks
>
>> AFAICT this should work for every arch, as long as they start with _text
>> (esp: data and init must be > _text).  In addition, it's not harmful on
>> 32 bit archs.
>>
>> IOW, I'd like to turn it on for everyone and discard some code.  But
>> it's easier to roll in like you've done first.
>>
>> Should we enable it by default for every arch for now, and see what
>> happens?
>>
>
> As you say, this only works if every symbol >= _text, which is
> obviously not the case per the conditional in scripts/kallsyms.c,
> which emits _text + n or _text - n depending on whether the symbol
> precedes or follows _text. The git log tells me for which arch this
> was originally implemented, but it does not tell me which other archs
> have come to rely on it in the meantime.
>
> On top of that, ia64 fails to build with this option, since it has
> some whitelisted absolute symbols that look suspiciously like they
> could be emitted as _text relative (and it does not even matter in the
> absence of CONFIG_RELOCATABLE on ia64, afaict) but I don't know
> whether we can just override their types as T, since it would also
> change the type in the contents of /proc/kallsyms. So some guidance
> would be appreciated here.
>

Digging a little deeper, it appears that it would be non-trivial to
port this to ia64:

...
a0040720 A __kernel_syscall_via_break
a0040740 A __kernel_sigtramp
a0040a00 A __kernel_syscall_via_epc
a001 T ia64_ivt
a001 T __start_ivt_text
a001 T _stext
a001 T _text
...

The top three symbols are the absolute symbols that are explicitly
whitelisted by scripts/kallsyms.c, and they are too far from 0 and too
far from _text to be representable in 32 bits



> So I agree that it would be preferred to have a single code path, but
> I would need some help validating it on architectures I don't have
> access to.
>
> Thanks,
> Ard.
>
>
>>> The idea is that on 64-bit builds, it is rather wasteful to use absolute
>>> addressing for kernel symbols since they are all within a couple of MBs
>>> of each other. On top of that, the absolute addressing implies that, when
>>> the kernel is relocated at runtime, each address in the table needs to be
>>> fixed up individually.
>>>
>>> Since all section-relative addresses are already emitted relative to _text,
>>> it is quite straight-forward to record only the offset, and add the absolute
>>> address of _text at runtime when referring to the address table.
>>>
>>> The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB
>>> compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter 
>>> case,
>>> the reduction in uncompressed size is primarily __init data)
>>>
>>> Kees Cook was so kind to test these against x86_64, and confirmed that KASLR
>>> still operates as expected.
>>>
>>> Ard Biesheuvel (4):
>>>   kallsyms: add support for relative offsets in kallsyms address table
>>>   powerpc: enable text relative kallsyms for ppc64
>>>   s390: enable text relative kallsyms for 64-bit targets
>>>   x86_64: enable text relative kallsyms for 64-bit targets
>>>
>>>  arch/powerpc/Kconfig|  1 +
>>>  arch/s390/Kconfig   |  1 +
>>>  arch/x86/Kconfig|  1 +
>>>  init/Kconfig| 14 
>>>  kernel/kallsyms.c   | 35 +-
>>>  scripts/kallsyms.c  | 38 +---
>>>  scripts/link-vmlinux.sh |  4 +++
>>>  scripts/namespace.pl|  1 +
>>>  8 files changed, 82 insertions(+), 13 deletions(-)
>>>
>>> --
>>> 2.5.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] support for text-relative kallsyms table

[Ard Biesheuvel]

On 21 January 2016 at 06:10, Rusty Russell  wrote:
> Ard Biesheuvel  writes:
>> This implements text-relative kallsyms address tables. This was developed
>> as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
>> I think it may be beneficial to other architectures as well, so I am
>> presenting it as a separate series.
>
> Nice work!
>

Thanks

> AFAICT this should work for every arch, as long as they start with _text
> (esp: data and init must be > _text).  In addition, it's not harmful on
> 32 bit archs.
>
> IOW, I'd like to turn it on for everyone and discard some code.  But
> it's easier to roll in like you've done first.
>
> Should we enable it by default for every arch for now, and see what
> happens?
>

As you say, this only works if every symbol >= _text, which is
obviously not the case per the conditional in scripts/kallsyms.c,
which emits _text + n or _text - n depending on whether the symbol
precedes or follows _text. The git log tells me for which arch this
was originally implemented, but it does not tell me which other archs
have come to rely on it in the meantime.

On top of that, ia64 fails to build with this option, since it has
some whitelisted absolute symbols that look suspiciously like they
could be emitted as _text relative (and it does not even matter in the
absence of CONFIG_RELOCATABLE on ia64, afaict) but I don't know
whether we can just override their types as T, since it would also
change the type in the contents of /proc/kallsyms. So some guidance
would be appreciated here.

So I agree that it would be preferred to have a single code path, but
I would need some help validating it on architectures I don't have
access to.

Thanks,
Ard.


>> The idea is that on 64-bit builds, it is rather wasteful to use absolute
>> addressing for kernel symbols since they are all within a couple of MBs
>> of each other. On top of that, the absolute addressing implies that, when
>> the kernel is relocated at runtime, each address in the table needs to be
>> fixed up individually.
>>
>> Since all section-relative addresses are already emitted relative to _text,
>> it is quite straight-forward to record only the offset, and add the absolute
>> address of _text at runtime when referring to the address table.
>>
>> The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB
>> compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter 
>> case,
>> the reduction in uncompressed size is primarily __init data)
>>
>> Kees Cook was so kind to test these against x86_64, and confirmed that KASLR
>> still operates as expected.
>>
>> Ard Biesheuvel (4):
>>   kallsyms: add support for relative offsets in kallsyms address table
>>   powerpc: enable text relative kallsyms for ppc64
>>   s390: enable text relative kallsyms for 64-bit targets
>>   x86_64: enable text relative kallsyms for 64-bit targets
>>
>>  arch/powerpc/Kconfig|  1 +
>>  arch/s390/Kconfig   |  1 +
>>  arch/x86/Kconfig|  1 +
>>  init/Kconfig| 14 
>>  kernel/kallsyms.c   | 35 +-
>>  scripts/kallsyms.c  | 38 +---
>>  scripts/link-vmlinux.sh |  4 +++
>>  scripts/namespace.pl|  1 +
>>  8 files changed, 82 insertions(+), 13 deletions(-)
>>
>> --
>> 2.5.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] support for text-relative kallsyms table

[Rusty Russell]

Ard Biesheuvel  writes:
> This implements text-relative kallsyms address tables. This was developed
> as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
> I think it may be beneficial to other architectures as well, so I am
> presenting it as a separate series.

Nice work!

AFAICT this should work for every arch, as long as they start with _text
(esp: data and init must be > _text).  In addition, it's not harmful on
32 bit archs.

IOW, I'd like to turn it on for everyone and discard some code.  But
it's easier to roll in like you've done first.

Should we enable it by default for every arch for now, and see what
happens?

Thanks!
Rusty.

> The idea is that on 64-bit builds, it is rather wasteful to use absolute
> addressing for kernel symbols since they are all within a couple of MBs
> of each other. On top of that, the absolute addressing implies that, when
> the kernel is relocated at runtime, each address in the table needs to be
> fixed up individually.
>
> Since all section-relative addresses are already emitted relative to _text,
> it is quite straight-forward to record only the offset, and add the absolute
> address of _text at runtime when referring to the address table.
>
> The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB
> compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter case,
> the reduction in uncompressed size is primarily __init data)
>
> Kees Cook was so kind to test these against x86_64, and confirmed that KASLR
> still operates as expected.
>
> Ard Biesheuvel (4):
>   kallsyms: add support for relative offsets in kallsyms address table
>   powerpc: enable text relative kallsyms for ppc64
>   s390: enable text relative kallsyms for 64-bit targets
>   x86_64: enable text relative kallsyms for 64-bit targets
>
>  arch/powerpc/Kconfig|  1 +
>  arch/s390/Kconfig   |  1 +
>  arch/x86/Kconfig|  1 +
>  init/Kconfig| 14 
>  kernel/kallsyms.c   | 35 +-
>  scripts/kallsyms.c  | 38 +---
>  scripts/link-vmlinux.sh |  4 +++
>  scripts/namespace.pl|  1 +
>  8 files changed, 82 insertions(+), 13 deletions(-)
>
> -- 
> 2.5.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/4] support for text-relative kallsyms table

[Ard Biesheuvel]

This implements text-relative kallsyms address tables. This was developed
as part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but
I think it may be beneficial to other architectures as well, so I am
presenting it as a separate series.

The idea is that on 64-bit builds, it is rather wasteful to use absolute
addressing for kernel symbols since they are all within a couple of MBs
of each other. On top of that, the absolute addressing implies that, when
the kernel is relocated at runtime, each address in the table needs to be
fixed up individually.

Since all section-relative addresses are already emitted relative to _text,
it is quite straight-forward to record only the offset, and add the absolute
address of _text at runtime when referring to the address table.

The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB
compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter case,
the reduction in uncompressed size is primarily __init data)

Kees Cook was so kind to test these against x86_64, and confirmed that KASLR
still operates as expected.

Ard Biesheuvel (4):
  kallsyms: add support for relative offsets in kallsyms address table
  powerpc: enable text relative kallsyms for ppc64
  s390: enable text relative kallsyms for 64-bit targets
  x86_64: enable text relative kallsyms for 64-bit targets

 arch/powerpc/Kconfig|  1 +
 arch/s390/Kconfig   |  1 +
 arch/x86/Kconfig|  1 +
 init/Kconfig| 14 
 kernel/kallsyms.c   | 35 +-
 scripts/kallsyms.c  | 38 +---
 scripts/link-vmlinux.sh |  4 +++
 scripts/namespace.pl|  1 +
 8 files changed, 82 insertions(+), 13 deletions(-)

-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] support for text-relative kallsyms table

[Ingo Molnar]

* Ard Biesheuvel  wrote:

> This implements text-relative kallsyms address tables. This was developed as 
> part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but I 
> think 
> it may be beneficial to other architectures as well, so I am presenting it as 
> a 
> separate series.
> 
> The idea is that on 64-bit builds, it is rather wasteful to use absolute 
> addressing for kernel symbols since they are all within a couple of MBs of 
> each 
> other. On top of that, the absolute addressing implies that, when the kernel 
> is 
> relocated at runtime, each address in the table needs to be fixed up 
> individually.
> 
> Since all section-relative addresses are already emitted relative to _text, 
> it 
> is quite straight-forward to record only the offset, and add the absolute 
> address of _text at runtime when referring to the address table.
> 
> The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB 
> compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter 
> case, 
> the reduction in uncompressed size is primarily __init data)

So since kallsyms is in unswappable kernel RAM, the uncompressed size reduction 
is 
what we care about mostly. How much bootloader load times are impacted is a 
third 
order concern.

IOW a nice change!

Thanks,

Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] support for text-relative kallsyms table

[Arnd Bergmann]

On Wednesday 20 January 2016 11:33:25 Ingo Molnar wrote:
> > The reduction ranges from around 250 KB uncompressed vmlinux size and 10 KB 
> > compressed size (s390) to 3 MB/500 KB for ppc64 (although, in the latter 
> > case, 
> > the reduction in uncompressed size is primarily __init data)
> 
> So since kallsyms is in unswappable kernel RAM, the uncompressed size 
> reduction is 
> what we care about mostly. How much bootloader load times are impacted is a 
> third 
> order concern.
> 
> IOW a nice change!

I think some people care a lot about the compressed size as well:

http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-4.4/203-kallsyms_uncompressed.patch;h=cf8a447bbcd5b1621d4edc36a69fe0ad384fe53f;hb=HEAD

This has been in openwrt.git for ages, because a lot of the target devices
are much more limited on flash memory size (4MB typically) than they are
on RAM size (at least 32MB).

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev