Thursday, April 8, 2010

HTML5 to the rescue!

The other day I needed to find a way for a web page to request data from another site.  I had control of the "other" site, but not on the web page itself. I could however place javascript on it, accessible through a link.

So, what had to be done was write some javascript that when activated on the proper page, should fetch data from the "other" site and update some things on the web page as it is viewed in the browser. A classic example of cross-site scripting...

Try 1:  xmlhttp API

NOT! The browsers go into great lengths to prohibit xmlhttp requests directed to pages not in the same server, or at least DNS domain. So this one is a no-no.


Try 2: window.open

Well, this solution would let me open the page on the "other" site where the data would be, but again, browsers go into great length to prohibit any interaction of pages like above. Most of the created window properties would become inaccessible as soon as the page started to load.

Bottom line: there is no way for javascript on one page to peek the contents of another, nor there will ever be one, as it is a huge security hole.


Try 3: greasemonkey

At least, something that would work. But, letting aside the minor(?) security issues and browser compatibility, the web page not under my control strictly forbids any greasemonkey scripts stored. The will shoot them on sight and ban the user. So... no go again.


Try 4: PostMessage/ message event

After enough looking around on how to circumvent xmlhttprequest restictions or greasemonkey alternative, Google stumbled onto a reference for this HTML5 feature. Which was exactly what I was looking for! And it is implemented exactly to allow intercommunication of 2 browser windows belonging to different sites.

Really! Google for PostMessage specifically, there are enough examples already on the net describing the API perfectly.


Thursday, January 7, 2010

Virtualization nightmares

I decided it was time I dove into virtualization.


Day 1:

Set up a Windows XP guest with VirtualBox (3.1.2) on my atom netbook under Linux was very easy but of course slow. So I went on to make a cheap virtualization testbed. Used some components I had lying around: Asus P5L-MX, Intel Celeron Dual Core E3200, 1GB memory

The Asus wouldn't recognize the processor and there was no recent BIOS update for it, but would utilize it, overclock it easily (just kicked FSB to 266MHz) and run Linux like a charm. Also noted it would enable Vanderpool.

Imported the VM from my netbook to testbed computer, fired up VirtualBox (3.0.12) and... blue screen right after the loading screen and an oops logged in the host. Played with various settings, now the VM wouldn't start at all, instead the host would oops and I'd be left with a stale VM. 

Strange...


Day 2:

So then I said "OK, fine, I am going the KVM way".

Goodness, kvm (2.6.30.5)/qemu-0.12.1.2 worked and I proceeded to install a fresh WinXP guest, using a real partition this time instead of the disk image file. Installation went smooth, machine restarted and... right, blue screen. Tryed to boot a linux image (gparted-live-0.4.6-1.iso) in the VM as well but the kernel wouldn't go further than the uncompressing stage.

Played with qemu parameters a bit:

  • Disabled kvm usage: VM came up fine. Enabled it again => Freeze. 
  • -smp=1, worked with kvm!!! I was happy... a few tries later, it wouldn't... bugger.
  • -cpu seemed to have no difference.

So I upgraded my kernel to the latest available at the time, 2.6.32.2 and tried again. Lo and behold, this time the host system would freeze (no oops) as soon as I started the VM. Holy ...

What was even more frustrating was that Google search results wound never mention a freeze with kvm/virtual box in the host (or if they did, it would date 2 years ago...). And frankly, a host freeze because of the bad guest would have been a showstopper, wouldn't it?


Day 3:

Ripped another machine from someplace: Asus P5B-VM, Core2Duo E6300. Then I hooked the hard disks from the testbed, booted,

  • fired up kvm/qemu VM:  SUCCESS!!!
  • tryed VirtualBox VM: SUCCESS!!! again...

So it is the testbed hardware, rather than the software...

Flash1: testbed doesn't really enable VM-X, because the BIOS doesn't recognise the CPU correctly.
Dim1: checked the msr 0x3a, it has the correct value... and kvm module doesn't complain about VM-X being disabled in BIOS either...


Flash2: microcode?

Had:
microcode: CPU0 sig=0x1067a, pf=0x1, revision=0x0
microcode: CPU1 sig=0x1067a, pf=0x1, revision=0x0

Updated with microcode-data v. 20090927. Got:
microcode: CPU0 updated to revision 0xa07, date = 2008-04-09
microcode: CPU1 updated to revision 0xa07, date = 2008-04-09

Result:
SUCCESSS!!!!

All VMs work!!! No BSOD, no freezes, linux guest (gparted image) now boots fine as well.


3 days spent over a non-issue, that is usually taken care by the BIOS during POST. Well, now I'll know better!