From: laura@labbott.name (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport
Date: Mon, 2 Nov 2015 09:40:47 -0800 [thread overview]
Message-ID: <5637A01F.4090806@labbott.name> (raw)
In-Reply-To: <56343BF2.1070800@huawei.com>
(adding Kees to see if he has any inputs)
On 10/30/15 8:56 PM, Xishi Qiu wrote:
> On 2015/10/30 23:05, Laura Abbott wrote:
>
>>>>
>>>> Hi Daniel,
>>>>
>>>> Sorry for didn't saying it clearly. I find this
>>>> interface(set_memory_ro/rw) can
>>>> only be used in module address. So why not extend the function? e.g.
>>>> like x86,
>>>> it can be used in direct mapping address too.
>>>>
>>>> Is there some limits in arm64 or we will do this later?
>>>>
>>>
>>> arm64 maps low mem (all direct mapped memory on arm64) with section
>>> mappings for performance. set_memory_ro/rw works on PAGE_SIZE
>>> granularity so if we wanted to use those functions on direct mapped
>>> memory we would need to break down the section mappings. On arm,
>>> this was a pain due to the TLB maintaince requried. On arm64, less
>>> so but we still lose the benefit of the section mappings.
>>>
>>> Do you have a use case in mind for wanting to use set_memory_ro/rw
>>> outside of the module area?
>>>
>
> Hi Laura,
>
> How about this case?
>
> module alloc some pages which from direct mapping area, and we write
> important data(e.g. password) on the pages, the data will not be changed
> during the runtime. If someone unfriendly try to rewrite the memory,
> something is going to get worse. So we can use set_memory_ro() to protect
> the date.
>
How long would you expected this data to stay around (minutes? hours?)
and how many instances of this would you expect?
It also looks like BPF wants to set its region as ro when in use
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/filter.h#n370)
So it's not completely unheard of.
I don't think it would be too difficult to take the
split_{pud,pmd} functions used for the direct mapping and apply them
for the page_attr if people are willing to make the security/performance
trade off.
Thanks,
Laura
next prev parent reply other threads:[~2015-11-02 17:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5633279A.7000003@huawei.com>
[not found] ` <56332ADB.7030306@iogearbox.net>
[not found] ` <563335FF.5020400@huawei.com>
2015-10-30 15:01 ` arm64: about Add CONFIG_DEBUG_SET_MODULE_RONX suport Laura Abbott
2015-10-30 15:05 ` Laura Abbott
2015-10-31 3:56 ` Xishi Qiu
2015-11-02 17:40 ` Laura Abbott [this message]
2015-11-03 1:24 ` Kees Cook
2015-11-03 2:14 ` Xishi Qiu
2015-11-03 9:10 ` Daniel Borkmann
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=5637A01F.4090806@labbott.name \
--to=laura@labbott.name \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).