patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
In this patchset we also consolidate instruction changes
in kprobes to use patch_instruction().
Balbir Singh (2):
powerpc/lib/code-patching: Enhance code patching
powerpc/kprobes: Move kprobes over to patch_instruction
arch/powerpc/kernel/kprobes.c | 4 +-
arch/powerpc/lib/code-patching.c | 88 ++++++++++++++++++++++++++++++++++++++--
2 files changed, 86 insertions(+), 6 deletions(-)
--
2.9.3
Today our patching happens via direct copy and
patch_instruction. The patching code is well
contained in the sense that copying bits are limited.
While considering implementation of CONFIG_STRICT_RWX,
the first requirement is to a create another mapping
that will allow for patching. We create the window using
text_poke_area, allocated via get_vm_area(), which might
be an overkill. We can do per-cpu stuff as well. The
downside of these patches that patch_instruction is
now synchornized using a lock. Other arches do similar
things, but use fixmaps. The reason for not using
fixmaps is to make use of any randomization in the
future. The code also relies on set_pte_at and pte_clear
to do the appropriate tlb flushing.
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
---
arch/powerpc/lib/code-patching.c | 88 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 84 insertions(+), 4 deletions(-)
patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
Why writing instruction directly into the address is not
sufficient and need to go through this virtual address ?
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
So whats the benifits we get otherwise in this approach when
we are adding a new lock into the equation.
From: Naveen N. Rao <hidden> Date: 2017-05-16 13:36:30
On 2017/05/16 01:49PM, Balbir Singh wrote:
arch_arm/disarm_probe use direct assignment for copying
instructions, replace them with patch_instruction
Thanks for doing this!
We will also have to convert optprobes and ftrace to use
patch_instruction, but that can be done once the basic infrastructure is
in.
Regards,
Naveen
From: Naveen N. Rao <hidden> Date: 2017-05-16 13:42:40
On 2017/05/16 10:56AM, Anshuman Khandual wrote:
On 05/16/2017 09:19 AM, Balbir Singh wrote:
quoted
patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
Why writing instruction directly into the address is not
sufficient and need to go through this virtual address ?
To enable KERNEL_STRICT_RWX and map all of kernel text to be read-only?
quoted
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
So whats the benifits we get otherwise in this approach when
we are adding a new lock into the equation.
Instruction patching isn't performance critical, so the slow down is
likely not noticeable. Marking kernel text read-only helps harden the
kernel by catching unintended code modifications whether through
exploits or through bugs.
- Naveen
patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
Very nice patch, would fit great with my patch for impmementing=20=20
CONFIG_DEBUG_RODATA=20(https://patchwork.ozlabs.org/patch/754289 ).
Would avoid having to set the text area back to RW for patching
Christophe
In this patchset we also consolidate instruction changes
in kprobes to use patch_instruction().
Balbir Singh (2):
powerpc/lib/code-patching: Enhance code patching
powerpc/kprobes: Move kprobes over to patch_instruction
arch/powerpc/kernel/kprobes.c | 4 +-
arch/powerpc/lib/code-patching.c | 88=20=20
=20++++++++++++++++++++++++++++++++++++++--
2 files changed, 86 insertions(+), 6 deletions(-)
--
2.9.3
On Tue, 2017-05-16 at 19:11 +0530, Naveen N. Rao wrote:
On 2017/05/16 10:56AM, Anshuman Khandual wrote:
quoted
On 05/16/2017 09:19 AM, Balbir Singh wrote:
quoted
patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
Why writing instruction directly into the address is not
sufficient and need to go through this virtual address ?
To enable KERNEL_STRICT_RWX and map all of kernel text to be read-only?
Precisely, the rest of the bits are still being developed.
quoted
quoted
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
So whats the benifits we get otherwise in this approach when
we are adding a new lock into the equation.
Instruction patching isn't performance critical, so the slow down is
likely not noticeable. Marking kernel text read-only helps harden the
kernel by catching unintended code modifications whether through
exploits or through bugs.
On Tue, 2017-05-16 at 19:05 +0530, Naveen N. Rao wrote:
On 2017/05/16 01:49PM, Balbir Singh wrote:
quoted
arch_arm/disarm_probe use direct assignment for copying
instructions, replace them with patch_instruction
Thanks for doing this!
We will also have to convert optprobes and ftrace to use
patch_instruction, but that can be done once the basic infrastructure is
in.
I think these patches can go in without even patch 1. I looked quickly at
optprobes and ftrace and thought they were already using patch_instruction
(ftrace_modify_code() and arch_optimize_kprobes()), are there other paths
I missed?
Balbir Singh
On Tue, 2017-05-16 at 22:20 +0200, LEROY Christophe wrote:
Balbir Singh [off-list ref] a écrit :
quoted
patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
Very nice patch, would fit great with my patch for impmementing
CONFIG_DEBUG_RODATA (https://patchwork.ozlabs.org/patch/754289 ).
Would avoid having to set the text area back to RW for patching
Awesome! It seems like you have some of the work for CONFIG_STRICT_KERNEL_RWX
any reason why this is under CONFIG_DEBUG_RODATA? But I think there is
reuse capability across the future patches and the current set.
Cheers,
Balbir Singh.
On Tue, 2017-05-16 at 22:20 +0200, LEROY Christophe wrote:
quoted
Balbir Singh [off-list ref] a =C3=A9crit=C2=A0:
quoted
patch_instruction is enhanced in this RFC to support
patching via a different virtual address (text_poke_area).
The mapping of text_poke_area->addr is RW and not RWX.
This way the mapping allows write for patching and then we tear
down the mapping. The downside is that we introduce a spinlock
which serializes our patching to one patch at a time.
Very nice patch, would fit great with my patch for impmementing
CONFIG_DEBUG_RODATA (https://patchwork.ozlabs.org/patch/754289 ).
Would avoid having to set the text area back to RW for patching
Awesome! It seems like you have some of the work for CONFIG_STRICT_KERNEL=
_RWX
any reason why this is under CONFIG_DEBUG_RODATA? But I think there is
reuse capability across the future patches and the current set.
From: Naveen N. Rao <hidden> Date: 2017-05-30 14:29:53
On 2017/05/17 11:40AM, Balbir Singh wrote:
On Tue, 2017-05-16 at 19:05 +0530, Naveen N. Rao wrote:
quoted
On 2017/05/16 01:49PM, Balbir Singh wrote:
quoted
arch_arm/disarm_probe use direct assignment for copying
instructions, replace them with patch_instruction
Thanks for doing this!
We will also have to convert optprobes and ftrace to use
patch_instruction, but that can be done once the basic infrastructure is
in.
I think these patches can go in without even patch 1. I looked quickly at
optprobes and ftrace and thought they were already using patch_instruction
(ftrace_modify_code() and arch_optimize_kprobes()), are there other paths
I missed?
[Sorry for the delay...]
Yes, all the patch_*_insns() functions need to be converted since the
area they patch comes from .text. There is also a memcpy() where we copy
the instruction template in, so perhaps a patch_instructions() helper
may be useful too.
- Naveen