- Simon's Lament Mac Os Catalina
- Simon's Lament Mac Os X
- Simon's Lament Mac Os 11
- Simon's Lament Mac Os Download
Bad news, everyone. Macs sometimes have bugs. Time to ditch your Mac and, uh… well, the next step isn't so clear.
Writing for the Forbes contributor network and set of the gameshow 'What's That Smell?' which was canceled before it premiered, Ewan Spence describes the 'Three Damaging Mistakes That Guarantee More MacBook Pro Disappointment.' (Tip o' the antlers to Alex.) Tic tac toe (itch) (intsmite) mac os.
VSTi AU-Patcher. The patch fixes issues that you may encounter when running our VST instruments on Mac OS X versions 10.10.5 (and earlier) and Mac OS X 10.11.x in AU hosts. Formal support for CrossOver Mac on Intel-based Mac OS X¶. Overview: As of December 2007, SIS is formally supporting running the Windows version of SIMION 8.0/8.1 on Intel-based Mac OS X via a third-party application called CodeWeavers CrossOver Mac.This means that this combination generally runs quite well, and has been tested by SIS. My Mac Software. I've written a lot of Mac software over the past ten years. Here are some personal projects that are mostly still current. You can find more about my professional projects on my work page. MT-NewsWatcher—a Usenet client for Mac; MacCVS Pro—a GUI-based CVS client for Mac; Chronoscope—a profiling tool for Mac OS 9.
[Takes MacBook Pro he's typing on, chucks it in the river.]
Having a safe and secure computer is a requirement that is becoming more important to consumers.
As opposed to years past when everyone was fine having a computer that anyone and everyone could get files and photos and browsing history off of.
A lot of people don't remember this but porn was only invented last year. True story.
For many years the Mac range of computers, from the MacBook in your bag to the Mac Pro hiding under your desk, were regarded as a gold standard, immune to malware and secure against malicious attacks.
Some may have regarded them as such, but they never were, of course.
In the last few months that perception has been challenged by errors on the part of Apple and its suppliers. Light consumed mac os. The strong selling point of security is no longer there.
Isn't it? Let us assume for the moment that you 'need' a computer of some kind. If we assume this, which seems like a fairly safe assumption these days, then the question is not 'Which computer is 100 percent impervious to malware and malicious attacks?' but 'Which computer is more secure against malware and malicious attacks?' And the Macalope would argue that, while it's a complicated issue, the Mac still holds an advantage over Windows, at the very least because Windows is still targeted more.
The biggest flaw that sticks in the mind was the discovery that a blank password field would allow anyone to log in with root access to the Mac.
Yep, that was what they call in the information security business [seventeen very filthy words that cannot be published on a family website like Macworld]. Fortunately, this has been patched. This week brought us another macOS security flaw, thankfully one that is much more minor.
Yes, these are not good things. But if your plan is to switch to Windows because security is all screwed up on the Mac but better on Windows, well, allow the Macalope to just say 'Good luck with that.' in the most sarcastic tone he can muster.
The technical reasons may be different but the perception building in the public conscience is a simple one… your password is not always needed on a MacBook.
Honestly, while the tech press rightly throws a fit about these flaws (that's what we're here for), most Mac owners probably don't know anything about them. Heck, most people probably don't even know the effects of certain security features of macOS. How many Mac users know that if you don't have FileVault turned on, the resetpassword utility in Recovery mode will reset the password of any account without the need for verification? Probably not that many.
Come to think of it, taking Apple to task for inadequate education on such matters is probably a more valid criticism than saying 'Macs have bugs so don't buy Macs'.
On top of the native macOS errors, you also have to consider the impact of Meltdown and Spectre.
Which only effect Macs?
The fact that both of these vulnerabilities affect almost every single computing device currently on sale is not mentioned. Because we only gathered here today to lament the sorry state of the Mac.
…the long-term effect will be a likely slowing down across the macOS devices, and the potential for more damming exploits to be discovered.
Spence continually evaluates the Mac in a vacuum, as if its only competition is the Platonic idea of a laptop that exists in thought space and not reality.
The Mac family is not a cheap option.
No, it's not cheap. But not only do most cheap PCs come with Windows, they're also made of plastic and usually come with some kind of crapware installed. When you price high-end PCs against Macs, the prices are pretty comparable.
Again, yes, these bugs are bad things. There is no denying that. But it's not exactly like Apple's competitors are bug-free and, for most people, buying a computer is a technology purchasing decision, not a decision about whether to adopt an Amish lifestyle.
Running Mac OS X as a QEMU/KVM Guest
Gabriel L. Somlo
Last updated: Mon. Sep. 05, 2016Feedback to: somlo at cmu dot edu
0. I Just Want It Working, Right Now !
OK, here's what you'll need (or skip to the technical details instead):
- Development Tools: git, gcc[-c++], [auto]make, iasl, kernel-devel, etc. On Fedora,should take care of it. But, if following the rest of the directions below, you get weird build failures and other unexplained errors, consider the possibility that you're missing something in this category, possibly something I didn't think of listing explicitly above..
- KVM: As of kernel version 3.15, all necessary functionality is already integrated upstream. Right now, I have 3.15.3-200.fc20.x86_64 on my Fedora 20 machine, and everything works out of the box.For older kernels, it may be possible to build KVM kernel modules using the kvm-kmod 'wrapper', by following these instructions.Then, as root, while still in the kvm-kmod directory (substitute kvm_amd for kvm_intel, depending on your CPU):
- QEMU: Download QEMU 2.1.0 or later. This contains and installs an appropriately patched SeaBIOS binary as well, so there's no longer a need to download, build, and install a separate instance of SeaBIOS. Configure and build QEMU using something like:
- Chameleon: an additional bootloader is currently needed to bridge the gap between SeaBIOS and the Apple EFI BIOS expected by Mac OS X. Source is available from the project's SVN repo, but since it requires Mac OS X and Xcode to build, I've uploaded a binary image which you may use until you're ready to build your own.
OK, here's what you'll need (or skip to the technical details instead):
- Development Tools: git, gcc[-c++], [auto]make, iasl, kernel-devel, etc. On Fedora,should take care of it. But, if following the rest of the directions below, you get weird build failures and other unexplained errors, consider the possibility that you're missing something in this category, possibly something I didn't think of listing explicitly above..
- KVM: As of kernel version 3.15, all necessary functionality is already integrated upstream. Right now, I have 3.15.3-200.fc20.x86_64 on my Fedora 20 machine, and everything works out of the box.For older kernels, it may be possible to build KVM kernel modules using the kvm-kmod 'wrapper', by following these instructions.Then, as root, while still in the kvm-kmod directory (substitute kvm_amd for kvm_intel, depending on your CPU):
- QEMU: Download QEMU 2.1.0 or later. This contains and installs an appropriately patched SeaBIOS binary as well, so there's no longer a need to download, build, and install a separate instance of SeaBIOS. Configure and build QEMU using something like:
- Chameleon: an additional bootloader is currently needed to bridge the gap between SeaBIOS and the Apple EFI BIOS expected by Mac OS X. Source is available from the project's SVN repo, but since it requires Mac OS X and Xcode to build, I've uploaded a binary image which you may use until you're ready to build your own.
- You will need to supply the correct 64-character string as the argument of the osk='..' command line parameter above. This string is the concatenated result of two 32-bit keys, OSK0 and OSK1, which can be read from the AppleSMC chip shipping on genuine Apple machines. I wrote a small userspace program based on the Linux kernel applesmc driver, SmcDumpKey.c, which can be used (on a Mac running Linux) to query the SMC for various key values. For the full details, please see here.
- SnowLeopard (10.6), Lion (10.7), MountainLion (10.8) and Mavericks (10.9) can all be booted, with the following caveats:
- 10.6 and 10.7 require the 'idlehalt=0' kernel argument to be passed in (e.g., at the Chameleon 'boot:' prompt) to avoid using the unsupported MONITOR and MWAIT CPU instructions.
- 10.6 and early versions of 10.7 (somewhere prior to 10.7.5) will crash with a 'HPET not found' panic on a PIIX + SMP guest. This can be fixed with this patch, but since the problem only occurs on relatively early versions of OS X on the 'secondary' platform (PIIX, as opposed to the 'primary' Q35), I've decided to hold off on trying to upstream it for now.
- Early 10.8 (definitely 10.8.0) will hang during boot for unknown reasons. Using 10.8.5 boot media (DVD iso or installed HDD image) works fine.
- 10.9 'firstboot' (i.e., booting from a freshly installed HDD image for the first time) only works with SMP, for currently unknown reasons. Once the initial setup is complete, the HDD image can be booted on either SMP or uniprocessor guests.
- The main goal of this work is to get Mac OS X working with upstream KVM/QEMU/etc., so I'm mainly targeting these projects' git master branches. The patches I refer to may work against recently released versions, but please consider that as nothing more than a happy coincidence :)
1. Intro, Motivation, and Overview
This work started out as my OS Practicum project during the Fall of 2012, where I picked Mac OS X on QEMU/KVM as my topic. I'm a 'native' Linux user, but my IT department supports quite a few Mac OS X users, and I decided I could be much faster and more productive if I could access a Mac as a VM guest rather than dual-boot or cold-start an additional machine each time it was needed.The original work to enable OS X to run under QEMU/KVM was done by Alexander Graf. Additional kernel and userspace patches were contributed by René Rebe. Previously available patches and documentation I reviewed include:- René's patches at T2
- The by now really out of date Wiki instructions at
http://d4wiki.goddamm.it/index.php?title=Howto:_Mac_OSX_on_KVM
- KVM Kernel Module: at the lowest level, this component provides an in-kernel hardware assisted virtualization infrastructure.
- QEMU: userspace emulator which takes advantage of the hardware virtualization facilities provided by KVM to run a guest at nearly native hardware performance.
- SeaBIOS: default BIOS used with QEMU.
- Chameleon: a bootloader used to bridge the gap between SeaBIOS and the EFI-compatible BIOS shipping with Apple hardware.
2. KVM Kernel Module
KVM is the component located at the lowest level, providing an interface to the virtualization support offered by (among a few others) the x86_64 hardware architecture. Let's begin with a brief list of upstream resources:- Master git repo: git://git.kernel.org/pub/scm/virt/kvm/kvm.git
This is actually a full clone of the mainline kernel git repo, with KVM-specific commits added on top. Therefore, it is slightly less convenient to work with, although any attempts at commiting changes upstream must apply cleanly (and work correctly) against it. - Kmod 'wrapper': git://git.kiszka.org/kvm-kmod.git
This allows building KVM kernel modules against (and loadable into) a distro kernel (such as what ships on e.g., F18), as shown here.
3. QEMU
QEMU is a multi-architecture emulator running in user-space. For certain architectures (such as x86_64), QEMU is able to take advantage of hardware virtualization features offered through e.g. KVM, which allow it to run guests at near-native performance levels. Here is roughly how QEMU and KVM work together to implement a guest VM:- QEMU starts as a user-mode process, launching one thread for each VCPU that will be part of the guest VM. The guest system's 'physical' memory is allocated as part of the virtual address space of the QEMU process, and various handlers for the emulated virtual hardware of the guest systems are prepared.
- Each QEMU VCPU thread makes an ioctl() call into the kernel (where it will be serviced by KVM), requesting that the VCPU be scheduled on a pyhsical core. This ioctl() call will only return to userspace if/when KVM encounters a VM exit it can't handle itself. This typically involves a need for userspace emulation of specific guest hardware. Normally, when the userspace emulation is complete, the QEMU VCPU thread loops back to the spot where it calls into the kernel via the ioctl().
- KVM handles the kernel-side of the ioctl() call made by each QEMU VCPU thread. Normally, it causes the physical core on which the thread is scheduled to enter VM guest mode (a.k.a. L>1). Whenever a VM exit (back to host mode) occurs, KVM attempts to handle the exit cause itself, and immediately re-enters VM guest mode if successful. Otherwise, the VM exit reason is passed back to userspace by falling out of the ioctl() call, at which point QEMU must handle it as described above, before calling back into KVM again via the ioctl().
- Master git repo: git://git.qemu.org/qemu.git
3.1. The Q35/ICH9 architecture
Support for the Q35 architecture was recently (Dec. 2012) merged into QEMU mainline. Q35 replaces the old I440FX (a.k.a. PIIX) with Intel's more modern ICH9 chipset, which also happens to be used on most Intel-based Apple hardware. Among other hardware, ICH9 includes an integrated AHCI disk controller, which had to be added explicitly prior to the Q35 QEMU command line:As Q35 is slated to become the new default 'machine type' in QEMU in the near future, the bulk of the effort (development, debugging, and testing) to get Mac OS X supported under QEMU will be focused on this platform.3.1.1. Ethernet Link negotiation issues with e1000 on PIIX
Starting with MountainLion (OS X 10.8), the proprietary e1000 network driver built into OSX (AppleIntel8254XEthernet.kext) fails to detect network link unless special care is taken to move the network card to a separate hardware IRQ line from the AHCI/SATA controller. By default with the above command line (i.e. without using ',bus=pci.0,addr=5'), the network card will be placed in PCI slot 4, and will share IRQ11 with a bunch of other devices (e.g. AHCI/SATA, USB, etc). Moving it to PCI slot 5 causes it to use IRQ10 by itself, which is a sufficient workaround for the problem, at least for now.After some reverse engineering, it appears that the AppleIntel8254XEthernet.kext reads the e1000 ICR (Interrupt Cause Register) each time a PCI interrupt is detected. However, until e1000 initialization is complete, including the final configuration of the e1000 IMR (Interrupt Mask Register), any e1000 interrupts, including LSC (link state change) are ignored. The driver 'knows' it hasn't unmasked the interrupt yet, so while it reads the self-clearing ICR on hardware interrupt, it simply ignores the contents, which is then lost due to the register's reset-on-read behavior.Normally, the driver has enough time to finish setting up the mask register before a PCI interrupt is generated by the hardware when link autonegotiation is completed. However, by sharing a hardware IRQ line with the 'noisy' SATA controller, the hardware interrupt handler portion of the e1000 driver (which reads the ICR) is invoked early and often, before the mask setup is completed, leading to the asserted link state change interrupt being discarded before it can be acted upon.Moving the e1000 card to a new hardware IRQ line away from SATA (by forcing it into a custom PCI 'slot') solves the problem by not invoking the e1000 hardware interrupt handler before setup is complete. Another workaround (suggested by Alex Graf) is to delay reporting the LSC interrupt to the guest until the IMR (mask register) was configured. However, as pointed later in that thread, this patch may be problematic for guests wishing to poll the ICR without relying on hardware interrupts (by setting up a mask). Although mostly a theoretical issue at this point, this patch would significantly differ from expected hardware behavior.3.2. The AppleSMC emulator
The AppleSMC (or System Management Controller) is a chip specific to Intel-based computers manufactured by Apple. Its main purpose is to control (and report on) fan speeds, temperature sensors, screen and keyboard light intensity levels, and miscellaneous other power management features.From the point of view of the operating system driver, interaction with the SMC happens via port-based I/O: The name of a 4-character key is written to a control port, and the key's numeric or ASCII value is then read from (or written to) a data port. Keys typically represent fan speeds, light intensity levels, or temperatures.A pair of already upstreamed patches advertises the presence of the SMC in QEMU's ACPI/DSDT table, conditionally, based on whether or not it was specified on the QEMU command line.There are currently two outstanding issues with QEMU's AppleSMC emulation which could improve Mac OS X guest support, outlined below.3.2.1. Automatic OSK 'pass-through' on Apple hardware
The AppleSMC is also used to store a 64-byte ASCII string copyrighted by Apple, spread across two 32-byte key values, named OSK0 and OSK1. This string is used by Mac OS X to determine whether it's being booted on genuine Apple hardware. QEMU does not set up AppleSMC emulation by default (since only OS X guests require it at this time). To set it up, the following QEMU command line snippet is required:The user must supply the correct value of the 64-byte OSK string as an argument, and is responsible for honoring Apple's OS X EULA (which states that '[..] you are granted a [..] license to instal, use and run one (1) copy of the Apple Software on a single Apple-Branded computer at any one time').I wrote a small C program, SmcDumpKey.c, which can be used to read various SMC key values (including OSK0 and OSK1) from an Intel Mac running Linux. However, a significant improvement in usability and ease of compliance with the OS X EULA could be accomplished by allowing QEMU's AppleSMC emulator to automatically acquire the OSK strings from the underlying (Apple) host hardware.Currently, the drivers/hwmon/applesmc.c Linux driver populates a Sysfs directory (/sys/devices/platform/applesmc.768/) which offers access to most SMC key values. Unfortunately, that does not include OSK0 and OSK1. I submitted this patch against the applesmc.c Linux driver, but encountered two main objections (also see the various other replies in the referenced thread):- /sys/devices/platform/applesmc.768/ is (or should be) reserved for hardware-monitoring related keys and values only; This point seems to be contradicted by Documentation/sysfs-rules.txt in the Linux kernel sources, which states that each device should get its own node (directory) in a device tree, and does not recommend spreading any device's entries into separate spots across Sysfs by any sort of 'category'.
- The OSK values are constant, so it makes no sense to query the hardware if we know ahead of time what the returned value will be. My counter argument to that is that it makes perfect sense to query the hardware each time, precisely because Apple claims copyright on the returned string, which can therefore never be legally hardcoded (and distributed) in any open source project such as QEMU.
3.2.2. OS X fails to write a key value to the emulated SMC
During boot, Mac OS X will log a few non-fatal SMC-related errors:It appears that emulating a few extra SMC keys, as well as allowing the OS X guest to write (as opposed to just read) some of the supported keys might make these errors go away.3.3. The virtio-net virtual network card
A great alternative to using the default e1000 virtual network card (albeit one that requires post-install 'surgery' on the guest) appears to be using virtio-net instead (thanks George Yunaev and Warren Togami for pointing this out!). Start the guest with the following additional command line arguments:and install the 'aftermarket' virtio-net driver by Phil Jordan on the guest side. Since our guest does not have a network connection, download the driver on the host like so:and then start your guest with an additional FAT 'drive' mapped to the './VirtIoNetDrv/' download directory:Once the guest is up, install the driver via the usual method, and restart. A new Ethernet interface should become available, and should work from that point on with minimum fuss. Tested and confirmed working on OS X 10.8.5 and 10.9.*.Simon's Lament Mac Os Catalina
3.4. Boot OS X on QEMU without KVM hardware assistance
This now works (albeit very slowly, too slowly to be useful in practice), with the following (already upstreamed) patches:- OS X requires a software-emulated LAPIC version of 0x14 or higher;
- The software-emulated IOAPIC must ignore polarity bits set by the guest, matching the hardware-accelerated behavior of the KVM IOAPIC.
4. SeaBIOS
SeaBIOS is the default BIOS for QEMU/KVM. The QEMU source tree includes a sufficiently up-to-date snapshot of SeaBIOS (in pre-built, binary form).For reference only at this point, upstream resources include:- Master git repo: git://git.seabios.org/seabios.git
5. Chameleon
Chameleon is a Darwin/XNU boot loader based on Apple's boot-132. It is currently used to boot OS X on systems which do not contain Apple's EFI BIOS as expected. Project resources include:- Project home page: http://chameleon.osx86.hu/
- SVN repository: http://forge.voodooprojects.org/svn/chameleon
Simon's Lament Mac Os X
make' in the appropriate SVN subdirectory will build the entire project.The Chameleon stage-2 bootloader will be built as './sym/i386/boot'. On QEMU, we bypass all earlier stages by loading this binary as the default 'kernel' (via the '-kernel chameleon_svn2783_boot' command line argument). On a (U)EFI compliant machine, in theory, (U)EFI would find a file named '/System/Library/CoreServices/boot.efi' on the OS X partition and use it directly. Chameleon's stage-2 'boot' file is a roughly equivalent replacement for that.Chameleon offers a range of additional 'bells and whistles', such as the ability to load alternative and/or additional .kext modules (OS X kernel drivers), and replace the system's default ACPI DSDT, mostly intended for 'hackintosh' systems. On QEMU, however, the idea is to offer a DSDT and virtualized 'hardware' that's close enough for OS X to run on, without needing that type of 'assistance' from the bootloader.An example Chameleon configuration (create a new file under /Extra/org.chameleon.boot.plist) is shown below. The example configures Chameleon to automatically enter the first encountered OS X partition after a 5-second wait. It also forces the guest video settings to 1280x1024 pixels, 32-bit color depth (which is something that currently can't be done from *within* the guest's display settings, for reasons I'm still investigating). Thanks to Andrei Ostanin, Christian Simon, and Warren Togami!In the long term, it might be possible to use a QEMU-compatible UEFI BIOS instead of SeaBIOS, and have it boot into OS X using the original /System/Library/CoreServices/boot.efiSimon's Lament Mac Os 11
Apple-provided bootloader.Simon's Lament Mac Os Download
6. Conclusion and Future Work
My ultimate goal is to upstream whatever changes are needed to KVM/QEMU/SeaBIOS/Chameleon/etc., to allow installing and running OS X from unadulterated, standard images. I plan to keep this document updated with the current list of outstanding issues. Eventually, the idea is for this document to 'melt away' as all these issues are addressed, and all patches are accepted into their respective upstream projects.I appreciate any ideas, comments, and feedback. Please email me at somlo at cmu dot edu with any questions, comments, and suggestions.