search for: replacementlen

...-git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index 3344d3382e91..81c577c7deba 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -410,20 +410,28 @@ void __init_or_module noinline apply_alternatives(struct alt_instr *start, insnbuf_sz = a->replacementlen; /* - * 0xe8 is a relative jump; fix the offset. - * - * Instruction length is checked before the opcode to avoid - * accessing uninitialized bytes for zero-length replacements. + * Fix the address offsets for call and jump instructions which + * use PC-relative addressing. */...

...rnel/alternative.c > > index 3344d3382e91..81c577c7deba 100644 > > --- a/arch/x86/kernel/alternative.c > > +++ b/arch/x86/kernel/alternative.c > > @@ -410,20 +410,28 @@ void __init_or_module noinline apply_alternatives(struct alt_instr *start, > > insnbuf_sz = a->replacementlen; > > > > /* > > - * 0xe8 is a relative jump; fix the offset. > > - * > > - * Instruction length is checked before the opcode to avoid > > - * accessing uninitialized bytes for zero-length replacements. > > + * Fix the address offsets for call...

...rnel/alternative.c > > index 3344d3382e91..81c577c7deba 100644 > > --- a/arch/x86/kernel/alternative.c > > +++ b/arch/x86/kernel/alternative.c > > @@ -410,20 +410,28 @@ void __init_or_module noinline apply_alternatives(struct alt_instr *start, > > insnbuf_sz = a->replacementlen; > > > > /* > > - * 0xe8 is a relative jump; fix the offset. > > - * > > - * Instruction length is checked before the opcode to avoid > > - * accessing uninitialized bytes for zero-length replacements. > > + * Fix the address offsets for call...

...ternative.c b/arch/x86/kernel/alternative.c > index 3344d3382e91..81c577c7deba 100644 > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -410,20 +410,28 @@ void __init_or_module noinline apply_alternatives(struct alt_instr *start, > insnbuf_sz = a->replacementlen; > > /* > - * 0xe8 is a relative jump; fix the offset. > - * > - * Instruction length is checked before the opcode to avoid > - * accessing uninitialized bytes for zero-length replacements. > + * Fix the address offsets for call and jump instructions which > +...

...t;> We'd also have to assume that the restore part of an alternative entry > >> is the same size as the save part. Which is true now. > > Why? > > > > Don't you need to know the size of the instruction without save and > restore part? > > + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) > > Otherwise you'd need another field for the actual instruction length. If we know where the CALL instruction starts, and can verify that it starts with "ff 15", then we know the instruction length: 6 bytes. R...

...t;> We'd also have to assume that the restore part of an alternative entry > >> is the same size as the save part. Which is true now. > > Why? > > > > Don't you need to know the size of the instruction without save and > restore part? > > + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) > > Otherwise you'd need another field for the actual instruction length. If we know where the CALL instruction starts, and can verify that it starts with "ff 15", then we know the instruction length: 6 bytes. R...

...so have to assume that the restore part of an alternative entry >>>> is the same size as the save part. Which is true now. >>> Why? >>> >> Don't you need to know the size of the instruction without save and >> restore part? >> >> + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) >> >> Otherwise you'd need another field for the actual instruction length. > If we know where the CALL instruction starts, and can verify that it > starts with "ff 15", then we know the instruction le...

On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > > > Maybe we can add a new field to the alternatives entry struct which > > specifies the offset to the CALL instruction, so apply_alternatives() > > can find it. > > We'd also have to assume that the restore part of an alternative entry > is

On Tue, Oct 17, 2017 at 11:36:57AM -0400, Boris Ostrovsky wrote: > On 10/17/2017 10:36 AM, Josh Poimboeuf wrote: > > > > Maybe we can add a new field to the alternatives entry struct which > > specifies the offset to the CALL instruction, so apply_alternatives() > > can find it. > > We'd also have to assume that the restore part of an alternative entry > is

...es() is supposed to adjust that displacement based on > the new IP, though it could be messing that up somehow. (See patch > 10/13.) > That patch doesn't take into account the fact that replacement instructions may have to save/restore registers. So, for example, - if (a->replacementlen && is_jmp(replacement[0])) + } else if (a->replacementlen == 6 && *insnbuf == 0xff && + *(insnbuf+1) == 0x15) { + /* indirect call */ + *(s32 *)(insnbuf + 2) += replacement - instr; + DPRINTK("Fix indirect CALL of...

...based on > > the new IP, though it could be messing that up somehow. (See patch > > 10/13.) > > > > That patch doesn't take into account the fact that replacement > instructions may have to save/restore registers. So, for example, > > > - if (a->replacementlen && is_jmp(replacement[0])) > + } else if (a->replacementlen == 6 && *insnbuf == 0xff && > + *(insnbuf+1) == 0x15) { > + /* indirect call */ > + *(s32 *)(insnbuf + 2) += replacement - instr; > + DPRINTK(&...

...based on > > the new IP, though it could be messing that up somehow. (See patch > > 10/13.) > > > > That patch doesn't take into account the fact that replacement > instructions may have to save/restore registers. So, for example, > > > - if (a->replacementlen && is_jmp(replacement[0])) > + } else if (a->replacementlen == 6 && *insnbuf == 0xff && > + *(insnbuf+1) == 0x15) { > + /* indirect call */ > + *(s32 *)(insnbuf + 2) += replacement - instr; > + DPRINTK(&...

...61b\n" /* label */ \ + " .long 663f\n" /* new instruction */ \ + " .byte %c0\n" /* feature bit */ \ + " .byte 662b-661b\n" /* sourcelen */ \ + " .byte 664f-663f\n" /* replacementlen */ \ + ".previous\n" \ + ".section .altinstr_replacement,\"ax\"\n" \ + "663:\n\t" newinstr "\n664:\n" /* replacement */ \ + ".previous" :: "i" (feature) : "memory") + +/* + * Al...

...61b\n" /* label */ \ + " .long 663f\n" /* new instruction */ \ + " .byte %c0\n" /* feature bit */ \ + " .byte 662b-661b\n" /* sourcelen */ \ + " .byte 664f-663f\n" /* replacementlen */ \ + ".previous\n" \ + ".section .altinstr_replacement,\"ax\"\n" \ + "663:\n\t" newinstr "\n664:\n" /* replacement */ \ + ".previous" :: "i" (feature) : "memory") + +/* + * Al...

Hi, all, I have difficulty on setting up lguest. Basic OS info: gcc 4.1.2 glibc: 2.5.1 binutils: 2.17 kernel: 2.6.23-rc1 Following lguest.txt instruction, I build lguest enaled kernel, disable CONFIG_COMPAT_VDSO, the host kernel boot fine, but when booting Qemu image using lguest laucher program, the guest kernel vmlinux panic, attached console.txt is console output, and config.txt is kernel

Hi, all, I have difficulty on setting up lguest. Basic OS info: gcc 4.1.2 glibc: 2.5.1 binutils: 2.17 kernel: 2.6.23-rc1 Following lguest.txt instruction, I build lguest enaled kernel, disable CONFIG_COMPAT_VDSO, the host kernel boot fine, but when booting Qemu image using lguest laucher program, the guest kernel vmlinux panic, attached console.txt is console output, and config.txt is kernel

On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote: > On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > > On 10/12/2017 03:27 PM, Andrew Cooper wrote: > >> On 12/10/17 20:11, Boris Ostrovsky wrote: > >>> There is also another problem: > >>> > >>> [ 1.312425] general protection fault: 0000 [#1] SMP > >>> [ 1.312901]

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

...ernatives() >>> can find it. >> We'd also have to assume that the restore part of an alternative entry >> is the same size as the save part. Which is true now. > Why? > Don't you need to know the size of the instruction without save and restore part? + if (a->replacementlen == 6 && *insnbuf == 0xff && *(insnbuf+1) == 0x15) Otherwise you'd need another field for the actual instruction length. -boris