Is it possible to run Bios Setup without restarting the PC by using virtualization method or using v8086 mode?

[Hoang Nguyen]

I have a crazy requirement...that I need to go to Bios Setup from pre-boot environment or OS environment without restart the PC. (the normal practice is to restart the PC then press the hotkey to force system go to Bios setup)

Initially, I am thinking to switch the CPU to v8086 mode and map the physical memory from 0x0000 - 0x10000 to some high memory address. Then make a call to reset address ( 0xFFFFFFF0 ) ...there will be some work to handle when the code tries to access the physical port (for example CMOS port, hdd port...)

I would like to check from your expert opinion...Is it possible to do that?

Thanks & Best regards
Jerry

[Rod Pemberton]

On Sun, 4 Dec 2016 23:36:14 -0800 (PST)
Hoang Nguyen <jerry.n...@gmail.com> wrote:

> I have a crazy requirement...that I need to go to Bios Setup from
> pre-boot environment or OS environment without restart the PC. (the
> normal practice is to restart the PC then press the hotkey to force
> system go to Bios setup)
>
> Initially, I am thinking to switch the CPU to v8086 mode and map the
> physical memory from 0x0000 - 0x10000 to some high memory address.
> Then make a call to reset address ( 0xFFFFFFF0 ) ...there will be
> some work to handle when the code tries to access the physical port
> (for example CMOS port, hdd port...)

You'd need to also look at setting values for CMOS 0Fh and 40:72h and
40:67h.

40:72h is the reset flag:
(this has other valid values)
0000h - cold boot
1234h - warm boot
4321h - preserve memory

CMOS 0Fh is the shutdown code:
(this has other valid values)
0 - full reset, POST tests executed
4 - reboot with NMI on, skips POST, int 19h
5 - skip POST, preserve memory, clear keyboard EOIs, clear interrupts,
jump to 40:67h
6 - no EOIs issued, jump to 40:67h
Ah - clear interrupts, no EOIs issued, jump 40:67h
Bh - iret to 40:67h
Ch - retf to 40:67h

Some sources say Ch uses iret instead of Bh.

40:67h is an address pointer to 16-bit resume code after a reboot with
40:72 set to 4321h (preserve memory). I.e., if 40:72h is set to 4321h,
and CMOS 0Fh is set to values (5,6,Ah,Bh,Ch) which jump to the address
at 40:67h, code execution will resume at the address stored at 40:67h.
Jumping to an address at 40:67h is known as a 286 reset. The 80286 uses
this method to switch from protected mode to real mode, since it had no
method to exit protected mode.

Of course, I've not tested this and the information sources I have are
not very reliable. So, you may have to do some experimentation. E.g.,
it might be Ch that uses iret or you might need 1234h instead of 4321h,
etc.

Since this 40:67h functionality was intended for a 80286, it's possible
that this functionality is not available, or has been reduced or
eliminated for some BIOSes. One specification does eliminate it. This
is for Intel EFI CSM (extensible firmware interfaces, compatibility
support module). The specification eliminates usage of 40:67h and CMOS
0Fh. So, if your machine has a EFI/UEFI instead of BIOS, it may not be
able to use this technique to regain control of execution.

However, the 40:67h method is designed to skip the BIOS setup and POST
and return to an executing program in real-mode from protected-mode.
If you don't use 40:67h, you'll need some other way to regain
control of processor execution. Since you want to access the BIOS
setup, you'll have to do a cold boot, which doesn't use 40:67h. The
BIOS setup is not available from a warm boot or a 286 reset. You could
try setting Int 18h and/or Int 19h vectors. However, those vectors are
likely to be reset for a cold boot.

The BIOS hooks most of the vectors from 00h to 1Fh, 70h to 7Fh, and
many in the region of 40h to 6Fh. These are most likely reset during a
cold boot. The BIOS doesn't hook 0h, 1h, 3h, 4h, and 7h. These are
for processor exceptions. So, if you set some of those vectors and are
able to find a way generate such a exception, you may be able to regain
control of execution. I'm not sure how you'd do that without already
having control of execution.

You might be able to enable the TF (trap flag) for single step
execution, set vector 01h, set 40:72h to cold boot for the BIOS setup,
call FFFF:FFF0h, if the BIOS code is v86 clean, and the BIOS doesn't
use PM or SMM, and ports are open in TSS, you might be able to use the
01h interrupt to watch for an Int 18h or Int 19h instruction. Once you
trap the Int 18h or Int 19h instruction, 01h interrupt code can
transfer execution to your code, before the BIOS attempts to boot a
device. Be warned that once the TF is set, every instruction is going
to call the 01h interrupt, i.e., slow. Effectively implementing a
working 01h interrupt routine is difficult as a number of instructions
must be emulated, e.g., INT n, PUSHF, POPF, IRET, INTO, INT3. If
certain PM instructions are seen, e.g., LIDT, SIDT, LGDT, SGDT, SMSW,
LMSW, INVPLG, etc., you must disable the TF. This causes you to lose
control of execution. E.g., for the LIDT instruction, the IVT/IDT is
invalid. So, you can't generate any more interrupts, including for the
01h TF interrupt, as you'll cause a general protection fault, leading to
a triple fault and a processor reset. So, this would only work if your
machine's BIOS is v86 clean, and doesn't use any PM code.

> I would like to check from your expert opinion...Is it possible to do
> that?

Possible, yes. Probable, no.

After protected mode (PM) was introduced with the 80286, most machines
use began using PM during the BIOS hardware setup. This gives the
BIOS full access to memory to program memory-mapped hardware. Some
BIOS are reported to use system management mode (SMM) also.

Some machines have BIOSes which are much larger than the original
BIOS memory regions. So, it's likely they are using PM or SMM to
temporarily unmap memory and map in the extended BIOS regions.

To call the BIOS from v86 mode, the BIOS would likely need to:

1) not use PM
2) not use SMM
3) have x86 code which executes cleanly in v86 mode
4) not be EFI/UEFI

It's not known whether or not the BIOS code is entirely clean for v86
mode. BIOSes may only be v86 clean for code that is expected to be
called from v86 mode. Since the only reasons to call the BIOS reset
are cold-boot, warm-boot, and to exit PM, it's possible the BIOS
reset code isn't clean for v86 mode. It most likely uses PM too. It's
expected that the processor isn't in PM.

I would think you could do this on really old machines, which likely
only have 8086 code in their BIOS, but would be skeptical about using
this on modern machines due to use of PM. Although, maybe a warm boot
or boot which skips POST, instead of a cold boot, would cleanly pass in
v86 mode. The cold boot and/or POST initializes hardware.

So, I think your main problems are:

1) cleanly executing the BIOS cold boot code in v86 mode
2) regaining control of execution near first Int 18h or Int 19h

Please note that this is all somewhat speculative based on what I think
I know.

Good luck,


Rod Pemberton

[Alexei A. Frounze]

It's tough and it may not work everywhere.

The key is expected only in a certain window of time.
So, even if you had a small hardware device between
the keyboard and the PC you'd somehow need to know
when to simulate the key press/release. Too early or
too late won't work. I'm unsure how you can figure
out the timing. Perhaps, by trial and error / tuning
(just keep trying until you get there or do it
manually once on every PC?).

Then again, even the key differs between different
BIOSes (just sending all of those DEL, F10, F2,
whatever may invoke something else).

You may need to perform a reboot (cold) in order to
actually reach that code path, where the key is
expected. That in itself is problematic if you want
to keep some stuff around and survive the reboot.

On one hand you don't know what the BIOS is going to
do since it's hardware-specific and undocumented and
so you should let it access hardware transparently
while in virtual 8086 mode. OTOH, it's unclear how
you can prevent it from overwriting the regions
where your stuff is. What if it's gonna test the
memory and not by simply performing memory reads and
writes, which you can intercept, but by playing with
various low level things via I/O ports or whatever?

The most trivial solution might be some sort of KVM
switch and/or hardware that supports remote access
to the BIOS and other things. Server hardware has
this.

Alex

[JJ]

What about the BIOS ROM memory mapping? Cause some motherboards have 1 to 2
MBit (128KB to 256KB) BIOS flash ROM chip, but only 64KB is mapped to
F0000-FFFFF during disk MBR / boot-record code. Shouldn't it be restored
too? e.g. to E0000-FFFF (for 128KB ROM) or D0000-FFFF (for 256KB ROM).

[Rick C. Hodgin]

Hi Jerry. This is a very interesting question. I think it might
come back to what your true needs are. Do you need a completely
native machine? Or are you looking to serve the needs of a particular
app?

It might be worth taking the BIOS from a tool like Bochs and using that
version of BIOS re-written/modified for your needs. It might be worth
running in a true soft VM like Bochs, where you can spawn off as many
as you need. They run slower, but if the app you're running in there
is trivial, it may not need high speed. In addition, they can be spun
up, paused, saved to disk to be resumed right where they were, etc.

You might want to take a step back and see what your goals are. And if
you already have them solidly, it may be worth investigating the
possibility of getting little devices like the Intel Compute Stick and
seeing if you can use something like that to spawn off little hard
machines which are, for all intents and purposes, under the control of
the host.

A very interesting question.

Best regards,
Rick C. Hodgin

[Hoang Nguyen]

This is a great input :) Basically, we are developing a technic like a software based KVM...we are able to remote access all the preboot environment, except the Bios Setup...we just need to make some changes such as boot order, tpm setting, some hardware timming...i think we can develop a simple virtualization software it will trick the Bios and ask them to save the new setting to CMOS. Then next reboot the PC will run with new setting.

Thanks
Jerry

[Hoang Nguyen]

Thank Rick, I need a native machine...

[Hoang Nguyen]

Thank Rod, your information is very useful

[Hoang Nguyen]

[Rick C. Hodgin]

Have you considered flashing the BIOS with a custom-built BIOS that
allows you to maintain the needs of the remote software? You could
also disassemble the actual BIOS on the machine, intercept the first
instruction to JMP to your virtual KVM enable code, and then return
to the point where it would've started up in normal BIOS.

I created an x86 debugger which allowed me to have a debugger to
debug my boot sector code. I had the boot sector setup to load
constant blocks from the boot disk into known areas, setup the
interrupt, and then I could literally single-step through the rest
of my boot code. It was very nice.

You could install something similar as that first-step done in your
BIOS to enable you to single-step through to figure out where it is
failing after you get it setup at first. You could then code patches
for work-arounds for any custom BIOS issues.

[wolfgang kern]

Jerry Hoang Nguyen asked:

I'd say no.
* the Reset Pointer cant be "called", it will never return.
* BIOS setup may not keep anything you altered alive.

You could do (like M$ windoze installer) a warm reboot.

I'm not sure to understand what you want to alter after your code
gained control. My OS ignore and override BIOS hardware enumerating.

Or do you mean to tell the BIOS that it shall boot another drive on
next power up ?
seems hard to achieve, I would use my own boot-manager for this.
__
wolfgang

[Hoang Nguyen]

Hi Rick,

Thanks for your advice...I mostly debug the code using Bochs or Qemu...But in this case it seems i need to debug on the real hardware...Could you share more on how to setup X86 debugger to debug your boot code?

Thanks
Jerry

[Hoang Nguyen]

There are more option we can change in Bios Setup...such as SDRAM timming, power mode...all will be saved to CMOS. If we trick the software to think it run as boot and redirect the access to CMOS to real hardware. I think it may work.

[Rick C. Hodgin]

I used this program:

https://github.com/RickCHodgin/libsf/tree/master/exodus/source/xdebug
https://github.com/RickCHodgin/libsf/blob/master/exodus/source/xdebug/xdebug.asm

And this boot loader:

https://github.com/RickCHodgin/libsf/blob/master/exodus/source/boot/boot.asm

I modified my "put boot" utility to write the xdebug.com file to fixed
locations on the disk (known head, track, sector) and then modified
the start of my boot loader to load that data into memory sequentially
for the <64KB it required. I redirected the INT3 vector to point to
that location and then added an INT 3 assembly instruction after that
was done, and from that point forward I had a debugger I could single-
step through with function keys. It showed me the registers, and it
did a few more things.

IIRC, the disassembly wasn't always 100% accurate as I originally had
it decoding protected mode 80386 code, so it may show "mov eax,edx"
when it's really "mov ax,dx", etc. But, you can see that from your
own code.

By tracing into function calls and interrupts, rather than stepping
over them, you can step forward.

With some modifications, it could introduce breakpoints, write data
back out to disk, etc., all using BIOS.

I did all this back in the 1990s. I haven't used it much since
about 2002, and as I say it was never perfect. But, it did give
me a debugger environment I could use when debugging my boot.asm
code, and from that point forward in the kernel startup before
it entered pmode and my regular kernel debugger was available:

https://github.com/RickCHodgin/libsf/tree/master/exodus/source/debi

Note: The lasm and lasp files you see there will soon be renamed to
lsa and lsi, and they are a migrated form of assembly language
I'm currently developing here (it's not done yet, I'm working
on developing a generic token parsing engine I can use for a
wider-use compiler framework I'm developing, called RDC for
Rapid Development Compiler):

https://github.com/RickCHodgin/libsf/tree/master/exodus/tools/lsa

Best regards,
Rick C Hodgin

[Hoang Nguyen]

Hi Rick,

Thanks a lot

Have a nice day
Jerry

[Rick C. Hodgin]

You're welcome, Jerry. I used MASM 6.11d in MS-DOS 6.22 back then, so
if you go to assemble it today you might need to use some command line
options or the older tool in a DOS environment.

[Rod Pemberton]

On Wed, 7 Dec 2016 06:57:17 -0800 (PST)
Hoang Nguyen <jerry.n...@gmail.com> wrote:

> On Tuesday, December 6, 2016 at 4:00:32 PM UTC+7, wolfgang kern wrote:
> > Jerry Hoang Nguyen asked:
> >
> > |I have a crazy requirement...that I need to go to Bios Setup from
> > |pre-boot environment or OS environment without restart the PC.
> > |(the normal practice is to restart the PC then press the hotkey to
> > |force system go to Bios setup)
> >
> > |Initially, I am thinking to switch the CPU to v8086 mode and map
> > |the physical memory from 0x0000 - 0x10000 to some high memory
> > | address. Then make a call to reset address ( 0xFFFFFFF0 ) ...
> > | there will be some |work to handle when the code tries to
> > | access the physical port (for |example CMOS port, hdd port...)
> >
> > |I would like to check from your expert opinion...Is it possible to
> > | do that?
> >
> > I'd say no.
> > * the Reset Pointer cant be "called", it will never return.
> > * BIOS setup may not keep anything you altered alive.

> > [...]

> > I'm not sure to understand what you want to alter after your code
> > gained control.

> > [...]

> > I would use my own boot-manager for this.
>

> There are more option we can change in Bios Setup...such as SDRAM
> timming, power mode...all will be saved to CMOS. If we trick the
> software to think it run as boot and redirect the access to CMOS to
> real hardware. I think it may work.

Are these all the computers for which you want to do this identical
machines? If so, you could save the CMOS settings for one machine and
load to all the others.


Rod Pemberton

[Hoang Nguyen]

Hi Rod,

Is the operation save and restore CMOS (NVRAM) is standardized with all computer? I am looking for a solution it can work with all computer and Server

Best regards
Jerry

[wolfgang kern]

Jerry asked:

[about CMOS]

> Is the operation save and restore CMOS (NVRAM) is standardized with
> all computer? I am looking for a solution it can work with all
> computer and Server

Unfortunately there are no standards defined for CMOS other than
RTCL-ports and a few more (see RBIL).

[...]

DRAM timing data were stored in CMOS only on very old PCs, all modern
BIOS read the pNp header of the RAM chips during POST for good reason:
the user may have inserted larger/faster DRAMs.

And the BIOS isn't restricted to the CMOS-RAM, it may store setup
information in its flash-ROM.
__
wolfgang

[Hoang Nguyen]

Hi Wolfgang,

Thanks for the info :)

Cheers
Jerry