Now, I try to write positive comments on my blog, but now and again things really irk me and I need to comment about them.
Google is using wireless access point SSIDs to construct a database to enable devices to determine their location using wireless and hence not relying on GPS. If you want to opt out of this database, Google is suggesting that one should simply append _nomap to the SSID. Google also hopes that this will become a standard SSID opt-out for any location service database.
This basically means that if you want your desired SSID you get opted into Google's database (so much for privacy), otherwise you have to put up with some utterly stupid name that Google mandates. Thanks for the choice Google. And there is nothing to stop other location service providers either suggesting a different naming scheme to make it impossible to opt out of one or more schemes.
Now, if the UK government mandated that all SSIDs needed to be named in a specific way to opt out of their special database, there would be uproar. However, Google just ploughs ahead with more of their data gathering and nobody seems to complain.
Wednesday, 16 November 2011
Monday, 7 November 2011
Does your UEFI firmware have CSM support or not?
UEFI Compatibility Support Module (CSM) provides compatibility support for traditional legacy BIOS. This allows allows the booting an operating system that requires a traditional option ROM support, such as BIOS Int 10h video calls.
While looking at boot and runtime misbehaviour on UEFI systems I would like to know if CSM is enabled or not, but the question is how does one detect CSM support? Well, making the assumption that CSM is generally enabled to support Int 10h video calls, we look for any video option ROMs and see if the real mode Int 10h vector is set to jump to a handler in one of the ROMs.
Option ROMs are found in the region 0xc0000 to 0xe0000 and normally the video option ROM is found at 0xc0000. Option ROMs are found on 512 byte boundaries with a header bytes containing 0x55, 0xaa and ROM length (divided by 512) so we just mmap in 0xc0000..xe0000 and then scan the memory for headers to locate option ROM images.
My assumption for CSM being enabled is that Int 10h vectors into one of these option ROMs, and we can assume it is a video option ROM if it contains the string "VGA" somewhere in the ROM image. Yes, it is a hack, but it seems to work on the range of UEFI enabled systems I've so far used.
For reference, I've put the code in my debug-code git repository and available for anyone to use.
I've also added a CSM test to the Firmware Test Suite (fwts). One can install fwts and run the test on Ubuntu by using:
While looking at boot and runtime misbehaviour on UEFI systems I would like to know if CSM is enabled or not, but the question is how does one detect CSM support? Well, making the assumption that CSM is generally enabled to support Int 10h video calls, we look for any video option ROMs and see if the real mode Int 10h vector is set to jump to a handler in one of the ROMs.
Option ROMs are found in the region 0xc0000 to 0xe0000 and normally the video option ROM is found at 0xc0000. Option ROMs are found on 512 byte boundaries with a header bytes containing 0x55, 0xaa and ROM length (divided by 512) so we just mmap in 0xc0000..xe0000 and then scan the memory for headers to locate option ROM images.
My assumption for CSM being enabled is that Int 10h vectors into one of these option ROMs, and we can assume it is a video option ROM if it contains the string "VGA" somewhere in the ROM image. Yes, it is a hack, but it seems to work on the range of UEFI enabled systems I've so far used.
For reference, I've put the code in my debug-code git repository and available for anyone to use.
I've also added a CSM test to the Firmware Test Suite (fwts). One can install fwts and run the test on Ubuntu by using:
sudo apt-get install fwts
sudo fwts csm -