This is now being investigated by Apple. It turns out to have nothing to do with our kext as it occurs even without our kext loaded. It reproduces on Macs with Apple silicon.

Our solution is to install two copies of Xcode, version 15 and version 14.3.1. The older version is located at "/Applications/Xcode_14.3.1.app". Then the build script can just set the environment variable on the command line which causes xcodebuild: env DEVELOPER_DIR="/Applications/Xcode_14.3.1.app/Contents/Developer" xcrun xcodebuild build -configuration ......... This avoids the need for root access (which xcode-select requires) as well as ensuring that the older developer tools are only used for this one build step.

The lack of a macOS 14 installer is severely limiting our ability to test our applications and drivers with the new version of macOS. We do not have enough Macs to dedicate a separate test Mac for each of our test engineers just for testing macOS 14. Each new build of our products has to be tested on multiple versions of macOS; all of our products support macOS back to 10.14, some of them back to 10.12. In addition, we are completely blocked on testing on Intel Macs. Just some feedback from outside Apple's walled garden. Tim Standing VP Software Development Other World Computing, Inc.

Your driver can't match and out-score an Apple supplied driver until around 120 seconds after startup. Since there is an Apple supplied driver which recognizes IOMedia objects with GPT partition maps, that driver will always load, and IOKit will not load your driver, until after the 120 second time window. This behavior was introduced in macOS 10.14 - I believe for security reasons.

Is there a similar command to determine the the boot security settings on a Mac with Apple silicon? I understand that this is configured on a volume by volume basis but can't find any security settings reported by diskutil.

No, not yet...

Quinn from Developer Support gave me the answer to this one. I was building my macOS application with the wrong architecture. For ARM based Macs, the kernel and user space code using different architectures: kernel code uses arm64e and user space code uses arm64. From what I have read, the major difference is that arm64e uses pointer authentication whereas arm64 does not. Applications and other user code needs: arm64 (i.e.: -arch arm64 on the command line with xcodebuild) For kexts: arm64e (i.e. -arch arm64e on the command line with xcodebuild) To build a fat application on the command line use: xcodebuild -arch x86\_64 -arch arm64 .... To build a fat kext on the command line use: xcodebuild -arch x86\_64 -arch arm64e .... Tim

Yes, I am seeing the same problem.... still searching for an answer...

To upgrade to beta 10, I used the information from the DTK information regarding upgrading to beta 10: "Please re-run the BAU in order to access macOS 11 Big Sur beta 10. Alternatively, you can download the image via the “Download” button to the right." From this page: https://developer.apple.com/download/universal/ When I wedged my DTK Mac earlier, I had to do the recovery steps outlined here: https://download.developer.apple.com/Documentation/Universal_App_Quick_Start_Program_Resources/DTK_Release_notes.pdf Hope this helps. Tim

My DTK unit no longer powers on. After 10 minutes of use, it's now completely inoperative. Is there a magic key combination for bringing it back to life. I have tried: 1) holding down the power button for 10 seconds and 2) leaving it disconnected from the AC outlet for 10 minutes. Nothing happens. Does anyone have an email address where I can request a replacement unit? If not, I will just send go through the "Contact Us" link. Thanks in advance, Tim

This is so awesome!! Thank you so very much.

Thank you so much for both of these replies. I will make sure that I only ever use the SIMD code in threads which I create using kernelthreadstart(). I will make sure they are not used on user threads which enter the kernel context or primary interrupt threads. I know that this will incur a performance hit to save and restore the registers but since I will be processing 1 - 3 gigabytes a second in 4 MB chunks, I think it will be worth the expense. When you state that they work with AVX, does this include the AVX-512 extension or just AVX (the 256 bit instructions)? Lastly, will this behavior be the same on arm64e ISA Macs?

This is new behavior with macOS 10.14 and only occurs when SIP is enabled. At boot time, 3rd party drivers are prevented from loading. This restriction stops 30 - 45 seconds after startup. I assume this is done, by design, to keep malicious drivers from snooping on access to the boot device.

This is so awesome!!! It worked first try. Thank you. I chose the first of your two options.In summary, my steps were:First I made sure that the kdumpd wasn't running (from my previous attempts):standing@Zippy ~ %sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.kdumpd.plistThen I copied the com.apple.kdumpd.plist to /Library/LaunchDaemons:sudo cp /System/Library/LaunchDaemons/com.apple.kdumpd.plist /Library/LaunchDaemons/I then created the PanicDumps directory inside /Library:standing@Zippy ~ % sudo mkdir /Library/PanicDumpsstanding@Zippy ~ % sudo chmod 1777 /Library/PanicDumpsI changed the ProgramArguments parameter to point to the new location. The com.apple.kdumpd.plist now reads:<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict> <key>Disabled</key> <true/> <key>InitGroups</key> <true/> <key>Label</key> <string>com.apple.kdumpd</string> <key>ProgramArguments</key> <array> <string>/usr/libexec/kdumpd</string> <string>/Library/PanicDumps</string> </array> <key>Sockets</key> <dict> <key>Listener</key> <dict> <key>SockServiceName</key> <string>1069</string> <key>SockType</key> <string>dgram</string> </dict> </dict> <key>UserName</key> <string>nobody</string> <key>Umask</key> <integer>7</integer> <key>inetdCompatibility</key> <dict> <key>Wait</key> <true/> </dict></dict></plist>Lastly, I loaded the daemon using launchctl:standing@Zippy ~ % sudo launchctl load -w /Library/LaunchDaemons/com.apple.kdumpd.plist