Apple Maps Guides

While the DEXT loads successfully, I'm facing a DMA issue: an INQUIRY command results in a 0-byte disk because the data buffer received by the DEXT is all zeros, despite our firmware logs confirming that the correct data was prepared and sent. How is your DEXT getting access to the transfer data? SCSIControllerDriverKit was intentionally architected to make that very difficult. Compared to a KEXT, are there any known, stricter IOMMU/security policies for a DEXT that could cause this kind of silent write failure (even with a correct IOVA)? No, not really. However, I think you've confused things a bit here: Alternatively, what is the correct and complete expected workflow in DriverKit for preparing an IOMemoryDescriptor* fDataBuffer (received in UserProcessParallelTask) for a PCI hardware device to use as a DMA write target? My concern here is where you say: ...for preparing an IOMemoryDescriptor* fDataBuffer The problem is that the whole goal of UserProcessParallelTask is to AVOID giving you an IOMemoryDescrip

Our ES client launches and functions when started manually (terminal). FYI, this is almost certainly because you previously granted Terminal.app FDA, which your client then inherited. Terminal.app does not have any unique/privileged access to the file system. We can’t find a supported way to grant Full Disk Access (SystemPolicyAllFiles) to a system daemon on unmanaged Macs (no MDM). The supported way to do this is for the user to grant your daemon FDA through System Setting-> Privacy & Security-> Full Disk Access. You may have already tried this and found that the interface wouldn't let you select this bare executable: /Library/Application Support///Platform/ However, the direct solution to that is simply embed your daemon executable inside an app bundle, as described here. However, this would also be a great time to adopt SMAppService, which would change some of the requirements/behavior here. Covering some specifics: On macOS 14/15, is Full Disk Access for system daemons strictly MDM-only via PPPC

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

I’ve removed all references to ‘Nano Banana’ and updated my apps to comply with Apple’s guidelines. My account is still flagged for termination. I would greatly appreciate any advice on how to escalate this officially with Apple.

Thanks for mentioning this problem. I have seen other reports of this as well. Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

I'm aware that IOBufferMemoryDescriptor::Create can be used in DriverKit to allocate memory and share it with user space. However, is the allocated memory physically contiguous? True physical continuity is largely irrelevant on our platforms. At this point, all of our platforms include an IOMMU which manages mapping 64-bit memory ranges into the physical addresses visible to devices on the PCI bus. You can read more about how this actually works in Background Info on PCI Address Translation. Can it guarantee that when I subsequently call PrepareForDMA in IODMACommand, there will be only one segment? Yes. Many of our DEXTs actually check that segmentsCount==1 and assert (crash) on any value other than 1. Having the descriptor segment would imply that the machine was so far out of the expected behavior range that they'd prefer to crash instead of trying to sort it out. I'm actually not sure a DEXT could get IODMACommand to segment. Inside the kernel, this is typically caused by IOMultiMemoryDescriptor,

Thanks for sharing here. Do you have a feedback report yet ? If not, I’d suggest that you file one because that is the formal way to communicate with Apple. If you do so, please share your report ID here. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thank you for the reply. I shared the test project to my apple support ticket that I created. The apple support ticket is Case-ID: 16525926. Let me elaborate some more as to what I am referring too. In my app we are using polymorphism that cannot be Codable. But we need to drag and drop objects into a predefined box, label, table, etc and if we simply code everything as a data blob it works no problem. But the user will not know that the drop area for Character Names was not accepted if you dropped it on Played by drop zone. The below Standard Object is shared by the other two classes. This gets ignored by Codable. So, if you try and package them up without Codable in your own data blob, it's fine. But the drop zone cannot determine that the data blob from CharecterName is different from PlayedBy. Therefore accepts drop. You can use validation afterwards to prevent errors. But that is after the mouse pointer gives you a green + sign saying that this object belongs to this drop. Im trying to

I was asking the same question on here several months ago, seems there is no way. Do you have an Apple IP range list? How did you obtain it, how do you know it won't change at some point in the future though.