[PATCH] WTF is VLI?

[PATCH] WTF is VLI?

[Hugh Dickins]

What is this "VLI" that 2.6.9 started putting after the taint string
in i386 oopses?  Vick Library Index?  Vineyard Leadership Institute?
Shall we just remove it?

Signed-off-by: Hugh Dickins <hugh@veritas.com>

--- 2.6.10-rc1-bk20/arch/i386/kernel/traps.c	2004-11-10 14:05:34.000000000 +0000
+++ linux/arch/i386/kernel/traps.c	2004-11-11 20:53:06.725490224 +0000
@@ -215,7 +215,7 @@ void show_registers(struct pt_regs *regs
 		ss = regs->xss & 0xffff;
 	}
 	print_modules();
-	printk("CPU:    %d\nEIP:    %04x:[<%08lx>]    %s VLI\nEFLAGS: %08lx"
+	printk("CPU:    %d\nEIP:    %04x:[<%08lx>]    %s\nEFLAGS: %08lx"
 			"   (%s) \n",
 		smp_processor_id(), 0xffff & regs->xcs, regs->eip,
 		print_tainted(), regs->eflags, system_utsname.release);

Re: [PATCH] WTF is VLI?

[Dave Jones]

On Thu, Nov 11, 2004 at 09:05:11PM +0000, Hugh Dickins wrote:
 > What is this "VLI" that 2.6.9 started putting after the taint string
 > in i386 oopses?  Vick Library Index?  Vineyard Leadership Institute?

"Variable length instructions".  I think newer ksymoops looks
for this tag and does something magical when doing disassembly.

		Dave

Re: [PATCH] WTF is VLI?

[Horst von Brand]

Dave Jones <davej@redhat.com> said:
> On Thu, Nov 11, 2004 at 09:05:11PM +0000, Hugh Dickins wrote:
>  > What is this "VLI" that 2.6.9 started putting after the taint string
>  > in i386 oopses?  Vick Library Index?  Vineyard Leadership Institute?
> 
> "Variable length instructions".  I think newer ksymoops looks
> for this tag and does something magical when doing disassembly.

Huh? Either an architecture has them (i386) or doesn't (RISCs). 
Or am I seriously misunderstanding here?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [PATCH] WTF is VLI?

[Hugh Dickins]

On Fri, 12 Nov 2004, Horst von Brand wrote:
> Dave Jones <davej@redhat.com> said:
> > On Thu, Nov 11, 2004 at 09:05:11PM +0000, Hugh Dickins wrote:
> >  > What is this "VLI" that 2.6.9 started putting after the taint string
> >  > in i386 oopses?  Vick Library Index?  Vineyard Leadership Institute?
> > 
> > "Variable length instructions".  I think newer ksymoops looks
> > for this tag and does something magical when doing disassembly.
> 
> Huh? Either an architecture has them (i386) or doesn't (RISCs). 
> Or am I seriously misunderstanding here?

I share your surprise, it does seem rather odd.  I think what it's
really trying to do is distinguish how 2.6.9 starts the "Code:" bytes
at eip - 43, where 2.6.8 started at eip; but flag that since it's VLI
then it's got a bit of guessing to do.  I'd have preferred to work it
out from i386 and the new "<%02x>" around the eip byte itself, rather
than stick a "VLI" somewhere else; but let's not interfere now it's so.

Hugh

Re: [PATCH] WTF is VLI?

[Keith Owens]

On Mon, 15 Nov 2004 21:18:43 +0000 (GMT), 
Hugh Dickins <hugh@veritas.com> wrote:
>On Fri, 12 Nov 2004, Horst von Brand wrote:
>> Dave Jones <davej@redhat.com> said:
>> > On Thu, Nov 11, 2004 at 09:05:11PM +0000, Hugh Dickins wrote:
>> >  > What is this "VLI" that 2.6.9 started putting after the taint string
>> >  > in i386 oopses?  Vick Library Index?  Vineyard Leadership Institute?
>> > 
>> > "Variable length instructions".  I think newer ksymoops looks
>> > for this tag and does something magical when doing disassembly.
>> 
>> Huh? Either an architecture has them (i386) or doesn't (RISCs). 
>> Or am I seriously misunderstanding here?
>
>I share your surprise, it does seem rather odd.  I think what it's
>really trying to do is distinguish how 2.6.9 starts the "Code:" bytes
>at eip - 43, where 2.6.8 started at eip; but flag that since it's VLI
>then it's got a bit of guessing to do.  I'd have preferred to work it
>out from i386 and the new "<%02x>" around the eip byte itself, rather
>than stick a "VLI" somewhere else; but let's not interfere now it's so.

ksymoops has to work with lots of different log formats from lots of
different architectures.  Some arch's already print the code around the
oops and enclose the failing instruction in <> or [], some do not.

Just looking at a code string, you cannot tell if the arch has variable
length instructions or not (don't forget that ksymoops also works cross
architecture).  The VLI tag will work for _all_ architectures that have
variable length instructions, not just i386.  At the very least, s390
can use it as well.

There are enough ambiguity problems in ksymoops, without adding new
ones.

Re: [PATCH] WTF is VLI?

[Hugh Dickins]

On Tue, 16 Nov 2004, Keith Owens wrote:
> 
> ksymoops has to work with lots of different log formats from lots of
> different architectures.  Some arch's already print the code around the
> oops and enclose the failing instruction in <> or [], some do not.
> 
> Just looking at a code string, you cannot tell if the arch has variable
> length instructions or not (don't forget that ksymoops also works cross
> architecture).  The VLI tag will work for _all_ architectures that have
> variable length instructions, not just i386.  At the very least, s390
> can use it as well.

But, to an outsider, it seems that the "VLI" can only be relevant when
disassembling the "Code:", and surely each arch disassembler knows
already if it's dealing with Variable Length Instructions.

No big deal, just odd.  I've no wish to add to ksymoops's difficulties.

Hugh

Re: [PATCH] WTF is VLI?

[Keith Owens]

On Tue, 16 Nov 2004 09:56:34 +0000 (GMT), 
Hugh Dickins <hugh@veritas.com> wrote:
>On Tue, 16 Nov 2004, Keith Owens wrote:
>> 
>> ksymoops has to work with lots of different log formats from lots of
>> different architectures.  Some arch's already print the code around the
>> oops and enclose the failing instruction in <> or [], some do not.
>> 
>> Just looking at a code string, you cannot tell if the arch has variable
>> length instructions or not (don't forget that ksymoops also works cross
>> architecture).  The VLI tag will work for _all_ architectures that have
>> variable length instructions, not just i386.  At the very least, s390
>> can use it as well.
>
>But, to an outsider, it seems that the "VLI" can only be relevant when
>disassembling the "Code:", and surely each arch disassembler knows
>already if it's dealing with Variable Length Instructions.

ksymoops takes the Code: line, converts it to a suitable object file,
passes that object to the arch specific disassembler then ksymoops
reformats the output to match the kernel symbol table.  With fixed
length instructions, ksymoops can dump the entire code line into a
single object.  With variable length instructions, disassembling the
code before the instruction pointer is dodgy, it may or may not work.

So for VLI code, ksymoops splits the code line into two separate pieces
and processes each one seperately.  ksymoops prints the first bit with
a warning that it may not be reliable.  The second bit, and all the
code line for non-VLI architectures, is reliable and is printed without
a warning.

The VLI tag, together with <> or [] around the failing instruction,
tells ksymoops if this oops needs to be processed in one chunk or two.
_Before_ passing the synthesized object(s) to the disassembler.

Re: [PATCH] WTF is VLI?

[Avi Kivity]

Keith Owens wrote:

>So for VLI code, ksymoops splits the code line into two separate pieces
>and processes each one seperately.  ksymoops prints the first bit with
>a warning that it may not be reliable.  The second bit, and all the
>code line for non-VLI architectures, is reliable and is printed without
>a warning.
>
>  
>
ksymoops can disasemble the entire code line, but starting at different 
offsets (up to the maximum instruction length) from the start. the first 
disassembly to include the program counter in the output would be deemed 
correct.

this would work for all architectures, and might improve reliability for 
i386.

in case I'm not communicating well:

for (offset = 0; offset < max_instr_len; ++offset) {
    create_object_file(code + offset, len - offset);
    disassemble();
    if (disassembly_includes_eip())
        break;
}

the likelyhood of the first section containing garbage is reduced; and 
the code works for VLI and FLI.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [PATCH] WTF is VLI?

[Horst von Brand]

Avi Kivity <avi@argo.co.il> said:

[...]

> ksymoops can disasemble the entire code line, but starting at different 
> offsets (up to the maximum instruction length) from the start. the first 
> disassembly to include the program counter in the output would be deemed 
> correct.

There might be several... I see no reason to consider the first one
correct.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [PATCH] WTF is VLI?

[Avi Kivity]

Horst von Brand wrote:

>>ksymoops can disasemble the entire code line, but starting at different 
>>offsets (up to the maximum instruction length) from the start. the first 
>>disassembly to include the program counter in the output would be deemed 
>>correct.
>>    
>>
>
>There might be several... I see no reason to consider the first one
>correct.
>  
>
Of course, there is no way to guarantee correctness. the point is with 
the current system the chances of being correct are around 1:(average 
instruction length) (a bit better because there is a chance to resync), 
while with my proposal to be _incorrect_ you need to start wrong _and_ 
hit a bad resync.

I don't get to see many oopsen, but it seems to me most would have 
garbage before eip, no?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [PATCH] WTF is VLI?

[Keith Owens]

On Thu, 18 Nov 2004 17:47:14 +0200, 
Avi Kivity <avi@argo.co.il> wrote:
>Keith Owens wrote:
>
>>So for VLI code, ksymoops splits the code line into two separate pieces
>>and processes each one seperately.  ksymoops prints the first bit with
>>a warning that it may not be reliable.  The second bit, and all the
>>code line for non-VLI architectures, is reliable and is printed without
>>a warning.
>
>ksymoops can disasemble the entire code line, but starting at different 
>offsets (up to the maximum instruction length) from the start. the first 
>disassembly to include the program counter in the output would be deemed 
>correct.

I originally tried that and rejected it, there are far too many false
positives on i386.  It does not matter where you start the disassembly,
it converges to the correct instructions fairly quickly.

Run this test case through ksymoops 2.4.9 or later.  It is the same
Code: line repeated 6 times, stripping one byte off the front of the
code for each repeat.  That has the same effect as your suggestion of
starting at different offsets, without having to write any C code.

EIP:    0010:[<c0113f8c>] VLI
Code: 8b 15 2c e4 09 08 89 e5 83 ec 08 85 d2 75 49 8b 15 28 e4 09 08 8b 02 85 c0 74 1a 8d 74 26 00 <8d> 42 04
EIP:    0010:[<c0113f8c>] VLI
Code: 15 2c e4 09 08 89 e5 83 ec 08 85 d2 75 49 8b 15 28 e4 09 08 8b 02 85 c0 74 1a 8d 74 26 00 <8d> 42 04
EIP:    0010:[<c0113f8c>] VLI
Code: 2c e4 09 08 89 e5 83 ec 08 85 d2 75 49 8b 15 28 e4 09 08 8b 02 85 c0 74 1a 8d 74 26 00 <8d> 42 04
EIP:    0010:[<c0113f8c>] VLI
Code: e4 09 08 89 e5 83 ec 08 85 d2 75 49 8b 15 28 e4 09 08 8b 02 85 c0 74 1a 8d 74 26 00 <8d> 42 04
EIP:    0010:[<c0113f8c>] VLI
Code: 09 08 89 e5 83 ec 08 85 d2 75 49 8b 15 28 e4 09 08 8b 02 85 c0 74 1a 8d 74 26 00 <8d> 42 04
EIP:    0010:[<c0113f8c>] VLI
Code: 08 89 e5 83 ec 08 85 d2 75 49 8b 15 28 e4 09 08 8b 02 85 c0 74 1a 8d 74 26 00 <8d> 42 04

For all six inputs, the disassembler converges to the correct sequence.
The "unreliable" sequences always end with the correct set of
instructions, test, jne, mov, mov, test, je, lea.

There is no way to tell which interpretation is correct, but it does
not matter.  The instructions just before EIP are valid, which is all
that we care about.

Re: [PATCH] WTF is VLI?

[Andrew Morton]

Hugh Dickins <hugh@veritas.com> wrote:
>
> What is this "VLI" that 2.6.9 started putting after the taint string
> in i386 oopses?  Vick Library Index?  Vineyard Leadership Institute?
> Shall we just remove it?
> 

It's a magic kaos cookie:

  ksymoops handles up to 64 code bytes so dump eip-43:eip+20 with the eip
  byte enclosed in <>.  Add the string 'VLI ' (variable length
  instructions) just before the taint output, ksymoops 2.4.8 will look
  for 'VLI ' on the 'EIP:' line and split the code line into two chunks.

and

  The VLI indicator tells ksymoops the dump has variable length
  instructions so ksymoops splits the code into two lines at the eip byte. 
  Without the VLI indicator or using ksymoops < 2.4.9, ksymoops decodes the
  whole line in one go.  


I think the rationale is mainly so that new ksymoopses won't make a mess of
old oops records.

Re: [PATCH] WTF is VLI?

[Bodo Eggert]

Avi Kivity wrote:

> for (offset = 0; offset < max_instr_len; ++offset) {
>     create_object_file(code + offset, len - offset);
>     disassemble();
>     if (disassembly_includes_eip())


Will fail for

movl eax,cc000000 ;or something similar, you get the point
*EIP here*

and result in

INT3
-- 
Keep your hands off strong drink. It can make you shoot at the tax collector
and miss.
        -- R.A. Heinlein
Friß, Spammer: snapdragon4709@qytayz.com fBzlGY9EVuwDME1@disrxcount.com

Re: [PATCH] WTF is VLI?

[Avi Kivity]

Bodo Eggert wrote:

>Avi Kivity wrote:
>
>  
>
>>for (offset = 0; offset < max_instr_len; ++offset) {
>>    create_object_file(code + offset, len - offset);
>>    disassemble();
>>    if (disassembly_includes_eip())
>>    
>>
>
>
>Will fail for
>
>movl eax,cc000000 ;or something similar, you get the point
>*EIP here*
>
>and result in
>
>INT3
>  
>
no, it will start at lower offsets first and see the movl.

of course, there is a chance that it will get confused (by even earlier 
partial code), but it will usually be better than the current method and 
it will never be confused at or above eip (same as current method).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.