I thought I'd reply to your private-message question here because it is one I get asked frequently and I might as well write it once and let others find it at their leisure
On your point about the manufacturers restricting features - part of the joy of the open-source world focused around GNU/Linux and BSD is that it is possible if you're determined enough to take back control of your PC and make sure it does what you intend, not what some cost/benefit analysis of the manufacturer's likely support costs has dictated!
I would like to experiment a bit myself with that BIOS issues. Would you please be so kind as to tell me how you managed the BIOS trace you reported? A short sequence of the steps and tools required would really be appreciated. Thanks in advance
I guess most of the knowledge on how to do this is something I've acquired from years of programming, hacking, and system-building.
It helps a great deal to have an instinctive 'feel' for how programs appear in assembly-language especially, and the choices of instructions to achieve particular aims.
As to tools, it is generally a case of having to hand basic tools such as hex-editors to view the raw bytes of a file - that gives you a good 'sense' after a while of how things are laid out, where you're likely to find things, and the common patterns and sequences.
Using disassemblers to reduce binary programs to assembly-code listings (the stuff fed into an assembler) is a good step especially if the disassembler is intelligent and can 'spot' calls to common library functions.
With BIOS editing things are a bit different. First you need a tool to extract the code from the usually compressed BIOS image files as stored in the ROM. For that it is usually a case of Googling for clues as to what others use.
That's how I discovered I needed Phoenix BIOS Editor. I had used the open-source tools that can split/recombine the older Phoenix BIOS images and that gave me a lot of understanding of how they are structured by reading the source-code.
Knowing how the Power On Self Test sequence of a PC works is critical as is understanding the standard BIOS calls via software interrupt that were a mainstay of the DOS era. All BIOSes still have to be backwardly compatible with that so you've got a known interface to base some key assumptions on.
The way I found the section of code that does the VMX-bit testing was to identify that the machine code instructions to read/write MSR registers of the CPU had particular op-codes. I knew the MSR register I was interested in was 0x3A so I could work out the opcode of the instruction "WRMSR 0x3A" and then search for it within all the BIOS code I had.
For this you need the manufacturers CPU manuals that detail the opcodes to hand. I spend a lot of time scanning/reading the IA32/IA64 Manual PDFs which are freely available from Intel.
Then for each occurrence I had to examine the code at that location and the code leading up to and after it to be sure it was actually an instruction sequence and not some random non-code data area that just happened to contain those bytes.
Once I had ensured there wasn't more than one use of the instructions I was interested in I could be sure I had the only execution-path that used those instructions (sometimes you'll find multiple occurrences and you might be caught out by analysing a code-path that isn't used in practice!) I could work out the thoughts and design principles of the programmers and from that make assumptions about how organised they were in laying out their code and data structures.
And finally from that I could explore the data structures and compare them against other BIOSes from different machines to be sure what I was looking at was standard library code from Phoenix rather than custom-code from Sony.
With that knowledge I knew I could write a tool to alter a predictable memory location in NVRAM and it would be 'safe' on all models with similar Phoenix BIOSes.
The essentials of being able to do this kind of hacking successfully are long hours of frustration and learning from following dead-ends, testing of lots of command-line tools, Googling and reading seemingly unrelated information until your eyes ache, and writing script files to do something useful by stringing the command-line tools together.
Oh and don't forget the most important thing of all - thinking
and putting yourself in the mind-set of the original programmers so you can make assumptions about how they'd go about something and make predictions and intuitive leaps based on them.