Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jun 2011 12:01:33 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Guido Falsi <mad@madpilot.net>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: BTX loader problem on specific hardware
Message-ID:  <201106171201.34037.jhb@freebsd.org>
In-Reply-To: <20110617153028.GB37006@megatron.madpilot.net>
References:  <20110609152820.GC57263@megatron.madpilot.net> <201106131145.08185.jhb@freebsd.org> <20110617153028.GB37006@megatron.madpilot.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, June 17, 2011 11:30:28 am Guido Falsi wrote:
> On Mon, Jun 13, 2011 at 11:45:07AM -0400, John Baldwin wrote:
> > 
> > Ouch.  Well, these can be a PITA to disassemble.  ndisasm from the 
devel/nasm
> > port is a good x86 disassembler that you can use.  You will need to use dd
> > on /dev/mem to extract INT 15's entry point from the IDT.  For example:
> > 
> > # dd if=/dev/mem bs=4 iseek=0x15 count=1 | hd
> > 1+0 records in
> > 1+0 records out
> > 4 bytes transferred in 0.000021 secs (190650 bytes/sec)
> > 00000000  59 f8 00 f0                                       |Y...|
> > 00000004
> > 
> > On this machine that gives a pointer of 0xf000:f859 which is a raw 
physical
> > address of '0xff859'.  You can then grab a block of that to disassemble 
like
> > so:
> > 
> > # dd if=/dev/mem bs=1 iseek=0xff859 count=100 | ndisasm -
> > 00000000  EB00              jmp short 0x2
> > 00000002  80FC87            cmp ah,0x87
> > 00000005  7503              jnz 0xa
> > 00000007  E94CF9            jmp word 0xf956
> > ....
> > 
> > In this case I'd then need to look at what was at 0xff956, etc.
> 
> Following your suggestions I finally got through that code. I could
> understand just part of it. As I said I have almost no experience
> with ASM.
> 
> I also disassebled the same function from another PC (same manufacturer)
> on which BTX/loader works.
> 
> Only thing I could make out is that the 6005Pro BIOS has a part of it's
> code where it touches the cr[034] and msr registers. This code if
> surrounded by a check on a memory location which, when I dump it, makes
> the code run. I don't know if at machine boot this byte has a different
> value. There is an instruction near there which makes the code what I
> see it, but it's not in the code path from the bios function in
> question.
> 
> I see that older BTX used to emulate all the operations on CR and MSR
> registers, so maybe that's why it went through. Any idea or help on a
> possible workaround?
> 
> I'm not sure, but maybe rdmsr or wrmsr are generating exceptions which
> are not managed by BTX? I could be wrong, I really dont' know that much
> about the internals of CPUs.

Well, the old BTX didn't allow full access to CR registers.  Running in
real mode, there should be no problems with any MSR accesses though in
the new BTX.

> I obviously have the disassembled code available, but not posting it
> here because I'm not sure what policies there are about disassembled
> code on the lists.

You can post a URL perhaps (or just send it to me directly if you wish).

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106171201.34037.jhb>