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

Groups > linux.kernel > #1340079 > unrolled thread

Re: [PATCH] lkdtm: add test for executing .rodata

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: [PATCH] lkdtm: add test for executing .rodata "PaX Team" <pageexec@freemail.hu> - 2016-02-23 00:30 +0100
    Re: [PATCH] lkdtm: add test for executing .rodata Kees Cook <keescook@chromium.org> - 2016-02-23 22:00 +0100
      Re: [PATCH] lkdtm: add test for executing .rodata Kees Cook <keescook@chromium.org> - 2016-02-23 23:10 +0100
      Re: [PATCH] lkdtm: add test for executing .rodata "PaX Team" <pageexec@freemail.hu> - 2016-02-23 23:10 +0100

#1340079 — Re: [PATCH] lkdtm: add test for executing .rodata

On 22 Feb 2016 at 12:46, Kees Cook wrote:

> GCC really wants to declare the section. :(

hmm, i see, so how about going about it another way. instead of trying
to do this at compile/link time, do it an load/runtime. one way of doing
it would be to preserve a page in .rodata then map in a code page underneath
that holds your empty function (which you can generate from C). it'd be
somewhat similar to how the vsyscall page on amd64 is mapped (or used to
be mapped) from the kernel image into its userland visible place.

[toc] | [next] | [standalone]

#1341028

On Mon, Feb 22, 2016 at 3:21 PM, PaX Team <pageexec@freemail.hu> wrote:
> On 22 Feb 2016 at 12:46, Kees Cook wrote:
>
>> GCC really wants to declare the section. :(
>
> hmm, i see, so how about going about it another way. instead of trying
> to do this at compile/link time, do it an load/runtime. one way of doing
> it would be to preserve a page in .rodata then map in a code page underneath
> that holds your empty function (which you can generate from C). it'd be
> somewhat similar to how the vsyscall page on amd64 is mapped (or used to
> be mapped) from the kernel image into its userland visible place.

I prefer using all the "regular" mechanisms so that I really know I'm
exercising the actual case I want to be testing. (i.e. I don't want to
bypass the linker.)

If only there were some way to filter gcc output, like with plugins. ;)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

#1341116

On Tue, Feb 23, 2016 at 2:00 PM, PaX Team <pageexec@freemail.hu> wrote:
> On 23 Feb 2016 at 12:53, Kees Cook wrote:
>
>> I prefer using all the "regular" mechanisms so that I really know I'm
>> exercising the actual case I want to be testing. (i.e. I don't want to
>> bypass the linker.)
>>
>> If only there were some way to filter gcc output, like with plugins. ;)
>
> plugins can set/override section flags, initify and constify both do in
> fact but i guess that's little help for your generic case that has to
> work without them as well.

I don't mind using a plugin to get the linker to see the right flags. :)

I'm hoping someone will take pity on me in the kbuild list.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

#1341122

On 23 Feb 2016 at 12:53, Kees Cook wrote:

> I prefer using all the "regular" mechanisms so that I really know I'm
> exercising the actual case I want to be testing. (i.e. I don't want to
> bypass the linker.)
> 
> If only there were some way to filter gcc output, like with plugins. ;)

plugins can set/override section flags, initify and constify both do in
fact but i guess that's little help for your generic case that has to
work without them as well.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web