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 <[email protected]>
--- 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);
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
Hugh Dickins <[email protected]> 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.
Dave Jones <[email protected]> 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
On Fri, 12 Nov 2004, Horst von Brand wrote:
> Dave Jones <[email protected]> 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
On Mon, 15 Nov 2004 21:18:43 +0000 (GMT),
Hugh Dickins <[email protected]> wrote:
>On Fri, 12 Nov 2004, Horst von Brand wrote:
>> Dave Jones <[email protected]> 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.
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
On Tue, 16 Nov 2004 09:56:34 +0000 (GMT),
Hugh Dickins <[email protected]> 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.
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.
Avi Kivity <[email protected]> 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
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: [email protected] [email protected]
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.
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.
On Thu, 18 Nov 2004 17:47:14 +0200,
Avi Kivity <[email protected]> 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.