Breaking BIOS: enabling VT-x virtualization support on Acer Aspire One netbook
sudonull.com
sudonull.com
FWIW the CPU in question is a 45nm dual-core, four-thread, 1,66 GHz Intel Atom chip that supports a max of 2GB of RAM. It was Intel's X86 alternative to ARM for phones/tablets.
Its micro-architecture was completely different and far more simpler and lower performing than Intel's Pentium or Core chips of the time in order to massively reduce die-size and save cost. Therefore it was slow and under-powered even back then in 2011, even without these artificial limitations put in place for market segmentation. Just ask anyone who used Atom chips of that era.
At the time you would often find these chips in cheap Netbooks and Tablets, usually by Asus, and running a bare bones Linux distro was the only way to get anything usable out of them, as getting run over by a bus was a more enjoyable UX than running windows on them.
In a way, those cheap, light, portable Netbooks were ahead of their time, held back mostly by the low performance of the low power chips of the era, the bloat of Windows of the era and the jankyness of bare bones Linux distros of the era that wouldn't ship with the mainstream apps people used on Windows.
So as cool as this hack of removing the artificial limitations is, I'm not sure how much this really helps to make a case for using this CPU for OS virtualization using Windows VirtualBox on all four threads, considering the already severely limited performance and RAM.
Guess I should be thankful though, in trying to get it to be faster I discovered that some Linux distros can be very lightweight, and it started me down a rabbit hole I'm still going down.
It was a bit like the microcomputers in that respect.
Sort of like a chromebook before chromebook.
I later did a lot of C, PHP and Python programming in Linux + Emacs on such a computer, so not completely useless.
[0] Actually the PCH, aka southbridge, not the CPU. But it's not much of a difference for end users.
See:
* Intel Boot Guard, Coreboot and user freedom
https://mjg59.dreamwidth.org/33981.html
* Why You Don't See Coreboot Supported By Many Modern Intel Systems
https://www.phoronix.com/news/Intel-Boot-Guard-Kills-Coreboo...
* Bootguard (for a technical description)
As someone who used one of these laptops as a daily driver for years, I disagree. The CPU was quite powerful. I would regularly use it to take notes in class, do development work (with an IDE) & browse the web. Compilation of larger components could be quite slow.
If you didn't insist on running the latest desktop environment with a bazillion bizarre graphical effects, it worked without issue. Battery life was 'good enough' that I could get a couple hours of regular usage.
Fast forward to today & many "productivity" applications like Microsoft Teams are so bloated they consume more memory than the entirety of that system had.
The benchmarks, reviews and poor sales disagreed with you. Maybe it wasn't under-powered for your standards and needs back then, but compared to what the mainstream laptop market of the time, they were very slow in windows apps which is what most consumers ran back then.
I think the fact that I consider XP to be performant is the fact that I had less to compare against back when it first released.
reducing power consumption was also a goal, which this worked for too. Though the early models at least were paired with hungry chipsets that negated most of that benefit.
My little netbook running Debian was a bargain and did sterling work for a while, and I know others that found that form factor and other properties to be rather convenient.
Sales numbers did fall off precipitously eventually, partly due to new models being hobbled by restrictions from MS (they wouldn't sell them XP for higher spec models IIRC, so no models got much of a RAM upgrade, and as that became an issue market share was lost to tablets (and to a small extent smarter phones) and higher spec laptops).
Sales number were good at first because all consumers were drawn to the massively small price tags of these machines along with the small form factor/increased portability. They were like 50% cheaper than a regular laptop and could fit in your purse/cargo pants. Who wouldn't want that?! Especially in developing countries like Eastern Europe where a regular laptop would cost several months(plural!) wages.
> Sales numbers did fall off precipitously eventually
Yes, because after purchasing them, consumers wised up and realized the low price tags came with some huge compromises the Average Joe did not expect (Atom CPU was too slow for Windows which let's face it was by far the most used OS back then, low-res display, minuscule eMMC storage that filled up far too quickly, the Linux ones didn't ship with a sane mainstream distro like Ubuntu or Mint but with some weird bare-bones custom one that had no mainstream apps available, playing PC games was an absolute no-go, etc.) so the Netbook market crashed, as unless you absolutely needed the small form factor and willing to put up with these compromises, you were much better off buying a second hand used regular laptop at the price of a new Netbook.
In a way, these slow, small-storage, weird-Linux, Atom Netbooks kinda poisoned the well for the rest of the market segment, even for the "good Netbooks" whcih were more capable, until Apple came with the Air and the PC market brought the Ultrabooks.
The only place I saw Netbooks flourish was, no joke, the taxi drivers in my Eastern European country, which, due to their diminutive size, would attach them to the central console of their ancient cars as some DIY infotainment system, and use them to watch movies and play games while waiting for customers (not gonna lie, a 2010 Netbook with keyboard bolted to the central console is still a better infotainment system than the touchscreen ones shipping in most modern cars today). I even saw one taxi driver playing DOTA on a Netbook in his car (not while driving, although for Eastern Europe that wouldn't be out of the picture).
...and yet they decided to add VT-x for some reason, but disable it?
You can also buy cars with included heated seats and they're disabled unless you pay extra.
Also WiFi/Bluetooth can be problematic when they are on SDIO, in my personal experience. Which anecdotally for me was about 50% of the time.
I used a N455 based netbook for years as a motorcycle-laptop with a stripped down Debian. Unfortunately I didn't know about Alpine Linux back then, which could likely have made it a lot faster. Also, my home NAS uses a D410 CPU which is enough to support two ZFS pools and other services.
I actually upgrade from the 1.66gz atom to a 1.3ghz ULV core 2 duo, and it was way faster.
Netbooks being used for programming was a very niche use case (maybe not on HN, but in general). Most programmers had more powerful and versatile PCs/laptops at the time for that.
That explains why they disappeared so quickly. But yeah, they were excellent for cheap linux devices.
Early atoms were really slow, compared to e.g. a SiFive P270, which is also in-order.
Out-of-order CPUs exist that are much slower. After all, in-order CPUs can be superscalar still.
It worked well, but I could pretty much only run one program at a time. It felt more like the old microcomputers in that respect!
But that forced me to use dwm and Arch Linux, and learn a lot more in the process.
And Zathura for lightweight PDF reading (with customisable colours!).
And of course vim and emacs (you're not running IntelliJ, PyCharm, etc. on that).
But it worked really well, and in retrospect was probably good for productivity as you couldn't really do anything else. So I'd download Coursera videos and watch them on the train with mpv/mplayer, etc. - it was frustrating when I had to fix some GUI code on-the-go though, and could barely use Glade with the tiny resolution and screen.
Anyone have insight on it ? What's the utility of being able to disable virtualization ?
Even in case of "corpo disallows it" (for whatever idiotic reason) it can be turned off one way or another in OS...
I consider the option to disable (or rather: enable this function manually if you need it) virtualization to be quite useful because if this feature is disabled, malicious software cannot install a virtualization rootkit, i.e. a rootkit that makes itself a hypervisor and moves the current OS instance into a virtual machine running under this hypervisor.
See for example https://en.wikipedia.org/wiki/Blue_Pill_(software)
As far as I know, it just enables a few new CPU instructions, but older software that didn't know about them wouldn't use them anyway?
So for 'broken' software (and there was a lot of it - even back in the day of the turbo button) it often can be better to just not allow the software to see/use all the hardware.
Example of the weird stuff you have to first know about, then detect and then mitigate, on a per-device basis: https://marc.info/?l=linux-iommu&m=139305749014927&w=2 and that's something that when you don't do it, the software doesn't deal with it very well. Since not all software can be influenced by its operator (be it lack of skill, resources or simply legally not allowed), it can be much easier to just have a switch in the firmware where you can hide it from the software.
Switching code paths based on MSR is something that is one of the safest (and broadest) things you can do early on when you start up, so in a way, such a switch is merely "supplying configuration" but in a pre-boot fashion.
As another datapoint, I have a machine with VT-x enabled and Windows 98 runs fine. It just doesn't know about the extra features the CPU has (like it also doesn't know about it having more than one core).
The best combination is either software that knows the issues for each implementation and can work with it, or software that doesn't use the features (either not using them natively or by making it unavailable to the software).
It's amazing how string-and-chewing-gum some hardware is with software working around so many issues to not crash. Sometimes there is good documentation, errata or usable flags (like MSR bits), sometimes it's just 'lower the pressure until it stops crashing' and you get a fat list of quirks.
Corpo can disallow that too via central policies
(Edit: of course, that wasn't the case when this particular article and BIOS was written.)
Also, there's no breaking involved as there's no signature anywhere, it's a reasonably simple mod. For example, re-enabling CPU undervolting seems to be impossible in modern ThinkPads because the UEFI firmware is signed.
Why can't you upload your own private key in the new bios payload, like you can for SecureBoot?
Everything is sitting in a flash chip. Some parts may be RO, but it can be replaced by another chip if you can't tweak it directly with flashrom.
Vendors burn a key into the system which prevents loading an unsigned BIOS. This is a one-time-programmable fuse (OTP fuse) and part of Intel BootGuard protections.
You get a laptop with _fused burned_ to prevent loading other firmware to your device. Booting won't work if you load a replacement SPI chip with anything but a vendor-signed firmware.
I don't think I'll be doing this, nor, as I briefly considered, trying to wedge a raspberry pi in the case. Cute machine though.
But I did learn the hard way that they’re really not meant to run like that: the fan became increasingly noisy until it sounded like a car ignition, and the heat (when the fan was working fine!) managed to slowly wear out the membrane keyboard, killing more and more keys, making in-person debugging kinda difficult.
But it was really cool. And I still have its more performant cousin Asus netbook somewhere!
I think the more likely explanation is that AMD wants to sell 500 series chipsets and is using its leverage on the board vendors.
Looking at you, Dell BIOS and Intel i7-2700 and Intel Q65 chipset.
I have a few ivybridge era chipset boards (B75, Z77) some of which actually don't officially support this feature but the motherboard manufacturers enabled it in bios anyway and it works. The sandybridge era was much messier for this feature.
It is very irritating Intel tried to gate this behind chipsets since I believe it is 100% handled by the processor.