iPXE boot to Windows writing back to boot device

[SameGuyAsBefore]

Weird thing I can't figure out. I'm using a flash device to boot iPXE, if I boot to a linux system like the demo or CoreOS everything behaves normally. If I boot to a windows image / installation , somewhere between the switch from ipxelinux to windows the flash device gets written to. (am using http in ipxe to load the win boot stuff)

4 bytes get changed at 0x440 bytes in. Same place every time, slightly different data.

If I boot the windows image straight from flash, this doesn't happen.

It's possible the problem wouldn't normally be noticed but because my flash device is image trusted, I can't boot that device next reboot due to the data change.

Cheers,
Pete

[robinsmidsrod]

I think this might be Windows trying to write a disk signature to the device. If you try to make a manual syslinux boot device and allow windows to write the identifier and THEN add ipxe.lkrn then you might have something that doesn't change on each boot.

[mcb30]

(2014-03-10 10:55)robinsmidsrod Wrote:  I think this might be Windows trying to write a disk signature to the device. If you try to make a manual syslinux boot device and allow windows to write the identifier and THEN add ipxe.lkrn then you might have something that doesn't change on each boot.

From memory, Windows will always write data to the boot disk during a boot attempt. It does this in order to be able to detect failed boot attempts: it sets a flag somewhere on the disk before handing over from the bootloader stage to the full OS, and the OS clears this flag after loading everything. I haven't traced this through, but I'm pretty sure it's used to implement the "Windows did not start successfully" message.

I assume you're using wimboot, since you mention using iPXE to load Windows via HTTP. wimboot has no support for writing back to the virtual INT13 disk that it creates, and will always return a failure for any write attempt. It's just about possible that Windows responds to this failure by attempting to find another disk it can write to, and so writes to your flash device.

I've pushed a "fakewrite" branch to the wimboot repository which will ignore and report success for any write attempts. You could give this a try and see if the changes the behaviour at all:

Source code: http://git.ipxe.org/wimboot.git/shortlog.../fakewrite
Prebuilt binary: http://git.ipxe.org/wimboot.git/blob_pla...5:/wimboot

Michael

[SameGuyAsBefore]

Wow, you guys move quickly thanks. It does seem like what you describe, if wimboot is in ramdisk then windows has just moved onto the next available disk (/dev/sda). Very rude of windows to behave like that.

We'll have a look at the fakewrite now and let you know how it goes.

Cheers,
Pete.

---

Michael we dropped in your prebuilt wimboot, but got the same result. on /dev/sda 0x440 it (we think windows) writes 4 bytes. For reference we're using Win Embedded 7 as well. It seems to be just after the windows loader bar displays that it happens.

So I wonder is windows supposed to remember the bytes it destroys and writes them back at the end of success. If so, our windows image might not be doing that correctly. As much as I dislike the thought of windows writing to CF at all, letting it write twice might help....

two wrongs make a write! :-)

[mdevey]

Thanks for this, using the setup with SameGuyAsBefore.

Compiled the fakewrite branch. No luck still writes to cf.

For giggles tried the following but nothing changed.

wimboot/src/int.c

Code:

//other int 13h codes that looked vaguely write'ish
                case 0x0b:
                case 0x03:
                case 0x05:
                case 0x06:
                case 0x07:
                case 0x45:
                case INT13_EXTENDED_WRITE:
                        int13_extended_write ( params );
                        break;

Verified I used a modified wimboot by altering read to fail, and window gives a nice error message.

ipxe/win7 combo may just expose a bug in our system. Would welcome any suggested parts of ipxe I could alter to help track it down?

Thanks for your time.

[mcb30]

(2014-03-11 05:55)mdevey Wrote:  wimboot/src/int.c

Code:

//other int 13h codes that looked vaguely write'ish
                case 0x0b:
                case 0x03:
                case 0x05:
                case 0x06:
                case 0x07:
                case 0x45:
                case INT13_EXTENDED_WRITE:
                        int13_extended_write ( params );
                        break;

Verified I used a modified wimboot by altering read to fail, and window gives a nice error message.

ipxe/win7 combo may just expose a bug in our system. Would welcome any suggested parts of ipxe I could alter to help track it down?

If you're happy hacking around in the wimboot code, then I would suggest trying to intercept (and ignore) writes to INT 13 drives other than the vdisk emulated drive: see the "Pass through command to underlying INT 13" section in emulate_int13(). Note that you can't just refuse to pass through all INT 13 calls, since some are not drive-number-specific.

It should be relatively straightforward to establish whether or not the write is coming via the INT 13 interface, and to block it if so.

If you do find a hack that works, please let me know so that we can work it up into a full solution and publish a new version of wimboot.

Michael

[mdevey]

(2014-03-11 14:22)mcb30 Wrote:  If you're happy hacking around in the wimboot code, then I would suggest trying to intercept (and ignore) writes to INT 13 drives other than the vdisk emulated drive: see the "Pass through command to underlying INT 13" section in emulate_int13(). Note that you can't just refuse to pass through all INT 13 calls, since some are not drive-number-specific.

It should be relatively straightforward to establish whether or not the write is coming via the INT 13 interface, and to block it if so.

Cheers, we confirmed the write wasn't coming from the INT 13 interface.

It's completely windows.

+1B8 (+440) is a 32bit disk signature. http://en.wikipedia.org/wiki/Master_boot_record#DISK_ID

http://thestarman.narod.ru/asm/mbr/W7MBR.htm
"But once Windows has begun running, it will write a Disk Signature in the MBR. These four bytes from offsets 1B8h through 1BBh are called the Windows Disk Signature or NT Drive Serial Number"

Our work around is write a 'unique' label into the ipxe card MBR so Windows will leave us the hell alone... (and trusted image remains intact)

Code:

echo -n -e "iPXE" | dd of=unsigned.bin bs=1 seek=440 conv=notrunc
sign unsigned.bin

Apologies for wasting your time with a windows issue.

---

(2014-03-10 10:55)robinsmidsrod Wrote:  I think this might be Windows trying to write a disk signature to the device. If you try to make a manual syslinux boot device and allow windows to write the identifier and THEN add ipxe.lkrn then you might have something that doesn't change on each boot.

Got it in one. Pity I didn't pay attention...

[SameGuyAsBefore]

Might be excessive but wimboot could possibly check the MBR for disk signature and possibly throw up a warning. To be honest, how many people develop on signed images and don't add signatures? Might not be worth the effort but it is a 'Gotcha'

Thanks for the help guys.