Qubes 3 MacOSX

[Drew White]

Hi folks,


I recently have been trying to get MacOSX onto this machine, Qubes 3, and it's not accepting.

On boot it keeps telling me there is a fault in CPU 0 and just errors out and doesn't go past there.

What do I do to fix this?

I have looked at all the options available, researched it for a long time and it doesn't resolve the issue at all.

Sincerely,
Drew.

[Jeremias E.]

Which version of Mac OS X?

[Drew White]

10.6.3

10.7

Both what it is said is compatible.

[Vít Šesták]

Do you want a dualboot, or MacOS in a VM?

If you want MacOS in a VM, then I am afraid it is AFAIK not supported at all.

If you want a dualboot, then it should theoretically work, but dualboot lowers security of Qubes.

Regards,
Vít Šesták 'v6ak'

[Drew White]

I only know that it can do it because of what I had read in the documents and interviews with the Qubes Head.

I want MacOSX in a VM, why would I want it on the hardware when I have Qubes on the hardware?

[Eric Shelton]

On Tuesday, August 11, 2015 at 6:03:59 AM UTC-4, Drew White wrote:

I only know that it can do it because of what I had read in the documents and interviews with the Qubes Head.

I want MacOSX in a VM, why would I want it on the hardware when I have Qubes on the hardware?

I had an earlier post on this, but below I will go into some more details.

https://groups.google.com/forum/#!msg/qubes-users/AFfylQOYQ8g/wuLweuF8FC0J

A patch to the Xen hypervisor is required to get past the CPU fault.  The patch adds support for an undocumented MSR 0x35, which the OS X kernel makes use of to determine the number of cores, etc.  Xen's default behavior is to return zero for this MSR, which eventually segfaults the kernel.

http://lists.xen.org/archives/html/xen-devel/2014-09/msg02524.html

A second patch to the hypervisor is required if your computer is running a Haswell (or above?) CPU, to get OS X to work with Xen's TSC emulation.  Basically, the patch emulates/implements a few of VMware's CPUID hypervisor leaves.  Without this patch, OS X will manage to boot up, but not for long.

http://lists.xen.org/archives/html/xen-devel/2014-09/msg02525.html

(this one is not perfect, as at the time I did not realize at the time that the emulated TSC ran at 1 GHz - fixing it is an exercise for the reader)

You will have to (1) sort out how to run the qubes build stuff (runs easily enough in an appvm), (2) rework the patches to apply cleanly against Xen 4.4.2, (3) rebuild the vmm-xen packages, and (4) install them in dom0.

Then, to get OS X to install in an HVM domain, you will have to follow the work of the Hackintosh community, in order to boot in a non-EFI environment, have SMC emulation, etc.  Plus, on the Qubes side, you will need to run a custom .conf file, because you will need to override some of the CPUID values as well - see:

http://comments.gmane.org/gmane.comp.emulators.xen.devel/168789

Running OS X 10.9 and above introduces another set of problems, as it there was a change regarding EFI boot.  I think perhaps the Hackintosh folks worked out updating Chameleon or such to boot on non-EFI systems.

My experience with doing all of this?  OS X will install in a Qubes HVM, but it is not quite stable - QEMU eventually hangs.  I attribute this to the version of QEMU being run within stub domains being hopelessly ancient.  However, running QEMU in a stub domain means that Qubes has not been susceptible to the recent run of QEMU-related Xen vulnerabilities - an excellent design decision by the Qubes team.  OS X does appear to run stably under newer QEMU versions (see KVM or non-Qubes Xen's qemu-upstream).  I think the main Xen team is on the cusp of getting upstream QEMU running in stub domains using rump kernel - my hunch is that it will be an experimental Xen 4.7 feature (note - Xen 4.6 is on the threshold of hitting rc1, so we're probably looking at a year from now).

tl;dr - You can patch up Xen to get OS X to boot, but it probably won't be stable.  However, if you're the enterprising type, maybe you can figure out what causes QEMU to eventually hang while running OS X.  Otherwise, you will have to just keep waiting until the Xen project gets qemu-upstream stub domains running with rump kernel.

Best,

Eric

[Eric Shelton]

On Tuesday, August 11, 2015 at 8:47:08 PM UTC-4, Eric Shelton wrote:

A patch to the Xen hypervisor is required to get past the CPU fault.  The patch adds support for an undocumented MSR 0x35, which the OS X kernel makes use of to determine the number of cores, etc.  Xen's default behavior is to return zero for this MSR, which eventually segfaults the kernel.

A second patch to the hypervisor is required if your computer is running a Haswell (or above?) CPU, to get OS X to work with Xen's TSC emulation.  Basically, the patch emulates/implements a few of VMware's CPUID hypervisor leaves.  Without this patch, OS X will manage to boot up, but not for long.

There was a mistake in the previously posted patch, plus it was incomplete, so I deleted my previous post.  With the attached patch, using the attached appvm config file, it is possible to boot up an OS X 10.9 installer using the Chameleon bootloader on a Haswell system.  However, the mouse will not work - OS X does not like the USB tablet used by Qubes.  Further work is required to get things to where OS X can be installed and used.  However, the patch gets you past the crashes you would experience with the stock Xen hypervisor.

Eric

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Is the patch going to the upstream Xen? Or maybe its even already there
and here it is a backport? I think it worth trying to get it included
there.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV5DflAAoJENuP0xzK19csrZkIAJNxKkPw6bTOCE+zOfBiM6mD
V+DpiQRTLRkDWSji4lI3a9sA1NuuJkbtTQurS08fFLt4VIaJsIzBw31PJjghQxDW
j6QzPtSzemF9fVLtNRSQLY0psdSG1fYUn4so38ohhw5Dfjozor3tlzLi2CoKynkh
WPHOkgCicrZ/REuvjaCQK+LGdgD/gVba18XGC9NLy2oDtCUC8JK1ysNgoemM2b83
sFGJ5XH1gFPPav39cPeNlyp3Q45g+NXuAeOKik/Fx2IoDFY1AWFD5/YRQpEXD17G
WgMPnFNJAQHwIxNv9Ht0nR0zXaUBXmJZ8mRqU6h+kVbEiAw0VfehdWWw0lvm/PU=
=IyiQ
-----END PGP SIGNATURE-----

[Eric Shelton]

Although I supplied it as a single patch, there are three parts, each with a different status:

1) Add MSR 0x35.  I tried upstreaming this about a year ago, but the Xen team was unwilling at that time to add an MSR that apparently is not officially documented by Intel.  I have a request for info outstanding with some kind folks at Intel, but nothing has come up yet.

2) Add VMware CPUID leaf 0x40000010.  The same thing is included as part of Don Slutz's patches for adding VMware tools support.  It looks like those patches are done or nearly done, but he just barely missed the feature freeze for Xen 4.6.

3) Report correct number of CPUs in CPUID leaves 1 and 4.  I had previously been doing this by overriding the CPUID values via an xl.cfg file.  Since this was no longer an option under libvirt, I did the same thing directly in the hypervisor.  I will try upstreaming after Xen 4.6 release activities settle down.  Hopefully the change will be acceptable, although I am guessing there may be some issue with hotplugging CPUs that led to these leaves reporting 32 CPUs in the first place.

The difficulty with getting items 1 and 3 upstreamed is that only OS X appears to rely on these, or at least to an extent that OS X will crash if they are not consistent with the number of VCPUs.  The perspective of the Xen team generally seems to be that the OS X kernel is acting in a nonstandard manner (such as using an undocumented MSR), and that the Xen hypervisor should not be modified to accommodate OS X's quirks.

Eric

[Drew White]

So how is it that I apply this patch?
Is there something in qubes to tell it to load this .patch file?

I am hoping that this cure does actually work, if it does then that would be great. But could you please explain each line of code and what it does to the system please?

[Eric Shelton]

After some more work, I can now report that I have successfully installed and run OS X 10.10.5 (the latest non-beta version) in an HVM stubdom.  I have attached the files I used to get Qubes to get it to work.  The hardest part will be stage 1 below, as it requires you to rebuild the Xen hypervisor and install the updated RPMs in dom0.  At this moment, I am not going to go into all of the details required to do that, as I would rather document the things specific to getting OS X to get up and running happily.  Please note this was done on a Haswell system - I do not know if more recent processors will present a new host of issues, like Haswell did over previous generations.

Stage 1 -  rebuild the Xen hypervisor to allow Darwin kernel to boot and improve RTL 8139 emulation:

1. Set up an appvm for building Qubes R3.  https://www.qubes-os.org/doc/QubesR3Building/ is likely to be of some help.

2. In the configured qubes-builder directory, run 'make get-sources'

3. Copy the attached two .patch files to qubes-src/vmm-xen/patches.misc

4. Add the following two lines to qubes-src/vmm-xen/series.conf"

patches.misc/xen-osx.patch

patches.misc/qemu-rtl8139-backports.patch

5. Run 'make vmm-xen'.  This will take a little while

6. Copy the following two files to dom0 (see https://www.qubes-os.org/doc/CopyToDomZero/):

qubes-src/vmm-xen/pkgs/fc20/x86_64/xen-hvm-4.4.2gui3.0.0-6.fc20.x86_64.rpm

qubes-src/vmm-xen/pkgs/fc20/x86_64/xen-hypervisor-4.4.2-6.fc20.x86_64.rpm

7. In dom0, run 'sudo yum reinstall ./xen-h*rpm' wherever you copied the above RPMs into dom0.

8.  Reboot.  On to stage 2.

Stage 2 - installing OS X into an appvm:

1. Set up a USB drive to install OS X (at least 8GB stick).  There are many ways to go about this.  However, you have to use a Hackintosh-style method, because, if nothing else, a Qubes HVM domain does not do EFI boot (which stock OS X requires).  What worked for me is shown at http://www.tonymacx86.com/yosemite-desktop-guides/143976-unibeast-install-os-x-yosemite-any-supported-intel-based-pc.html  This is easy enough to do on a Mac that you have set up to dual boot Qubes and OS X.

2. There are several kexts that are required for OS X to boot with the virtual devices provided by QEMU.  If you used the UniBeast method above, or any other Chameleon-based approach, you copy the kexts into the /Extra/Extensions folder on the USB drive.  The kexts you need to track down are:

AppleIntelPIIXATA2.kext (very, VERY important)

PCGenRTL8139Ethernet.kext (version 1.4.1 is available somewhere)

FakeSMC.kext

NullCPUPowerManagement.kext

Other kexts I had, but may not be needed, are:

AppleACPIPS2Nub.kext

AppleACPIPlatform.kext

ApplePS2Controller.kext

EvOreboot.kext

3.  Copy the following onto the USB as well, as this gets the mouse working at the end of everything:

http://philjordan.eu/osx-virt/binaries/QemuUSBTablet-1.1.pkg (found via http://philjordan.eu/osx-virt/)

4.  Using Qubes Manager, create an HVM-based appvm (no less than 20 GB disk space).  The examples and attachments assume the appvm is named 'osx'.  They also assume your USB stick comes up as /dev/sdb.  You will need to update them to match anything different about these on your system.

5.  Copy the other two attachments (osx-upstream.cfg and myosx.conf) into /var/lib/qubes/appvms/osx.  Revise them as noted above, if needed.  One of the revisions might include providing less than 4GB of memory.  Update the attached files with the MAC address and IP address assigned to your appvm.

6.  QEMU upstream has to be used for the initial phases of the install, as that is the only way to get the mouse to work.  To do this, in /var/lib/qubes/appvms/osx, repeatedly run 'sudo xl set-mem dom0 1500' and 'sudo xl -vvv create osx-upstream.cfg' until the HVM domain starts up.  You may have to modify the 1500 value and the amount of memory assigned in osx-upstream.cfg toi work with the amount of memory available of your system.  You probably can dial the memory in osx-upstream.cfg down to 2048, I would guess.

7.  When the HVM window pops up, IMMEDIATELY hit F12 (you won't have much time).  Choose the USB drive (in the attached .cfg file, this would be drive 2).  Assuming you are doing the above UniBeast method, you then simply choose to boot from the USB drive.  It may take a few minutes, but you should end up at the OS X installer.  If it fails before it gets there, you should add '-v -f debug=0x14c' to the Darwin boot arguments (for Chameleon, see the file /Extra/org.chameleon.Boot.plist, and put this into the value for "Kernel Flags"; while there, you might also set "Graphics Mode" to "1440x900x24" or such).  The 'debug=0x14c' portion gets the OS X kernel to log output via the serial port, which you can review in /var/log/xen/console/guest-osx-dm.log

8.  Install OS X to the virtual hard drive.  Reboot.

9.  Do the  'sudo xl set-mem dom0 1500' and 'sudo xl -vvv create osx-upstream.cfg' thing to bring up OS X again.  This time, tell Chameleon to boot from the hard drive, instead of the install USB.  You will then run through the final part of the OS X installer.  When it asked you about the network adapter, choose manual config, and input the values for the appvm.  It will not find the network, because there is no network in qemu-upstream, but this gets it ready for running in the stubdom HVM.

10.  Once OS X finished coming up, run QemuUSBTablet-1.1.pkg you copied to the USB drive.  This installs the necessary driver for the mouse in the stubdom.  Shut down OS X - we should never need to go back to qemu-upstream now.

11.  Run 'qvm-run osx --custom-config myosx.conf'  Use Chameleon on the USB stick to boot into the hard drive again.  Everything should now work.  The display is going to be a little sluggish, given that QEMU provides an emulated SVGA adapter, and OSX is tailored to running in a full-blown GPU.  You probably want to investigate how to take the USB stick out of the loop by installing Chameleon to your virtual hard drive.  The above link for setting up the install USB talks about using a program called Multibeast to do this.  There are other methods.

There are some quirks with the mouse support - not everything seems to register single clicks quite right or with a single click.  A workaround for this is to use OS X's built-in VNC support, under System Preferences->Sharing->Screen Sharing.  Note that getting the OS X appvm network to communicate with another appvm running vncviewer has its own set of hoops to jump through (see the section "Enabling networking between two AppVMs" at https://www.qubes-os.org/doc/QubesFirewall/)

The above steps are not simple, but I can say that they worked for me.  If something doesn't work, you will probably have to roll up your sleeves and exercise your Google search-fu to identify a solution.  Some additional steps are likely needed to get all of the OS X features running (there is a fair chance the App Store will not work without certain SMBIOS values being provided).  Some programs may never work under QEMU (the maps program does not seem to).  An OS X appvm may be a good candidate for GPU passthrough, although I have not heard any reports on this.

Best of luck for those who wish to go down this road...

Eric

[Eric Shelton]

As an update, I have had some success lately getting the El Capitan GM Candidate running using the following bootloader:

http://www.insanelymac.com/forum/topic/306960-chameleon-os-x-el-capitan/

I just used the default config, using the desktop SMBIOS.  The only extensions you need to add top /Extra/Extensions are AppleIntelPIIXATA2.kext and PCGenRTL8139Ethernet.kext.  For kernel boot arguments (see /Extra/org.chameleon.Boot.plist is the USB stick you create), I used "-v -f debug=0x14c maxmem=4096 darkwake=0 dart=0 PCIRootUID=1" (adjust maxmem according to your setup).  This should get the installer up and running.  On subsequent boots from the OS drive, I have found the "Boot Ignore Caches" option necessary.

Also, the QEMU tablet driver I noted above, which did not work very well with Yosemite, does not work at all with EL Capitan.  Instead, you should use the driver available from here, which appears to work almost perfectly (with exception of goofiness with dragging on 1.0 driver pkg):

https://github.com/SipRadius/Qemu-USB-Tablet-Driver

http://www.chui-pas.net/qemu/Qemu-Tablet-Driver-v1.0.pkg (download package from here - I don't think this has the drag fix, so dragging is a little unusual, and does not work for everything).

Presumably, this will work just as well with the final release version at the end of the month.  So now, Mac users can run Qubes, but not have to leave Qubes and do dual boot to still run OS X.

Eric

[john.app...@gmail.com]

Hey Eric, are you running Qubes off a Mac? If so, which model?

[amarnat...@gmail.com]

Will this process work on a normal PC?

Thanks for the time.

[Drew White]

Yes it will, as long as you can build qubes from the ground up.

Just follow the instructions and it should be operational for you, depending on hardware compatibility.
So I'd say you can try, but I won't guarantee you have identical hardware to me.

[fad...@gmail.com]

I have long been interested in this OS topology:

(top) Windows OSX
(bottom) Linux

From what I've read it sounds like it should be posible to achieve:
(top) Windows OSX Linux
(bottom) Qubes

Am I getting this right? Additionally, what if I had a passthrough GPU for each OS? Have people gotten NVIDIA working reliably, or should I plan that the GPUs be ATI?

Thanks!

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


El 31/12/15 a las 06:04, fad...@gmail.com escribió:

> I have long been interested in this OS topology:
>
> (top) Windows OSX (bottom) Linux
>
> From what I've read it sounds like it should be posible to
> achieve: (top) Windows OSX Linux (bottom) Qubes
>
> Am I getting this right? Additionally, what if I had a passthrough
> GPU for each OS? Have people gotten NVIDIA working reliably, or
> should I plan that the GPUs be ATI?
>
> Thanks!
>

I am not sure what you mean but Qubes should run on real hardware.
Then you can run Linux or Windows 7. I have no idea about OSX :\

GPU passthrough is very unstable, I don't know if it's possible, Xen
has few PCI/GPU passthrough compatibility compared to KVM.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWhOrEAAoJEBQTENjj7QilG6QQALr5OCxUZfkj/8h6qXNISnxS
qbLSB6q3jx50QaZNAABV2T76K2ZfB/+Smo1WQorGNr26lTiPasO0RrBzfLBx4XIB
urudFCxuQmOJWERtHYky7VHbI1PHsEm9i2LdmZe2CQYkaIEh3u8i5wX3KcqTV0/l
kZoO45ErvBhaUgTRssZf5Vj6iHXsh8VZPBMvasu3X/yXgM0LSGDym+oWcN4bKJ68
xwS6xepVeL9ASKpkHLRxkcY2WXVU/Rc6nt4iVEizM0e4j38q6+JxzWLh6hLado3q
UMwdT6XOSAPpXermg1kyFiDLZ2vChRciTXb5b2qdr4IPv3ZDmWNFTbpo0z7vb4FA
xIZvNij4nmy8KCYFe679nr72LzbLW4ThOGud+wCp/6leEGAguKPVupb2JndGqdJs
CSnJJyRUI8kzRc0KN6jq2Tq/N2jDWq+kXfrtKMmQ3/z/wdhubdkkm37tGGFFmTs+
H+vCjQGPGWlHpDKCUyW0i1F6OIlt/8jbKhlNzjdzwv0jRphqk6agc1VKydaSYTRH
+KVRbW+SL2SoqLwmtxQTs3xFOLBlcmu2hDdf6boS4r8JnIbDFwuHMBfuHd5gSqAv
HZ8y1lE5xioM3oamNdteafzUUUnQART/QTKqSqDra1PVWG6/ENHTwCQAqJMwe9xs
HBBN4THsnz0matO5ppLC
=c7+p
-----END PGP SIGNATURE-----

[Drew White]

Jacob,

Yes, that is what this whole topic was about, getting MacOSX to run under Qubes.

It already does Windows and Linux just fine. (only Fedora and Debian though, and some newer versions at the time.)

The patches were to get MacOSX to work.

As for the topology, having Qubes on the PC, then running everything underneath is the way it's meant to be run.

For GPU passthru, yes, it is doable and will work, DEPENDING on your video card and chipset.

[logan....@gmail.com]

> Presumably, this will work just as well with the final release version at the end of the month.  So now, Mac users can run Qubes, but not have to leave Qubes and do dual boot to still run OS X.
>
>
> Eric

Can anyone comment on getting this to work in Qubes 3.1?

-Logan

[Drew White]

On Friday, 11 March 2016 04:35:08 UTC+11, logan....@gmail.com wrote:

Can anyone comment on getting this to work in Qubes 3.1?

-Logan

Has anyone managed to advance further in this endeavour?

In 3.1 they fixed the Windows Tools issues, but has OSX support been added in?

It would be most beneficial for it to be. Many people would use MacOSX under Qubes if they could.

I've asked many people, and to be able to use Qubes and have Windows, Linux, and OSX side by side on the one or multiple screens on the one machine, most beneficial. ESPECIALLY for developers.

Any chance that it could be made an official patch?

[Drew White]

Why is there still no MacOSX patch on Qubes permanently?
The patch was provided here for Qubes 3, but it wasn't put into the development after someone went to all the trouble of making it?

Can you please get MacOSX to be able to work in Qubes?
AND with the Tools for Seamless available too please? (Since it is Unix Based.)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Based on skimming this thread, it sounds like a fair amount of work is
still needed to get this into Qubes. Given that developer time is
extremely limited and currently devoted to the tasks on our road map,
it sounds like developers from the community would have to help with
that extra work in order for this to happen.

I think the best way to help make this happen is to make things as
easy as possible for the core devs by submitting pull requests
containing thoroughly-tested code which follows Qubes' coding style:
https://www.qubes-os.org/doc/coding-style/

Tracking this here:

https://github.com/QubesOS/qubes-issues/issues/1982

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXMtSGAAoJENtN07w5UDAwxaMQAIacOv3mJEY0d+1Kh0mknAA4
XcpeMOMtFYBKhhRP+MmMJHVe9+iifU5SgXemtRyM09FuBtRpwAsjoer93HOW6X/X
QmO6pK59KJXjJDfQgLA58IuK5IQmTXumhzlYqv3g9rhE0vVoDMCJxC4ZV/D9M7+F
MSnyYtqOYu1udU93pHZqVfbBJAtDfqV8/KLguhTuXC50cp6jZ6qsdBqsq744hFCA
t9Vo9iwWnP/GspnP2GNCyYyYz9WXoi/UtchDFzyGw1l23IJon8LK12EJrC/9/ZPv
HR16C/2uixz0CxhRdt/LgFIJylwcXZ2jwRTZ09eH2uX1mX6KDhj5S35L9Yu2Hx2K
EzexkS31TGhzCZXKfI3D9Lyr3IvpZyQZSLJMPlh/z1l+MPE8+fElIBjy9uLjTzjg
usZP8vLmh9u7Dz8JEIFneUT1PpdpqLgwaCzAjf+P0j1XAscWBlPd+ViZbdGYOtqd
hN3R0gSsS0BetPvhOIWE1CPb3yV4d0aL1luqBPg2CsAEV3HsR8kag4z/2vukKpRs
JoXpFqObjbsUa1CAw5O8spDIq7DMJCwFnAZkKvgx3TgaDPwpJNC7v1k7/57SMj2I
A6N5AfCAxxxD+FTgemRO58lv9WfbVcjooxaMhfd38Vqzo1HwvVR+3eYAIq58ybSI
jTotBLxHLOJ2B0WPByLS
=aTb7
-----END PGP SIGNATURE-----

[Achim Patzner]

> Am 11.05.2016 um 07:42 schrieb Drew White <drew....@gmail.com>:
>
> Why is there still no MacOSX patch on Qubes permanently?

Because supporting the masses in breaking licensing agreements is just not the way to do things.

> Can you please get MacOSX to be able to work in Qubes?

Does anyone remember the one short-lived version VMware Workstation where VMware removed the restriction of only booting Mac OS X server? It took them about two weeks to have a regiment of Apple’s lawyers at their door. I don’t see a good reason to invest a massive amount of time for a special case that could be used only in Qubes running on Apple hardware for running properly licensed Mac OS X with Mac OS X Server installed.

> AND with the Tools for Seamless available too please? (Since it is Unix Based.)

Even you should know that this will take quite a lot of (interesting) work as Mac OS X is not based on any technology anyone else is providing right now. But you’re welcome to try.


Achim

[Drew White]

On Thursday, 12 May 2016 22:34:47 UTC+10, Achim Patzner wrote:

> Am 11.05.2016 um 07:42 schrieb Drew White <drew....@gmail.com>:
>
> Why is there still no MacOSX patch on Qubes permanently?

Because supporting the masses in breaking licensing agreements is just not the way to do things.

I own a Mac, but I want to use it under Qubes instead of having to use multiple PCs. It's not breaking
the agreement with them since I own a Mac and have Mac OSX.
 

> Can you please get MacOSX to be able to work in Qubes?

Does anyone remember the one short-lived version VMware Workstation where VMware removed the restriction of only booting Mac OS X server? It took them about two weeks to have a regiment of Apple’s lawyers at their door. I don’t see a good reason to invest a massive amount of time for a special case that could be used only in Qubes running on Apple hardware for running properly licensed Mac OS X with Mac OS X Server installed.

I used to use Hackintosh to get Mac running under VMWare. But after that stopped working, I couldn't.

 

> AND with the Tools for Seamless available too please? (Since it is Unix Based.)

Even you should know that this will take quite a lot of (interesting) work as Mac OS X is not based on any technology anyone else is providing right now. But you’re welcome to try.

Well, it MAY take a lot of work, but since it's a Unix operating system, there should already be a base
for it, just not compiled into the native language.


At the moment I'm putting Android under Qubes. Can't use tools though, because that would defeat the
purpose of having Android there to emulate different screen resolutions and densities.

But as for MacOSX, it would be a great advantage.

[Achim Patzner]

> Am 13.05.2016 um 02:24 schrieb Drew White <drew....@gmail.com>:
> I own a Mac, but I want to use it under Qubes instead of having to use multiple PCs. It's not breaking
> the agreement with them since I own a Mac and have Mac OSX.

You do if it is not running a server variant.

How many users are running Qubes on Apple hardware? Is it really worth spending scarce development resources on them? Wouldn’t it be better to use them to get dom0 to current OS levels? That would be supporting more users.

> I used to use Hackintosh to get Mac running under VMWare. But after that stopped working, I couldn’t.

So much about sticking to licensing terms…

>> > AND with the Tools for Seamless available too please? (Since it is Unix Based.)
>>
>> Even you should know that this will take quite a lot of (interesting) work as Mac OS X is not based on any technology anyone else is providing right now. But you’re welcome to try.
>>
> Well, it MAY take a lot of work, but since it's a Unix operating system, there should already be a base
> for it, just not compiled into the native language.

Sorry, but I’ve got the distinct feeling that you don’t know what you’re talking about here. Quartz was never intended to be able to this so there are no interfaces to that level inside the protocol. If you want to have access to an application’s windows you will have to dig quite deeply inside the entire Quartz.

Ask the Dropbox programmers what they had to do to get access to Finder’s icons if you want to write that kind of software. It will be quite educational to try implementing it.

> But as for MacOSX, it would be a great advantage.

Only for the less than 1%.


Achim

[Jacob Gadikian]

It is truly your operating system's "killer app".

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/RiVntUzgJmY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7FA2F77E-E32E-4BAC-B756-214A530E0522%40noses.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Rand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/12/2016 07:34 AM, Achim Patzner wrote:
>> Am 11.05.2016 um 07:42 schrieb Drew White
>> <drew....@gmail.com>:
>>
>> Why is there still no MacOSX patch on Qubes permanently?
>
> Because supporting the masses in breaking licensing agreements is
> just not the way to do things.

FWIW, I think a legal argument could be made that such license
agreements are anti-competitive and therefore unenforceable. However,
I am unaware of any specific precedent for this argument, so it would
indeed probably be unwise for ITL to violate the license agreement
unless their goal is to win the inevitable lawsuit and thus achieve a
beneficial precedent. (And while that would be laudable, I would
definitely not blame ITL if they decided that such activities are not
worth their effort or budget.)

(And of course, I'm not a lawyer.)

Cheers,
- -Jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXN/WOAAoJEAHN/EbZ1y06fM4QAJo1EOPnOnh82e4b+NJYjCKl
HgG4ONodLeLPnvZgJrgpOt2JQ0ODgtT/Gjd+wQu12tI2sHQsAaXm/TGqHuX5Eitb
Jtn/dbPBpml1m6ysEUQhlsjIE3ROwmFtIs8moru9KEZI79JF4hm49J+yHhfLITG3
Gw98NtYiE6yrjyKp1fW+EevLNWlwxu4DpeM94SnoapLo4Kw7KNaIh2g2UFpvHyaR
kvt+PsK3G/UE/gGw0tNmYyv0KnyEs+0nMRwIt4sT2qv1TWogJCP5PlAvUuQNG2W6
X11uwP4/etTWu9c0JpZYtFOy0oXejkeORbbeB85jQx9TL+u96Sz7iKjgIZkSRPUB
Cyp76E8pKcg5SwPGyvgmEVskus4OfvqK6K0F5dHsR4D76SFfu3fWzu3BvzAljy1M
QsCbLBeBAw9ebQp6ykCwmIB+DyMHMnJrVZuJ/hpzv+8c4QG6ZWbLW9Z2AtF6w9kw
aGb5mrpSBbpBF6Fe+lz8rEzIgnPuBl/pZ1m3DCM+LPqXcXOgbzC+Sy7c7MbFelj5
QULDRPzzPExpwSDybJTOYrmELKa26CDDSsjSaipX70CV4vht3FC4dw/HOspWh6Xn
E4pASVnpM20Fdo8lULFuGIO7xw+v37pEjlae50DBnHI7gv2lSxqiuOD4HNdyLk8+
Whtba2OtsmLdA9ZlxP+l
=wmAz
-----END PGP SIGNATURE-----

[Drew White]

On Sunday, 15 May 2016 14:05:50 UTC+10, Jeremy Rand wrote:

FWIW, I think a legal argument could be made that such license
agreements are anti-competitive and therefore unenforceable.  However,
I am unaware of any specific precedent for this argument, so it would
indeed probably be unwise for ITL to violate the license agreement
unless their goal is to win the inevitable lawsuit and thus achieve a
beneficial precedent.  (And while that would be laudable, I would
definitely not blame ITL if they decided that such activities are not
worth their effort or budget.)

(And of course, I'm not a lawyer.)

Well, in the end, I own a mac, It's not breaking any agreement or anything for me wanting to run it.
All that the qubes-os developers are doing is putting the availability for those that have a MAC and want to run one piece of hardware instead of 4 to do so without an issue.
There is no infringment on any agreement or lisencing there or anything because they would already own a Mac.

If people decide to use it for the wrong purposes, then that is not the fault of Qubes-OS. Qubes-OS and developers should not be the judge, jury, and executioner for this.
We can run Windows on a Mac if we have Qubes on the Mac, so why not the other way around?

For Windows people use Illegal Lisence Keys and cracks and all, but that is THEIR issue, not the manufacturer of the hardware.
The patch for Qubes 3.0 would work fine, jsut have to put it into 3.1 / 4.0 and get it working again.

I own a Mac, I want to run MacOSX on Qubes on my PC which is much much more powerful than my Mac. And that way I could also have multiples.
I could have one that I use for this, one for that, and another for another.
I own a Mac, I want to run OSX, I want to run it under Qubes. I'm not doing anything wrong.
If people choose to do it wrong, then that is their fault, not Qubes. Qubes wouldn't be saying that people can use it to have MacOSX if they don't have a Mac, but you would just be allowing those that have a Mac to run OSX on their PC.
You are not responsible for those that do things illegally.

Please, add it in and get it working, it would be most beneficial to have a SECURE operating system for OSX as well as windows and other variants of Unix.

[Achim Patzner]

Am 17.06.2016 um 06:11 schrieb Drew White:
> Well, in the end, I own a mac, It's not breaking any agreement or
> anything for me wanting to run it.

You didn't read the license very well, then. Depending on the version of
Mac OS X you bought as part of your machine there are several
restrictions (including only running server versions and only running it
on genuine Apple hardware) on the use of the software you licensed.

> All that the qubes-os developers are doing is putting the availability
> for those that have a MAC and want to run one piece of hardware
> instead of 4 to do so without an issue.

_could_ be doing.

> If people decide to use it for the wrong purposes, then that is not
> the fault of Qubes-OS. Qubes-OS and developers should not be the
> judge, jury, and executioner for this.

The Qubes developers should have the right to decide that for themselves.

> The patch for Qubes 3.0 would work fine, jsut have to put it into 3.1
> / 4.0 and get it working again.

If you belive this is a good idea why don't you spend your time on doing it?

> I own a Mac, I want to run MacOSX on Qubes on my PC which is much much
> more powerful than my Mac. And that way I could also have multiples.

You know that you really start sounding like a spoilt child? If this is
so important to do, implement it, publish it on the repository and
mantain the code across Qubes versions. Do the work or pay for it.


Achim

[ni...@kobschaetzki.net]

> On June 17, 2016 at 11:47 AM Achim Patzner <no...@noses.com> wrote:
>
>
> Am 17.06.2016 um 06:11 schrieb Drew White:
> > Well, in the end, I own a mac, It's not breaking any agreement or
> > anything for me wanting to run it.
>
> You didn't read the license very well, then. Depending on the version of
> Mac OS X you bought as part of your machine there are several
> restrictions (including only running server versions and only running it
> on genuine Apple hardware) on the use of the software you licensed.

Actually if he updates his iMac regularly it depends on the version installed. And 10.10 is allowed to be virtualized (10.7 and up is client and server; 10.5 and .6 only server - since for some versions the server is only an extension of the client via an AppStore-App anything else wouldn't make sense)

> > All that the qubes-os developers are doing is putting the availability
> > for those that have a MAC and want to run one piece of hardware
> > instead of 4 to do so without an issue.
>
> _could_ be doing.
>
> > If people decide to use it for the wrong purposes, then that is not
> > the fault of Qubes-OS. Qubes-OS and developers should not be the
> > judge, jury, and executioner for this.
>
> The Qubes developers should have the right to decide that for themselves.

Yep, priorities and such.

> > The patch for Qubes 3.0 would work fine, jsut have to put it into 3.1
> > / 4.0 and get it working again.
>
> If you belive this is a good idea why don't you spend your time on doing it?

Because not everyone is able to code, test code and build an operating system and would need a lot of work by the user to get to a level to include an appropriate patch (sorry, I don't know what exactly the patch is doing and what needs to be done to recompile the Xen hypervisor and install it properly) but maybe not a lot of work by the developers. But I also have to say that users often assume things are simpler than they expect. If the devs have no use for OS X and there's only one user who really wants it, the priority is probably not that high.

> > I own a Mac, I want to run MacOSX on Qubes on my PC which is much much
> > more powerful than my Mac. And that way I could also have multiples.
>
> You know that you really start sounding like a spoilt child? If this is
> so important to do, implement it, publish it on the repository and
> mantain the code across Qubes versions. Do the work or pay for it.

Yes, there is always the option to ask a Qubes-dev what he wants in terms of compensation to get the feature faster implemented.

I adjusted my expectations in terms of F/OSS that I can have feature requests and bug reports and hope that they get implemented at some point because I just don't have the money to pay a dev because I expect their hourly rates are outside my budget. Even with paid software I had to adjust my expectations that I pay for what the software can do now - everything else is just hopeful wishing (looking at you Hibari).

Niels

[dom...@dominikdorn.com]

Hi.. just chiming in...

I came here because of all the hype that's going on about Cubes-OS at the moment, mainly because of the Snowden movie. I liked what I've seen in the video tour.

On the main website, Cubes-OS is advertising that its able to run Mac OS X and iOS.

I also own a Macbook Pro and would like to run Mac OS X as a Cubicle / multiple cubicles .. at the moment, I can quite easily install a OS X VM with VMWare Fusion - they even provide a explicit installation option for it, where you can install it from the rescue partition.

So obviously, the legal part is already tackled by checking for some properties on the underlying hardware.. Apple seams to be fine with it, as else VMWare wouldn't allow it.

The two main questions now are:
1) Are there skilled CubesOS developers that would be willing to do this?
2) What resources would they need to do this (hardware, money, other developers)?

if we have a yes for 1) we can try to find a way for 2) ... crowdfunding comes to my mind. If of course no Devs are interested in this, the whole thing makes no sense and references to MacOS X and iOS should be removed from the website, so people now right from the start that this is not supported.

cheers,
Dominik

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-10-29 07:52, dom...@dominikdorn.com wrote:
> Hi.. just chiming in...
>
> I came here because of all the hype that's going on about Cubes-OS at the moment, mainly because of the Snowden movie. I liked what I've seen in the video tour.
>

Welcome. :)

> On the main website, Cubes-OS is advertising that its able to run Mac OS X and iOS.
>

Where do you see this?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYFL0aAAoJENtN07w5UDAwDcgQAM08InYAYRdAjbyEQooWkbOL
26ZIscMhW7niCYoKGEQml2igxE6hE6NKiT7uIVoQRRzfm1QZpMkop1VqE+f+qZ/M
u60ThVIRHAEKbJe6PzxruwEORwtJ7UAzvlxYBeg6XCwiHVuDUxIAeoSSJUR6XOwS
iWTfdz6FQ70fFDA3OCQjx2kTC+7r3CItw3S3CtzWbl0pr1lpEwRb84/NkrrULwr1
WegVwS0CwJdbpn5OUPSIAc9HlM9zumTZHIvL1FNPTSZxnzR4gZQ1dggTEONY/kSK
X9cOfdyVTpjN1Ubb23cQeioHKt1o5JaiZcRr/rApRJJUwiJhG0IwCfzzsTow8CQ7
agVy5Atya6alUy6oWDsva22BbGLAUyEb6K0wfu5ti2fP/8GJlvzVQZ/r3ZS7zxG1
eheYkHnyuAdBRbpgMz4PfaNd50Hfp8E9egDvD+WsQwUbkohp9G0kafZkCao3f2Ax
1ecTBmJjLgQExkmTQ5gSC7jHH2Itt58dYYzN3n5IRpn6BDyWi9tvNSzMG3yIDGUM
mnKTkAghZQSolA4YzRz7MFcvIRQGCydc7DWxbOrx+TIsL4DRiYoQnYy6/Sgs3Eha
pqQZ3mxiWRLPsl/zSKbTuomDcQ6r+dcRYZ5HfQf3CoFzKmP5Pd6S0p7wod/QTSlb
qjvPezog8Iekgguu8ipv
=zUp6
-----END PGP SIGNATURE-----

[Dominik Dorn]

Hmm.. just noticed that it does not say "we support os x"... still a little misleading.. 

so back to the question... what's required to get this going? 

Cheers,

Dominik

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/RiVntUzgJmY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to qubes-users+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5f585451-a8d2-81be-6f01-fa3443c1415f%40qubes-os.org.

For more options, visit https://groups.google.com/d/optout.

--

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-10-29 09:19, Dominik Dorn wrote:
> [image: Inline image 1]
>
>
> Hmm.. just noticed that it does not say "we support os x"... still a little
> misleading..
>

Oh, that's just Google giving you a preview of our "What is Qubes OS?"
explanation:

https://www.qubes-os.org/intro/#what-is-qubes-os

As you can see, that sentence is literally just explaining what an operating
system is (for non-technical readers) and pointing to the most well-known
examples (which, of course, includes OS X).

> so back to the question... what's required to get this going?
>

I'm afraid Qubes does not (currently) support OS X. However, we have an
open issue for it, and we welcome help on this:

https://github.com/QubesOS/qubes-issues/issues/1982

You can read more in this message (and the surrounding thread):

https://groups.google.com/d/msg/qubes-users/RiVntUzgJmY/rXMtXD3WKQAJ


P.S. - Please try to avoid top-posting.

>
> On Sat, Oct 29, 2016 at 5:15 PM, Andrew David Wong <a...@qubes-os.org> wrote:
>
> On 2016-10-29 07:52, dom...@dominikdorn.com wrote:
>>>> Hi.. just chiming in...
>>>>
>>>> I came here because of all the hype that's going on about Cubes-OS at
> the moment, mainly because of the Snowden movie. I liked what I've seen in
> the video tour.
>>>>
>
> Welcome. :)
>
>>>> On the main website, Cubes-OS is advertising that its able to run Mac OS
> X and iOS.
>>>>
>
> Where do you see this?
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYFNQoAAoJENtN07w5UDAwykgP/io5tpKGuzywpVh+lwAqyagr
2cqOlTf9U9gUn/8M/eSuyhIfpgjcytIsHUnX28vABhtITSgZ1Br2eTIfiHNPlrvd
Ad+wqbY9NXkb5sG865i5sgXrZEosiVSRv1I4+ut49foWOAiIjDzoAGuCxS/usbUR
RvugtKBhVMPWwa7jdFLWDJeSlPLxzo0TKyTWY2dY0U4+pp1Z37wI6NquplzS2Pzb
AqeDGVIFzTAS0f1nb7VDTaf/1VPCEtX8ZUoRR6LxgZJZxOkwp8NQc2gD4t+uM5kJ
cqNwSlep8PBsODGZmvdt9fmOFUC3ZSwpBqLU2S00omtDo84s0NVEj7t7CM3jQZDN
ipm/SxYehrbJaaSkH6nv1+HA5kJdMV7eAOLxp1d851lXOH3EW0oz9M+ksbTffb+V
WsDEbhZi1NPgny7XSzQ1HDRdo7mUWv/nzvVGzZrW/6A0pQsZ1DBxIYZN2EOSFh3E
Lkip3jL1Jgh8qQINu8nd+Fh4pUVvb0XqO9kq+MMOEwhXs7kGWeGibafZvCh1YBeO
SAGKajq5epkLnnSQ6KIARHmguqiwVdk0BI89AWghzwEmiw8FEwOnKZoQ6wPdZAJR
Xz+ZJNKmFCLw5rXp2SatxRA59lUHIdR95PiUT/bMJ06UF31OPYH/isv1OfAjfIQt
2yLyG9PoQboZZ2JbPgpw
=WS7M
-----END PGP SIGNATURE-----

[Eric Shelton]

On Saturday, October 29, 2016 at 12:54:11 PM UTC-4, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-10-29 09:19, Dominik Dorn wrote:
> > [image: Inline image 1]
> >
> >
> > Hmm.. just noticed that it does not say "we support os x"... still a little
> > misleading..
> >
>
> Oh, that's just Google giving you a preview of our "What is Qubes OS?"
> explanation:
>
> https://www.qubes-os.org/intro/#what-is-qubes-os
>
> As you can see, that sentence is literally just explaining what an operating
> system is (for non-technical readers) and pointing to the most well-known
> examples (which, of course, includes OS X).
>
> > so back to the question... what's required to get this going?
> >
>
> I'm afraid Qubes does not (currently) support OS X. However, we have an
> open issue for it, and we welcome help on this:
>
> https://github.com/QubesOS/qubes-issues/issues/1982
>
> You can read more in this message (and the surrounding thread):
>
> https://groups.google.com/d/msg/qubes-users/RiVntUzgJmY/rXMtXD3WKQAJ
>
>
> P.S. - Please try to avoid top-posting.

Do not expect any success with getting OSX/MacOS working until a recent version of QEMU is in place for HVM (the only version of QEMU that works in a stub domain right now is very old and many, many changes and improvements have been made to QEMU since then that make it a lot easier to run guest OSes. Getting that to work is a substantial development effort. Headway is being made on it, but I don't know if you can count on it being a Qubes 4.0 feature - I suspect it is not a blocker that would justify delaying that release.

Then, even after QEMU is in place, there will likely be a few additional challenges, but I there are enough examples of OSX/MacOS being run under QEMU+KVM to get past that.

Finally, running OSX/MacOS as a guest OS never really has been much of a priority in the Xen community, so it may never end up running "out of the box."

Eric

[Manuel Amador (Rudd-O)]

On 06/17/2016 04:11 AM, Drew White wrote:
>
>
> On Sunday, 15 May 2016 14:05:50 UTC+10, Jeremy Rand wrote:
>
> FWIW, I think a legal argument could be made that such license
> agreements are anti-competitive and therefore unenforceable.
> However,
> I am unaware of any specific precedent for this argument, so it would
> indeed probably be unwise for ITL to violate the license agreement
> unless their goal is to win the inevitable lawsuit and thus achieve a
> beneficial precedent. (And while that would be laudable, I would
> definitely not blame ITL if they decided that such activities are not
> worth their effort or budget.)
>
> (And of course, I'm not a lawyer.)
>
>
> Well, in the end, I own a mac, It's not breaking any agreement or
> anything for me wanting to run it.

Yeah you are. Check the licensing terms for the Mac OS X software that
came with it.

Not that it matters, as it's a bullshit "agreement" that transforms a
purchase into somewhat of a feudal renting system of objects.


--
Rudd-O
http://rudd-o.com/

[Jeremy Rand]

Manuel Amador (Rudd-O):

Drew reminds me of a kid I knew in high school who routinely got his
legal advice from the first response he got on Yahoo Answers. You can't
seriously expect someone with that mindset to have the patience or skill
set to read the OS X license agreement, can you? I mean, he doesn't
even have the patience or skill set to read paragraph-long answers that
he's given on this mailing list (see his countless other threads).

-Jeremy

[Alex]

On 11/06/2016 10:31 AM, Jeremy Rand wrote:
> Manuel Amador (Rudd-O):
>> On 06/17/2016 04:11 AM, Drew White wrote:
>>>
>>> Well, in the end, I own a mac, It's not breaking any agreement
>>> or anything for me wanting to run it.
>>
>> Yeah you are. Check the licensing terms for the Mac OS X software
>> that came with it.
>>
>> Not that it matters, as it's a bullshit "agreement" that transforms
>> a purchase into somewhat of a feudal renting system of objects.
>

> [...]
Actually reading the license of OSX available at
https://store.apple.com/Catalog/US/Images/MacOSX.htm is very easy
because they are awfully short and simple, compared to a lot of other
software.

And in 2.A. there is the actual permitted use:
> This License allows you to install and use one copy of the Apple
> Software on a single Apple-labeled computer at a time.

which means that you can own an Apple Mac computer, install
Qubes/Linux/what you want on it, install VirtualBox/VMWare/Xen on it,
and have an OSX virtual machine while still behaving according to the
license.

That's also the position of VMWare regarding their products; please
check http://partnerweb.vmware.com/GOSIG/MacOSX_10_9.html where they
speak about VMWare Fusion:
> Prerequisites
>
> Before you begin, verify that the following tasks are complete:
>
> Read General Installation Instructions for All VMware Products.
> Download Install OS X Mavericks.app from the Mac App Store. Ensure
> your physical system is an Apple-labeled computer. This is required
> to install or run OS X 10.9 in a virtual machine. Ensure you physical
> system can support an additional virtual machine with at least 2GB of
> RAM.
The third point, "ensure your physical system is an Apple-labeled
computer", explicits the then-actual license conditions to run a
virtualized OSX within the license terms.

AFAIK, by the link from the apple store reported above, these terms are
still valid - you can run a virtualized OSX and be within the license
terms if it is the only instance you run, and it runs on an
Apple-labeled computer.

--
Alex

[Achim Patzner]

Am 06.11.2016 um 10:42 schrieb Alex:

> On 11/06/2016 10:31 AM, Jeremy Rand wrote:
> Actually reading the license of OSX available at
> https://store.apple.com/Catalog/US/Images/MacOSX.htm is very easy
> because they are awfully short and simple, compared to a lot of other
> software.
>
> And in 2.A. there is the actual permitted use:
>> This License allows you to install and use one copy of the Apple
>> Software on a single Apple-labeled computer at a time.
> which means that you can own an Apple Mac computer, install
> Qubes/Linux/what you want on it, install VirtualBox/VMWare/Xen on it,
> and have an OSX virtual machine while still behaving according to the
> license.

There were other people who thought it would be that simple (mind you,
I'm not talking about Mac OS X Server, a product that became a 30$
add-on later); does anyone remember a product called VMware Fusion
version 4.10 which suddenly removed the artificial barrier against
running non-Server Mac OS X on VMware and which had ot be replaced by
version 4.11 only two weeks later with the only bug fixed being able to
run Mac OS X on a VM? That must have ben one hell f a letter Apple sent,
I guess I would pay for reading it.

> The third point, "ensure your physical system is an Apple-labeled
> computer", explicits the then-actual license conditions to run a
> virtualized OSX within the license terms.

And if you do, you can run VMware ESXi on a Mac Pro cluster and use it
to virtualize multiple Mac OS-based machines, as long as they are
installing Server.app on them. One of our customers is doing it to get
the applications from his old Mac Servers running in a world where the
most important customer is obviously the iPad Pro user...

> AFAIK, by the link from the apple store reported above, these terms are
> still valid - you can run a virtualized OSX and be within the license
> terms if it is the only instance you run, and it runs on an
> Apple-labeled computer.

Point is: You can't buy a valid license without buying a machine with
it. I guess you could buy *heaps* of Mac mini just to obtain licenses...
Just like having to buy defective power supplies to get MagSafe
connectors. And Apple does not attack the people breaking the licenses;
they are usually aiming at those who enable others to break them (which
I regard as a good thing).


Achim

[Dominik Dorn]

The current VMWare Fusion v8 allows to run multiple instances of OSX.
They even advertise it on their website:
http://www.vmware.com/products/fusion.html
"macOS Sierra-Ready
Launch virtual machines on Macs with macOS 10.12 Sierra, or safely test the new macOS in a sandbox on your current Mac without disruption."

[Drew White]

Still, it's running on a Mac...
So that's why aparently they can advertise that like that and do it like that. Because it's on a Mac already.

[Eric]

Most of the following removed for brevity:

On Sunday, November 6, 2016 at 4:37:15 AM UTC-8, Achim Patzner wrote:
>
> Point is: You can't buy a valid license without buying a machine with
> it. I guess you could buy *heaps* of Mac mini just to obtain licenses...
> Just like having to buy defective power supplies to get MagSafe
> connectors. And Apple does not attack the people breaking the licenses;
> they are usually aiming at those who enable others to break them (which
> I regard as a good thing).
>
>
> Achim

Most of seems a bit misinformed (or at least very confusingly worded), and thankfully Apple's own SLA provides us with very direct answers:


"B. License from Mac App Store. If you obtained a license for the Apple Software from the Mac App Store, then subject to the terms and conditions of this License and as permitted by the Mac App Store Usage Rules set forth in the App Store Terms and Conditions (http://www.apple.com/legal/itunes/ww/) (“Usage Rules”), you are granted a limited, non-transferable, non-exclusive license:

[several sections removed for brevity]

(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."


This is the license for the NON-SERVER version of Mac OS X Lion, 10.7, and every operating system since then has had a similar provision. This means that yes, you do need to run it on Apple hardware, but you can run up to three copies of OS X, or two in a virtual machine presuming you were using Xen or ESXi.

Macs have good VT-d and VT-x support, but since they don't use PS/2 for trackpad and keyboard, or have a TPM, it would be a terrible platform to run Qubes on (trust me, I've tried). Not to mention that HiDPI support is still a work in progress - I miss my retina display something awful.


Which brings us to the real question, how do we get this to work on Qubes today, on a non-Apple laptop?

1) accept that the developers will not work on making this happen, because Mac hardware is not a good target for Qubes unless something changes, and the dev's very limited time is much better spent elsewhere, especially given the potential for SLA abuse. I for one would much rather see Qubes 4 ship, than have macOS patches land.

2) accept *individual* responsibility for breaking a software license agreement.

3) try to make it work (not sure if those patches above still work in Xen 4.7, but Xen 4.7 might also have some of the newer code needed to make it work). ¯\_(ツ)_/¯
Also accept that if you have to patch Xen with code downloaded from a mailing list, you're probably downgrading your dom0 security, and therefore the overall system security, by a fair amount.

4) google a bunch (IIRC there is some info floating around on the QEMU mailing list that might help).

5) celebrate or drink, depending on the outcome. possibly both.

[Eric]

<snip>

On Saturday, April 1, 2017 at 5:31:36 PM UTC-7, Eric wrote:

> 4) google a bunch (IIRC there is some info floating around on the QEMU mailing list that might help).

http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

looks like Eric Shelton who provided the patches up-thread did most of the work on this.

[Drew White]

The thing about the licensing is that IF you get permission from Apple to use the OS under Qubes then you can. Even if it is not on Apple Hardware.

If you get permission to do so then you can. There is no issue there.

1. The developers won't make it happen because they think it's breaking the licensing to get permission to run it.

2. It isn't breaking the agreement if you have permission from Apple to do the specified things.

3. I have patches and all that allow it to work in 3.0, all that one has to do is update it to run properly on 4. But it can patch 3.1, however the updates in 3.2 mean the patches need to be updated more.

4. Why use Google "a bunch" when you can just look on this forum and read this thread?

5. Do both, because you should always celebrate both successes and failures.
From failure, you learn, from success, not so much.

[Vít Šesták]

> The thing about the licensing is that IF you get permission from Apple to use the OS under Qubes then you can. Even if it is not on Apple Hardware.

Sure. This, however, essentiually means you get a different license. Well, anything that the original license does not allow can be solved by licencing the software under a different license – provided that the vendor wishes to do so. But the key question is, how hard is it to get the license. I doubt Apple will give the license to anyone who asks. If they did, why would they put the restrictions on the standard license?

Regards,
Vít Šesták 'v6ak'

[Eric]

On Sunday, April 2, 2017 at 5:09:05 PM UTC-7, Drew White wrote:
>
>
>The thing about the licensing is that IF you get permission from Apple to use the OS under Qubes then you can. Even if it is not on Apple Hardware.

Good luck. Apple has not done this for ANYONE, even the big names, since Steve Jobs came back. That door is closed. The way is shut. For our purposes, it's not a real option.

>
>If you get permission to do so then you can. There is no issue there.
>
>1. The developers won't make it happen because they think it's breaking the licensing to get permission to run it.
>
>2. It isn't breaking the agreement if you have permission from Apple to do the specified things.

See the above. Short answer, if we can make it work such that it works on Apple laptops, no issue (and that work would likely carry over to non-Apple laptops, "incidentally" as it were.

>
>3. I have patches and all that allow it to work in 3.0, all that one has to do is update it to run properly on 4. But it can patch 3.1, however the updates in 3.2 mean the patches need to be updated more.

So let's make that happen. There's an active ticket open (https://github.com/QubesOS/qubes-issues/issues/1982) but I imagine it would require a fair piece of work. (and I sure as shit don't know enough about hypervisor underpinnings to even take a stab at that).

>4. Why use Google "a bunch" when you can just look on this forum and read this thread?

Because there are additional resources that might contribute knowledge and help - specifically the ones involving OS X on QEMU.

>5. Do both, because you should always celebrate both successes and failures.
>From failure, you learn, from success, not so much.

*toasts*

[nhe...@gmail.com]

On Monday, October 31, 2016 at 4:39:40 AM UTC+8, Manuel Amador (Rudd-O) wrote:
> On 06/17/2016 04:11 AM, Drew White wrote:
> >
> >
> > On Sunday, 15 May 2016 14:05:50 UTC+10, Jeremy Rand wrote:
> >
> > FWIW, I think a legal argument could be made that such license
> > agreements are anti-competitive and therefore unenforceable.
> > However,
> > I am unaware of any specific precedent for this argument, so it would
> > indeed probably be unwise for ITL to violate the license agreement
> > unless their goal is to win the inevitable lawsuit and thus achieve a
> > beneficial precedent. (And while that would be laudable, I would
> > definitely not blame ITL if they decided that such activities are not
> > worth their effort or budget.)
> >
> > (And of course, I'm not a lawyer.)
> >
> >
> > Well, in the end, I own a mac, It's not breaking any agreement or
> > anything for me wanting to run it.
>
> Yeah you are. Check the licensing terms for the Mac OS X software that
> came with it.

FWIW - I have a MacBook Pro with OS X. I want to run qubes on my MacBook Pro, and OS X inside qubes. OS X is the running on genuine Apple hardware. No license agreements broken. Cheers.

I am not arguing that this is a good use case to work on for Qubes developers, just saying that the license argument is untrue.

Sadly, getting Qubes to run on Apple hardware isn't super easy either.

[Unman]

Naturally, the situation isn't as simple as you suggest.

Apple licensing has altered from OSX version to version - it's pointless
to talk of this without specifying WHICH version you are talking about.
Also, most of the licenses are not transferable so if you acquired a
second hand MacBook you almost certainly wont have the benefit of the
"virtualization" clauses in later EULAs.

On your second point, it's easy to get Qubes running on SOME Apple
hardware - in my experience old MacBookPro6.2 works fine with 8GB RAM:
the i5s don't, of course support VT-X but are otherwise fine.