While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature.
Apart from that, I will definitely use that project as a documentation for "how to run MacOS/Windows in KVM". Cool project :) .
Checking hashsums against downloaded hashsums file is pointless. If you're being MITMed (and downloading from `http` is asking for being MITMed), you'll download fake checksum. Proper check will require using GPG with pinned keys.
Which, without some form of certificate pinning, could still be MITM'd. At least if there's a catalogue of hashes for everything it downloads (hard-coded or configurable by the user, latter preferred) then at least it can verify the right files are being downloaded regardless of source.
Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.
> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.
Well that's a matter of trust as well, isn't it? I would assume that even if it's user configurable, the app itself should still ship with an up to date catalogue whenever a new release is made. After all you're already trusting the app itself at that point.
If you are having your SSL connection to Apple MITMed, then you have much bigger problems. Ones like "why do you have a malicious root cert in your keychain?!"
> without some form of certificate pinning, could still be MITM'd
Now, apparently this uses plain http - but if tls/https is an option - any client (like curl/wget) should by definition come with a ssl trust root (os or bundled). If this is mitm'ed, you've got big problems. Certificate pinning doesn't really help that much in this case.
It's hardly stealing if the original owners still have a copy. It's more of a breach of terms of service, or unlicensed access to intellectual property.
The "theft" spin on copyright violation is the result of years of lobbying by the media industry because they foresaw a drop in sales when people didn't need to buy the same thing over and over again.
Property is about who has the right to control something, not about scarcity. Although its original application was to a physical object, it's not limited to physical objects. So, "stealing" can be considered in both a narrow context and a broader context. The narrow meaning refers to literally taking a physical object away from someone else and giving it to yourself. But the broader meaning is wresting exclusive control of the property from the lawful owner. So, in that sense, copyright infringement and license violations can be legally thought of as theft.
Ignoring the legal and accounting details, the basic idea is that macOS is something that Apple includes with each Mac computer that they sell.
If you don't own a Mac, you don't own macOS. If you own a Mac and some other computer(s), you own macOS for the Mac, but not for the computer(s). You might've purchased an upgrade to a newer version of macOS, but if you don't already own a Mac, you don't have something to upgrade, so the upgrade doesn't grant you ownership of macOS.
Now, from a legal point of view, it's a good deal different from (and more complicated than) that, but that's the basic idea. So don't make the mistake of thinking that because Apple gives macOS away for free to Mac owners, and don't use elaborate and onerous copy protection or license-tracking nonsense, that you're entitled to install it on something other than a Mac.
I think that the illegal (ish) part comes from Apple making macOS free if you're installing it on Apple hardware. They don't publicly license it for use on non-Apple hardware, although, I would guess that VMWare if not others has a license to run it on random x64 servers to test ESXi with because setting up a different testing environment of Mac Minis to test every change to their hypervisor on instead of using their normal testing infrastructure would be dumb.
> I think that the illegal (ish) part comes from Apple making macOS free if you're installing it on Apple hardware.
I don't think it's true since the phrase in question was present also in Mac OS X when we had to purchase each version. Apart from that, this part of the license is not valid in several European countries. When you think of it, it's quite reasonable: how could anyone dictate how you are using something you purchased? It makes no any sense.
As with all information, society as a whole "owns" macOS - Apple only has been granted a temporary monopoly of this information in order to encourage them to create more.
Innumerable court cases have turned on what are often negligible practical differences. Apple is said, legally, to "hold" copyright. Saying they "own" it would mean they have all sorts of rights and powers around it that we as a society choose not to grant to them.
That is not to say that numerous judges have not, on their own initiative, elected to grant holders many such powers. Judges can be just as confused as anyone, and more than some, and so exceed their statutory authority. Congress, moreso. But there is still a difference.
Sure, and I didn’t argue for or against the use of that term. The legal definition of theft varies by jurisdiction, but is not necessarily limited to physical objects (e.g. services). I have no idea whether it’s appropriate in this case (I’m not a lawyer), but feels more like copyright infringement.
Control is a part of ownership. If you don't control how something is used and by whom, you don't really own it. So either using it in unauthorized ways is in a manner theft, or Apple's "ownership" is not real ownership. I'm not sure what the solution is, but IP is a tricky concept no matter your position.
It has nothing to do with actually preventing all infringement, but instead seeking enforcement in at least some cases. If a copyright owner is aware of substantial infringement and chooses not to pursue (or license) they may lose their copyright through genericization or other means.
(Caveat: I’m not a lawyer, but I learned broadly the above from an IP lawyer.)
It's a Rot13-encoded string: "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc". It seems to be the string that is supposed to make MacOS only run on certified systems, but it's obviously been reverse engineered and now it needs to be added to any Mac emulators to work.
(1) You supply this value in the "DeviceKey" config parameter
(2) Ensure the "GetKeyFromRealSMC" boolean config parameter is enabled (not sure if it is turned on by default or not). When enabled, VirtualBox retrieves the value from the SMC of your Mac.
Obviously method (2) only works if your host is a Mac. Apple doesn't supply a public API to retrieve this value, so VirtualBox has some code which runs inside a macOS kernel extension, and directly uses the SMC hardware registers to request it. [EDIT: Actually, turns out macOS does have an undocumented API for this – talk to AppleSMC using IOServiceGetMatchingService, IOConnectCallStructMethod, etc – and they use it, but they still fall back to direct hardware access if the API call fails, or if Windows/Linux/etc is the host OS and Apple hardware is detected.] VirtualBox already has a bunch of kexts needed to provide various features, and so this is just a bit more code in one of those kexts.
Option (2) is a lot of extra complexity compared to option (1), but has the advantage of being legally much cleaner. Option (2) only works on Apple hardware, and so by using option (2) Apple's license condition, of only virtualising macOS on Apple hardware, is automatically enforced.
Considering that VirtualBox is from Oracle, and as well as open source, they also sell it as a commercial product, you can understand why Oracle's lawyers want option (2).
So my understanding – if you run VirtualBox on macOS, and you choose macOS as Guest OS type when creating your VM, it automatically turns GetKeyFromRealSMC on. That means you are using option (2) by default. You can always switch to option (1) instead if you want to, but if you are virtualising macOS-on-macOS, there is little reason to.
From reading the VirtualBox source code [0] – it also automatically enables GetKeyFromRealSMC if it detects Apple hardware, even if the host OS isn't macOS. So, if you install Windows on your Mac, and then create a macOS VM in VirtualBox, it will automatically select option (2) as well. (I think, they actually include the code to talk to the Apple SMC in their Windows and Linux kernel drivers too.)
(Note I haven't actually tried doing this myself, this is just what I gather from the source.)
VirtualBox has code to do the above. But it also has code in one of its kexts to do it by talking directly to the hardware, in case (for whatever reason) this API doesn't work; it tries IOKit first and then calls the kext as a fallback. And, the kext doesn't solely exist to talk to the SMC, it does a bunch of other things too. I'm not sure whether VirtualBox works without its kexts, but if it doesn't, it isn't because of this reason.
(When I wrote my original comment above, I didn't know you could do this through the IOKit API, although I've since edited that comment to mention it.)
That would likely need to be built for every version of MacOS that's ever been made, it's easier to emulate the hardware and provide the key it's looking for. That part alone shouldn't violate any ToS or laws on it's own, as long as the key isn't provided by the emulator/vendor. That will still allow you to
still virtualize MacOS on the actual hardware (as is required by the license of the OS) without having a hacky patch in place that could lead to crashes or failures to boot whenever an update is applied to the guest.
disclaimer: I am not a lawyer, this is not legal advice, etc.
It is illegal under the DMCA to circumvent an effective copy protection measure, or to traffic in devices intended primarily for such circumvention. The law sets a very, very low bar for what counts as "effective". Basically, if you get around any obstacle to unauthorized copying or use, or show others how to get around it, you have committed a felony. Everyone who has repeated the device key here has committed a felony.
Seems people really avoid saying the value, ('don't be surprised it doesn't look like a random string') maybe there's some history of Apple requesting people cease & desist wherever they find it, I don't know.
I'm guessing it's more of a philosophical stance rather than avoiding detection. Like "Apple isn't going to make me put the string 'dontsteal' in my repo".
It's odd the things we remember. I memorized a 25-digit Windows 98 Key because of how many times I reinstalled it. I don't remember why I had to reinstall it so many times, but I sure remember the key!
What I would really like to exist, is a VM image for Windows 10, without all the telemetry, updates and anti-virus software. I hate that when I need to test something on IE, my laptop's fans start spinning up, and the VM is unusable, because Microsoft decided its a good time to scan the whole disk and consume all the vCPUs allocated to the vm.
I use the Windows Insider program to run legitimate Windows, and used a bunch of debloat/decrapify programs from Github to try to remove the worst offenders. But damn does Windows Defender and some of the other stuff really ream my resources, and there doesn't seem to be any easy way of permanently disabling them =(
I'd never heard of an "LTSC" Windows either. Interesting.
---
EDIT: Ahh it says there's no support for DirectX12, only Vulkan?
I don't know much about this stuff -- I thought it was a software SDK you could just install. But if not, that seems like a pretty huge con:
It's not. ReactOS is a long-running project aiming at creating an open source OS that is fully Windows compatible so you can run Windows programs on it.
While it doesn't have telemetry and you can run it as a VM (arguably the better choice, given it's state), it is not Windows 10 by any stretch, and I guess it doesn't run the latest IE version (but I haven't tried it in ages)
If anyone tries running Photoshop under Windows using this and has good performance please tag me in a comment. I've migrated several times from Qemu, VirtualBox and settled on VMware player (for non commercial usage).
I found that to be the "best" performing, although still leaves a lot to be desired and having to open the application, manually sign kernel drivers and then reboot after every kernel upgrade is a little tiresome.
Sadly no, my Ryzen doesn't have an iGPU and I only have the one dedicated GPU. VMware's software? acceleration is partially useful however, there are some bugs requiring disabling transparency in Windows but various Direct X programs run mostly acceptably. I find it the best performing of the 3 setups when using GPU passthrough is not available.
The first problem is rendering within the guest. If you only have one GPU, then GVT-g [1] virtualizes it with just a bit of overhead. But it's Intel only.
The second problem is getting those pixels onto your screen in the host. SPICE is not as fast as Looking Glass [2], which sets up a shared memory buffer between the host and guest. This has acceptable performance even for modern games.
The OP doesn't seem to utilize these techniques, so I don't think it can plausibly claim to have the fastest configuration - at least not yet.
Neat. Something not to forget is that USB devices (host) passthrough can be tricky, as it's a passthrough of the device, not the port. In difficult situations, https://github.com/darkguy2008/hotplugger comes handy (although it needs setup work).
I want to run many old windows [95 - XP] applications and games. If there is a way to have minimal os emulator (at least with all dependencies of that app/game) it would be great to have it as a container for that app.
I tried setting up qemu once by downloading many images. Almost none worked with apps I wanted to run. Also I had a very hard time finding a sane qemu documentation in one place. It's wiki is very messy to go through.
So is there anything to run win 98 to win xp apps in emulator/sandbox/container easily?
I haven't tested it yet, but I recently came across boxedwine[0] which is basically wine + an emulation of the linux syscalls + graphical api forwarded to the host. All that wrapped in SDL.
Is there an easy to follow documentation for dosbox-x? And can it work with pre-built images?
I have tried to use it a few times but got overwhelmed by all the options. From the screenshot it looks exactly what I want (only for windows 98 though).
Is there a windows image that contains none of the hard dependencies like Edge and all stuff? I'm looking for a Windows 10/11 with every that's not necessary stripped out for a local VM for when I need Windows. Ideally things like telemetry, unnecessary apps, windows store etc all removed would be nice. I recall nLite used to be a thing for Windows XP.
I don't know if there's one out there right now but I think it should be possible through the UUP process for creating windows install isos. At least if it is possible that'll be how it's done these days. That might give you enough info to find it if it does exist.
edit: from another comment thread here, https://ameliorated.info/ is apparently everything you're after. Not sure of any info about it myself but that looks to be decently useful.
It's sad that Qemu is so hard to use that scripts like this are necessary.
All this autodetection of the OS to apply tweaks and workarounds to make the OS run properly should ideally be eliminated entirely, and if that really isn't possible, it should be part of Qemu itself rather than requiring a special wrapper script to apply the right flags to make things work.
You are not really supposed to run QEMU directly if you are looking for that kind of experience, that's why libvirt exists. Other than that, QEMU should really be a generic emulator rather than being infested with platform-specific stuff, everything else should be independently maintained and pluggable. (Autodetection is also extremely fragile, and takes away from keeping a VM a VM)
But it would be easy to design qemu to have 1000+ config options which are on/off/auto settings, and the 'auto' mode is autodetected based on which OS is probably running.
Nothing stops someone overriding some or all of those flags to whatever values they like. It's still a power user tool, just one that also 'just works' for common usecases of people who don't want to manually set the IRQ number for the DMA controller by hand...
> But it would be easy to design qemu to have 1000+ config options which are on/off/auto settings, and the 'auto' mode is autodetected based on which OS is probably running.
That would add a ton of new responsibility to a codebase that so far has been doing none of this. It would have to be aware of different operating systems, operating system image formats for autodetection, OS releases and their corresponding quirks, ... And some way to test this, and test this automatically, so that this stuff doesn't immediately rot away. People would begin to depend on this, and any change in this behaviour would be a breaking bug, and would introduce implicit stability contracts for complex scenarios.
Let qemu be low-level emulator and make zero assumptions about how it's being used - that makes life so much easier for those of us who integrate it into non-standard scenarios. Libvirt gives you everything needed for typical 'I wanna run a commercial OS in a VM on my desktop/server', and can afford to make assumptions about its usage scenario.
I'm not sure how it works now, but a few years ago it was illegal to use more than one copy of Windows in this way (provided that you already have a purchased copy). If you wanted to have two instances, you had to purchase a second copy. I'm not sure what the relevant terms are for macOS now apart from the fact that in the old days VMware had an artificial block you need to remove in order to run Mac OS X. It would be interesting to know the current legal ramifications.
AFAIK you can use Windows unlicensed as long as you activate it after evaluation. You're right that you can only run one instance of a given Windows product code on a machine for long-time use, though.
The last I heard about the macos situation is that virtualisation of macOS is allowed as long as you do it on Apple hardware that you have a license to run macOS on. You can run as many virtual machines on your mac as you want, as long as you've paid for the OS on your mac, which you can't buy separately anymore (making any restrictions on licenses a full ban on macOS VMs, which nobody wants). Perhaps you could buy additional licenses through second hand shops, depending on your jurisdiction.
As for legal ramifications, I don't think either Microsoft or Apple will care if you use this for your personal projects. Don't try this as a business, though, because that's where the lawyers start caring.
Legally, you'll probably be liable for a civil lawsuit from either Apple or Microsoft. I don't think it's actually considered a crime to run a copy of software without a license in most countries.
> You can run as many virtual machines on your mac as you want
No, the EULA says:
> (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software
within virtual operating system environments on each Mac Computer you own or control that is
already running the Apple Software, for purposes of: (a) software development; (b) testing during
software development; (c) using macOS Server; or (d) personal, non-commercial use.
Interesting. I was always under the impression that you can run a macOS VM as long as it is on Apple hardware. But this says "that is already running the Apple Software".
Does that mean Apple Hardware -> Linux -> macOS is not allowed? Or is it simply saying that all 3 copies must be on the same machine? So you can run Apple Hardware -> Linux -> macOS as your "primary copy" and two more macOS VMs on that same Apple Hardware?
IANAL, but this whole section of the Big Sur license is a bit of a mess to read and understand — for example, per section 2B(i), copies of the OS downloaded from the Mac App Store by individuals may only be used for "personal, non-commercial use", and downloaded from the MAS only on computers running older versions of the OS.
In other words, for an individual (vs. a "commercial enterprise or educational institution"), both of the following appear to violate the license:
(1) Downloading Big Sur from the Mac App Store using a machine running Big Sur itself, for any purpose: the virtualization section 2B(iii) expressly excludes the term "download" from the phrase "download, install, use and run", and, while the other section 2B(i) applicable to individuals does permit downloads, it only applies to computers running Catalina, Mojave, High Sierra, Sierra, El Capitan, Yosemite, Mavericks, Mountain Lion, or Lion.
(2) Using Big Sur for any commercial purpose, e.g., working from home as an employee, or non-personal purpose, e.g., producing flyers for a school bake sale.
The old trick of buying an OEM copy of Windows (instead of paying full retail) when you were not an OEM building a computer to be sold to others was just as "illegal".
Vagrant is an orthogonal tool to this, it is a VM orchestrator not an actual VM. What does this do: well, qemu doesn't have virgl support merged yet, so you need to go to some lengths to compile it for yourself.
All of the other stuff (spice, virtio) is for "it should be a nice user experience and perform well" above and beyond simply being fast enough to use. In other words, you should be able to copy and paste between the host OS and the guest. You should be able to slide your mouse across the border of the VM window and do some clicking around then simply slide it back out and use your mouse with native host-OS windows again. It should have all of the features you expect and not force you to read a bunch of tutorials to find the features you expect from your desktop VM.
These things are all not granted when you use qemu out of the box. I have this intense 25-lines "qemu" script for invoking qemu-system properly. It was enlightening but I'm not sure how much I was enriched by the process of actually figuring all this out.
Quickemu is, I guess, for making figuring out all this stuff and making it easier to do (and on Linux.)
> I have this intense 25-lines "qemu" script for invoking qemu-system properly. It was enlightening but I'm not sure how much I was enriched by the process of actually figuring all this out.
Do you have your script posted publicly somewhere?
This expects you're using the special qemu from the prior link, compiled with homebrew. (else I think there will be no virtio-vga-gl video driver?)
The guest OS is an Ubuntu VM. I think the instructions say to use a recent Fedora/Silverblue for a reason (there are some things that don't quite work right around window resizing.)
Each time I start the VM, it shows up with tiny tiny pixels and the menubar does not work. I switch to another app, switch back, go to the menu and enable "zoom to fit" and it's off to the races. Other things to be aware of, if you resize the window it actually scales the pixels, (which is OK and doesn't even have any noticeable perf impact because OpenGL, I guess)
If QEMU is compiled with graphical window support, and is started without `-nodefaults`, then you can press ctrl-alt-2 to switch to the monitor, type "sendkey ctrl-alt-delete", then press ctrl-alt-1 to switch back to the emulated display.
Common QEMU frontends may have a UI button or keyboard sequence to do this for you (they connect to the monitor backend and send the same command, either as text or as JSON (in "qmp" mode)).
I've always kept a script like this on my computer, but the idea of "optimized" is very subjective, volatile, and prone to change. Also, that was a reason why I ditched libvirt, because once its internal change impacted the performance on my side. There's just no correct answer here.
Certainly, however, this can be handy if one needs to quickly spin up something.
FWIW I use my Windows 10 Pro (VLK) license on my gaming PC, and as a virtual machine when using Linux. It's undergone 3 activations, initially for the desktop, once when I was using VirtualBox and the last when I converted my VDI to VMDK when I migrated to VMware. All activations were several months apart however.
Windows activation servers were happy enough with that, without any install becoming unactivated (other than the VirtualBox to VMware conversion which is the 3rd activation).
While you can use Windows unactivated but it restricts access to various settings, which may not be important to you depending on your use case.
Legally, I think yes? You can definitely run macOS under ESXi when it is installed on a real Mac, so I can't imagine the difference between a type 1 and type 2 hypervisor making a difference.
I haven’t tried this yet, but I’m very excited about this. Virtualizing MacOS is extremely painful, and windows is not fantastic. It would be wonderful to be able to quickly jump in, and build and test a program without a lot of preparation. Thank you!
Apart from that, I will definitely use that project as a documentation for "how to run MacOS/Windows in KVM". Cool project :) .