offloading

@Engineer we are working on an alternative approach to renew the attestation in case of these failures. We still want to use a possession factor secured in Secure Enclave for device binding. And for that we are planning to use a PrivateKey Are you aware if this offloading issue only impacts app attestation or can the same issue happen with keys created via Secure Encalve too? Thanks

We've in a very similar situation too and suspect many of our users are unwillingly churning as the app is offloading automatically because our users mainly use the extension and not the app itself. I hope we can soon get some transparency about what causes these automatic offboardings. It is about size, days of not opening the app, or whether the app does not communicate with the OS.

Oh, there are so many pitfalls here )-: The System keychain is a filed-based keychain. To modify it you must have file system permissions to change the file. That means running as root. Using sudo for this is tricky because of execution context issues. There are two relavent bits of execution context here: BSD and security. The sudo command changes the first but not the second. That can result in a lot of ‘fun’ edge cases. In this specific situation I think the only relevant edge case is the default keychain, which is easy to work around. However, keep an eye out for this in other situations where you use the security-related APIs from sudo. Note TN2083 Daemons and Agents talks about execution contexts in some detail. File-based keychains use an access control system based on ACLs. If program A adds a keychain item and program B tries to access it, one of two things happens by default: If B is in a GUI context, the user gets a dialog asking whether to allow this. If not, the access fails. Your -T argument is

The issue with the keys not working when an app is offloaded/reloaded and when an app is restored from backup (or migrated to a new device) is known. It has to do with the backed up key information no longer matching the on device information after a restore. The AppAttest team is aware of this, and is working on a solution in an upcoming iOS release. In the meantime, the workaround is to follow the standard guidance when encountering key errors, and to generate a new key and attest it. Argun Tekant /  DTS Engineer / Core Technologies

Hi, @DTS Engineer [quote='820617022, DTS Engineer, /thread/771298?answerId=820617022#820617022'] The queue architecture above handles this. Every queue has an associated dispatch queue, which lets you control parallel packet processing. [/quote] In the RSS feature of Windows (e.g., as described on the website https://learn.microsoft.com/en-us/windows-hardware/drivers/netcx/rsc-offload), the driver developer uses NET_ADAPTER_RECEIVE_SCALING_HASH_SECRET_KEY to request a hash key from the system. This hash key is then used with an algorithm to calculate a hash value, which determines the specific QueueID. Then, I reviewed this document IOUserNetworkRxSubmissionQueue/withpool As I understand it, if I need 4 queues, they can be created using withPool to initialize IOUserNetworkPacketQueueId queueId[0~3]. Each queue extracts packets from the same IOUserNetworkPacketBufferPool, with capacity and bufferCount set as uint32_t capacity, uint32_t bufferCount. However, I am uncertain how to declare or assign valu

Tx/Rx Multiqueue, Yes. A DEXT can have multiple IOUserNetworkRxSubmissionQueue/IOUserNetworkRxCompletionQueue and IOUserNetworkTxSubmissionQueue/IOUserNetworkTxCompletionQueue. RSS The queue architecture above handles this. Every queue has an associated dispatch queue, which lets you control parallel packet processing. NS/ARP offload Your DEXT is directly controlling your hardware so, yes, I think this is something you could configure your hardware to do. RSC, PTP or packet timestamping and TSN. I'm not entirely sure how all of those are handled but it might be helpful to look at the NetworkingDriverKit Constants list. __ Kevin Elliott DTS Engineering, CoreOS/Hardware

tl;dr - you might want to check for offloaded apps. Those might count towards a high System Data usage as well. Just adding to the discussion since I recently discovered that offloaded app storage counts towards the System Data usage. It might have been mentioned here, but I just skimmed throught the responses... In my case I had ~65Gb System Data usage, but when re-downloading one specific video app it became evident that 50Gb of those were from that app. So after re-downloading, System Data usage was reduced by 50Gb - but of course that was just moved to Applications. But now it's at least evident what app is using those 50Gb:s, giving me a fair chance to clean it up.

Documents or an Application Support directory in the Library. From everything I’ve read, it seems that Apple’s intent is Library/Application Support. Which is the correct location? Application Support - though it doesn’t really matter except in the case where you have a mixture of “documents” that the user needs to have access to via e.g. the Files app and “non-documents” that they shouldn’t. the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself). You weren’t storing it in the Caches directory, or using the “don’t backup” xattr, were you? OS updates can “offload” apps, but I’ve not seen any reports of that causing problems. Do you vacuum your sqlite db?

Moving the files to the iCloud folder will still occupy space on your hard drive unless they are automatically offload when not in use. I would recommend to read this documentation how to manage storage in iCloud :https://support.apple.com/en-us/108922 Albert Pascual
  Worldwide Developer Relations.

Hi, Could you elaborate on When overloaded, stale metal render passes need to be 'aborted', which results in metal callbacks not being called.? This approach seems like dynamic load balancing to maximize throughput. It's unclear how well this could work with current Metal API and seems unlikely to be successful with OS watchdogs. Instead we recommend reducing and optimizing workload. Guidance on that can be found in Improving your game’s graphics performance and settings (even though your app may not be a game). You may also want to consider offloading some rendering work to compute to improve efficiency. See Compute Passes.

Can you clarify the circumstances in which mach ports are leaked? Well, the unhelpful (and slightly flippant) answer is basically anytime they're not properly deallocated when they're no longer useful. More practically, the whole reason mach ports create issues IS that it's often quite difficult to connect any given mach port with the specific component responsible for managing that unit. In terms of run loop semantics specifically, I think you'd (potentially) generate a leak anytime you destroy an thread without removing/stopping all of it's input sources*. *Strictly speaking, that isn't necessarily a guaranteed leak. For example, some of our frameworks register thread destruction handlers so to handle clean up. However, at that point you're relying on the details of our own implementation, which is never ideal. Also, keep in mind that this isn't just about mach port leakage, but could involve any other resource who's management happened to be tied to that thread. The while loop in the original post is in a