(2013/07/12 1:46), Steven Rostedt wrote:
> On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote:
>
>> The current code assumes that one of the two code sequences is a NOP,
>> and therefore that jumping over the region is legal. This does not
>> allow for transitioning one active code sequence
(2013/07/11 19:51), Jiri Kosina wrote:
>>> + * - update all but the first byte of the patched range
>>> + * - sync cores
>>> + * - replalace the first byte (int3) by the first byte of
>>> + * replacing opcode
>>> + * - sync cores
>>> + *
>>> + * Note: must be called under text_mutex.
>>> + */
On 07/11/2013 12:29 PM, Jiri Kosina wrote:
> On Thu, 11 Jul 2013, H. Peter Anvin wrote:
>
+ * The way it is done:
+ *- add a int3 trap to the address that will be patched
+ *- sync cores
>>>
>>> You don't need this "sync cores". (and your code didn't) :)
>>
>> I
On 07/11/2013 12:29 PM, Jiri Kosina wrote:
> On Thu, 11 Jul 2013, H. Peter Anvin wrote:
>
+ * The way it is done:
+ *- add a int3 trap to the address that will be patched
+ *- sync cores
>>>
>>> You don't need this "sync cores". (and your code didn't) :)
>>
>> I
On Thu, 2013-07-11 at 21:43 +0200, Jiri Kosina wrote:
> OTOH we apparently don't need the one after the text_poke() below, as
> syncing the cores just after patching the first byte afterwards provides
> safe enough guard (at least according to hpa's words back in 2010 :) ).
Right, but I'm
On Thu, 11 Jul 2013, Steven Rostedt wrote:
[ .. snip .. ]
> > + smp_wmb();
> > +
> > + text_poke(addr, , sizeof(int3));
> > +
> > + if (len - sizeof(int3) > 0) {
>
> I believe we need a sync here. Otherwise, if the instruction crosses
> cache lines, the original first byte could have been
On Thu, 11 Jul 2013, H. Peter Anvin wrote:
> >> + * The way it is done:
> >> + *- add a int3 trap to the address that will be patched
> >> + *- sync cores
> >
> > You don't need this "sync cores". (and your code didn't) :)
>
> I believe you do, lest you get "Frankenstructions".
On Thu, 11 Jul 2013, Steven Rostedt wrote:
> > The current code assumes that one of the two code sequences is a NOP,
> > and therefore that jumping over the region is legal. This does not
> > allow for transitioning one active code sequence to another.
>
> Correct, and I think we should keep
On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote:
> The current code assumes that one of the two code sequences is a NOP,
> and therefore that jumping over the region is legal. This does not
> allow for transitioning one active code sequence to another.
Correct, and I think we should
On 07/11/2013 03:09 AM, Jiri Kosina wrote:
>>
>> I'm wondering if it would be easier/more general to just return to the
>> instruction. The "more general" bit would allow this to be used for
>> other things, like alternatives,
>
> As Boris already pointed out, this is not really that
On 07/11/2013 03:23 AM, Masami Hiramatsu wrote:
>> + *
>> + * The way it is done:
>> + * - add a int3 trap to the address that will be patched
>> + * - sync cores
>
> You don't need this "sync cores". (and your code didn't) :)
>
I believe you do, lest you get "Frankenstructions". I believe
On Wed, 2013-07-10 at 23:31 +0200, Jiri Kosina wrote:
> Changes:
>
> v1 -> v2:
> + fixed kerneldoc
> + fixed checkpatch errors (reported by Borislav)
>
> arch/x86/include/asm/alternative.h |1 +
> arch/x86/kernel/alternative.c | 101
>
>
On 07/11/2013 10:35 AM, Steven Rostedt wrote:
> On Wed, 2013-07-10 at 14:36 -0700, H. Peter Anvin wrote:
>> On 07/10/2013 02:31 PM, Jiri Kosina wrote:
>>> If any CPU instruction execution would collide with the patching,
>>> it'd be trapped by the int3 breakpoint and redirected to the provided
>>>
On Wed, 2013-07-10 at 14:36 -0700, H. Peter Anvin wrote:
> On 07/10/2013 02:31 PM, Jiri Kosina wrote:
> >
> > If any CPU instruction execution would collide with the patching,
> > it'd be trapped by the int3 breakpoint and redirected to the provided
> > "handler" (which would typically mean just
On Thu, 11 Jul 2013, Jiri Kosina wrote:
> > Returning to the instruction will, in effect, be a busy-wait for the
> > faulted CPU until the patch is complete; more or less what stop_machine
> > would do, but only for a CPU which actually strays into the affected
> > region.
>
> To be honest, I
On Thu, 11 Jul 2013, Masami Hiramatsu wrote:
> > + * text_poke_bp() -- update instructions on live kernel on SMP
> > + * @addr: address to patch
> > + * @opcode:opcode of new instruction
> > + * @len: length to copy
> > + * @handler: address to jump to when the temporary
(2013/07/11 6:31), Jiri Kosina wrote:
> +/*
> + * text_poke_bp() -- update instructions on live kernel on SMP
> + * @addr:address to patch
> + * @opcode: opcode of new instruction
> + * @len: length to copy
> + * @handler: address to jump to when the temporary breakpoint is hit
> + *
> +
On Wed, 10 Jul 2013, H. Peter Anvin wrote:
> > If any CPU instruction execution would collide with the patching,
> > it'd be trapped by the int3 breakpoint and redirected to the provided
> > "handler" (which would typically mean just skipping over the patched
> > region, acting as "nop" has been
On Wed, 10 Jul 2013, H. Peter Anvin wrote:
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
handler (which would typically mean just skipping over the patched
region, acting as nop has been there, in
(2013/07/11 6:31), Jiri Kosina wrote:
+/*
+ * text_poke_bp() -- update instructions on live kernel on SMP
+ * @addr:address to patch
+ * @opcode: opcode of new instruction
+ * @len: length to copy
+ * @handler: address to jump to when the temporary breakpoint is hit
+ *
+
+ *
On Thu, 11 Jul 2013, Masami Hiramatsu wrote:
+ * text_poke_bp() -- update instructions on live kernel on SMP
+ * @addr: address to patch
+ * @opcode:opcode of new instruction
+ * @len: length to copy
+ * @handler: address to jump to when the temporary breakpoint is hit
On Thu, 11 Jul 2013, Jiri Kosina wrote:
Returning to the instruction will, in effect, be a busy-wait for the
faulted CPU until the patch is complete; more or less what stop_machine
would do, but only for a CPU which actually strays into the affected
region.
To be honest, I fail to
On Wed, 2013-07-10 at 14:36 -0700, H. Peter Anvin wrote:
On 07/10/2013 02:31 PM, Jiri Kosina wrote:
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
handler (which would typically mean just skipping
On 07/11/2013 10:35 AM, Steven Rostedt wrote:
On Wed, 2013-07-10 at 14:36 -0700, H. Peter Anvin wrote:
On 07/10/2013 02:31 PM, Jiri Kosina wrote:
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
handler
On Wed, 2013-07-10 at 23:31 +0200, Jiri Kosina wrote:
Changes:
v1 - v2:
+ fixed kerneldoc
+ fixed checkpatch errors (reported by Borislav)
arch/x86/include/asm/alternative.h |1 +
arch/x86/kernel/alternative.c | 101
kernel/kprobes.c
On 07/11/2013 03:23 AM, Masami Hiramatsu wrote:
+ *
+ * The way it is done:
+ * - add a int3 trap to the address that will be patched
+ * - sync cores
You don't need this sync cores. (and your code didn't) :)
I believe you do, lest you get Frankenstructions. I believe you don't
need
On 07/11/2013 03:09 AM, Jiri Kosina wrote:
I'm wondering if it would be easier/more general to just return to the
instruction. The more general bit would allow this to be used for
other things, like alternatives,
As Boris already pointed out, this is not really that interesting, as it's
On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote:
The current code assumes that one of the two code sequences is a NOP,
and therefore that jumping over the region is legal. This does not
allow for transitioning one active code sequence to another.
Correct, and I think we should keep
On Thu, 11 Jul 2013, Steven Rostedt wrote:
The current code assumes that one of the two code sequences is a NOP,
and therefore that jumping over the region is legal. This does not
allow for transitioning one active code sequence to another.
Correct, and I think we should keep the two
On Thu, 11 Jul 2013, H. Peter Anvin wrote:
+ * The way it is done:
+ *- add a int3 trap to the address that will be patched
+ *- sync cores
You don't need this sync cores. (and your code didn't) :)
I believe you do, lest you get Frankenstructions. I believe you
On Thu, 11 Jul 2013, Steven Rostedt wrote:
[ .. snip .. ]
+ smp_wmb();
+
+ text_poke(addr, int3, sizeof(int3));
+
+ if (len - sizeof(int3) 0) {
I believe we need a sync here. Otherwise, if the instruction crosses
cache lines, the original first byte could have been pulled in,
On Thu, 2013-07-11 at 21:43 +0200, Jiri Kosina wrote:
OTOH we apparently don't need the one after the text_poke() below, as
syncing the cores just after patching the first byte afterwards provides
safe enough guard (at least according to hpa's words back in 2010 :) ).
Right, but I'm
On 07/11/2013 12:29 PM, Jiri Kosina wrote:
On Thu, 11 Jul 2013, H. Peter Anvin wrote:
+ * The way it is done:
+ *- add a int3 trap to the address that will be patched
+ *- sync cores
You don't need this sync cores. (and your code didn't) :)
I believe you do, lest you get
On 07/11/2013 12:29 PM, Jiri Kosina wrote:
On Thu, 11 Jul 2013, H. Peter Anvin wrote:
+ * The way it is done:
+ *- add a int3 trap to the address that will be patched
+ *- sync cores
You don't need this sync cores. (and your code didn't) :)
I believe you do, lest you get
(2013/07/11 19:51), Jiri Kosina wrote:
+ * - update all but the first byte of the patched range
+ * - sync cores
+ * - replalace the first byte (int3) by the first byte of
+ * replacing opcode
+ * - sync cores
+ *
+ * Note: must be called under text_mutex.
+ */
+void *text_poke_bp(void
(2013/07/12 1:46), Steven Rostedt wrote:
On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote:
The current code assumes that one of the two code sequences is a NOP,
and therefore that jumping over the region is legal. This does not
allow for transitioning one active code sequence to
(2013/07/11 6:36), H. Peter Anvin wrote:
> On 07/10/2013 02:31 PM, Jiri Kosina wrote:
>>
>> If any CPU instruction execution would collide with the patching,
>> it'd be trapped by the int3 breakpoint and redirected to the provided
>> "handler" (which would typically mean just skipping over the
On Wed, 10 Jul 2013, H. Peter Anvin wrote:
> > If any CPU instruction execution would collide with the patching,
> > it'd be trapped by the int3 breakpoint and redirected to the provided
> > "handler" (which would typically mean just skipping over the patched
> > region, acting as "nop" has been
On Wed, Jul 10, 2013 at 02:56:36PM -0700, H. Peter Anvin wrote:
> No, the idea is that the affected CPU will simply execute int3 -> iret
> ad nauseam until the first byte is repatched, at that point execution
> will resume normally.
Ok, that sounds simple enough. I just hope we don't unearth some
On 07/10/2013 02:48 PM, Borislav Petkov wrote:
> On Wed, Jul 10, 2013 at 02:36:41PM -0700, H. Peter Anvin wrote:
>> I'm wondering if it would be easier/more general to just return to the
>> instruction. The "more general" bit would allow this to be used for
>> other things, like alternatives, and
On Wed, Jul 10, 2013 at 02:36:41PM -0700, H. Peter Anvin wrote:
> I'm wondering if it would be easier/more general to just return to the
> instruction. The "more general" bit would allow this to be used for
> other things, like alternatives, and perhaps eventually dynamic call
> patching.
Well,
On Wed, 2013-07-10 at 23:31 +0200, Jiri Kosina wrote:
> Introduce a method for run-time instrucntion patching on a live SMP kernel
> based on int3 breakpoint, completely avoiding the need for stop_machine().
Yet more trivia:
instruction typo
> The way this is achieved:
>
> - add a
On 07/10/2013 02:31 PM, Jiri Kosina wrote:
>
> If any CPU instruction execution would collide with the patching,
> it'd be trapped by the int3 breakpoint and redirected to the provided
> "handler" (which would typically mean just skipping over the patched
> region, acting as "nop" has been there,
Introduce a method for run-time instrucntion patching on a live SMP kernel
based on int3 breakpoint, completely avoiding the need for stop_machine().
The way this is achieved:
- add a int3 trap to the address that will be patched
- sync cores
- update all but the first
Introduce a method for run-time instrucntion patching on a live SMP kernel
based on int3 breakpoint, completely avoiding the need for stop_machine().
The way this is achieved:
- add a int3 trap to the address that will be patched
- sync cores
- update all but the first
On 07/10/2013 02:31 PM, Jiri Kosina wrote:
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
handler (which would typically mean just skipping over the patched
region, acting as nop has been there, in case
On Wed, 2013-07-10 at 23:31 +0200, Jiri Kosina wrote:
Introduce a method for run-time instrucntion patching on a live SMP kernel
based on int3 breakpoint, completely avoiding the need for stop_machine().
Yet more trivia:
instruction typo
The way this is achieved:
- add a int3
On Wed, Jul 10, 2013 at 02:36:41PM -0700, H. Peter Anvin wrote:
I'm wondering if it would be easier/more general to just return to the
instruction. The more general bit would allow this to be used for
other things, like alternatives, and perhaps eventually dynamic call
patching.
Well, the
On 07/10/2013 02:48 PM, Borislav Petkov wrote:
On Wed, Jul 10, 2013 at 02:36:41PM -0700, H. Peter Anvin wrote:
I'm wondering if it would be easier/more general to just return to the
instruction. The more general bit would allow this to be used for
other things, like alternatives, and perhaps
On Wed, Jul 10, 2013 at 02:56:36PM -0700, H. Peter Anvin wrote:
No, the idea is that the affected CPU will simply execute int3 - iret
ad nauseam until the first byte is repatched, at that point execution
will resume normally.
Ok, that sounds simple enough. I just hope we don't unearth some
On Wed, 10 Jul 2013, H. Peter Anvin wrote:
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
handler (which would typically mean just skipping over the patched
region, acting as nop has been there, in
(2013/07/11 6:36), H. Peter Anvin wrote:
On 07/10/2013 02:31 PM, Jiri Kosina wrote:
If any CPU instruction execution would collide with the patching,
it'd be trapped by the int3 breakpoint and redirected to the provided
handler (which would typically mean just skipping over the patched
52 matches
Mail list logo
