From: Ho-Eun Ryu <hoeun.ryu@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org, Jessica Yu <jeyu@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [kernel-hardening] [RFC 3/7] module: modify memory attrs for __ro_mostly_after_init during module_init/exit
Date: Tue, 21 Feb 2017 22:36:05 +0900 [thread overview]
Message-ID: <BD3E52DE-98B0-4DC0-8DCB-540599FC876C@gmail.com> (raw)
In-Reply-To: <20170220103008.GC9003@leverpostej>
> On 20 Feb 2017, at 7:30 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Sun, Feb 19, 2017 at 07:04:06PM +0900, Hoeun Ryu wrote:
>> `__ro_mostly_after_init` is almost like `__ro_after_init`. The section is
>> read-only as same as `__ro_after_init` after kernel init. This patch makes
>> `__ro_mostly_after_init` section read-write temporarily only during
>> module_init/module_exit.
>>
>> Signed-off-by: Hoeun Ryu <hoeun.ryu@gmail.com>
>> ---
>> kernel/module.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 7eba6de..3b25e0e 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -987,8 +987,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
>>
>> mutex_unlock(&module_mutex);
>> /* Final destruction now no one is using it. */
>> - if (mod->exit != NULL)
>> + if (mod->exit != NULL) {
>> + set_ro_mostly_after_init_rw();
>> mod->exit();
>> + set_ro_mostly_after_init_ro();
>> + }
>> blocking_notifier_call_chain(&module_notify_list,
>> MODULE_STATE_GOING, mod);
>> klp_module_going(mod);
>> @@ -3396,8 +3399,11 @@ static noinline int do_init_module(struct module *mod)
>>
>> do_mod_ctors(mod);
>> /* Start the module */
>> - if (mod->init != NULL)
>> + if (mod->init != NULL) {
>> + set_ro_mostly_after_init_rw();
>> ret = do_one_initcall(mod->init);
>> + set_ro_mostly_after_init_ro();
>> + }
>
> This looks very much like the pax_{open,close}_kernel() approach for
> write-rarely data.
I read the discussion [1] and I agree that __ro_mostly_after_init marker
looks very similar to __write_rarely.
>
> I think it would be better to implement a first class write-rarely
> mechanism rather than trying to extend __ro_after_init to cover this
> case.
I’m not extending __ro_after_init. __ro_mostly_after_init resides in the same section of rodata though.
>
> As mentioned previously, I *think* we can have a generic implementation
> that uses an mm to temporarily map a (thread/cpu-local) RW alias of the
> data in question in what would otherwise be the user half of the address
> space. Regardless, we can have a generic interface [1] that can cater
> for that style of approach and/or something like ARM's domains or x86's
> pkeys.
>
I’m still learning cpu/kernel architectures, It would be very thankful if you tell me more about the detail of the implementation itself.
The mm that maps temporary RW alias is like
* special mm like idmap/init_mm which have its own page tables?
* the page tables have the same content of page tables of init_mm’s swapper_pg_dir except for RW permissions for a specific section (let’s say __write_rarely)
* then use switch_mm(special_rw_mm) to change the address space before the access happens to the section
* then use switch_mm(current->mm) to change the address space to original after the access is done
And the interface itself. rare_write(__val, __val), is it a single value access interface.
I’m intending to make data in __ro_mostly_after_init section RW during multiple accesses like during module_init/exit.
and __rare_rw_map()/unmap() used in rare_write() seems to work like open/close api.
How could __rare_rw_ptr() be implemented and what happens when `__rw_var = __rare_rw_ptr(&(__var))` is done ?
However the interface will look like, Do we still need a special data section that is mapped RO in general but RW in some cases ?
if then, doesn’t __ro_mostly_after_init marker itself make sense and we still need it ?
> Thanks,
> Mark.
>
> [1] http://www.openwall.com/lists/kernel-hardening/2016/11/18/3
next prev parent reply other threads:[~2017-02-21 13:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-19 10:04 [RFC 1/7] arch: add __ro_mostly_after_init section marker Hoeun Ryu
2017-02-19 10:04 ` [RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function Hoeun Ryu
2017-02-20 10:22 ` [kernel-hardening] " Mark Rutland
2017-02-21 6:33 ` Ho-Eun Ryu
2017-02-19 10:04 ` [RFC 3/7] module: modify memory attrs for __ro_mostly_after_init during module_init/exit Hoeun Ryu
2017-02-20 10:30 ` [kernel-hardening] " Mark Rutland
2017-02-21 13:36 ` Ho-Eun Ryu [this message]
2017-02-21 13:58 ` Mark Rutland
2017-02-22 13:45 ` Hoeun Ryu
2017-02-19 10:04 ` [RFC 4/7] selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops Hoeun Ryu
2017-02-21 10:35 ` Tetsuo Handa
2017-02-19 10:04 ` [RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states Hoeun Ryu
2017-02-20 8:20 ` Sebastian Andrzej Siewior
2017-02-21 5:47 ` Ho-Eun Ryu
2017-02-19 10:04 ` [RFC 6/7] arm64: add __map_kernel_segment to accept additional vm flags Hoeun Ryu
2017-02-19 11:21 ` Ard Biesheuvel
2017-02-19 10:04 ` [RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section Hoeun Ryu
2017-02-19 11:35 ` Ard Biesheuvel
2017-02-20 12:45 ` Mark Rutland
2017-02-21 20:38 ` Kees Cook
2017-02-19 11:24 ` [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker Ard Biesheuvel
2017-02-21 6:29 ` Ho-Eun Ryu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BD3E52DE-98B0-4DC0-8DCB-540599FC876C@gmail.com \
--to=hoeun.ryu@gmail.com \
--cc=jeyu@redhat.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®