Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable file protection for BSGRunContext #1407

Merged
merged 4 commits into from
Jun 21, 2022
Merged

Conversation

nickdowell
Copy link
Contributor

@nickdowell nickdowell commented Jun 20, 2022

Goal

Fix a potential segfault when accessing bsg_runContext after device is locked.

If an app uses the Data Protection Entitlement to set the default protection to NSFileProtectionComplete, the file mapping becomes invalidated once the underlying file gets encrypted - i.e. after locking the device. Dereferencing bsg_runContext then causes a segfault and crashes the app.

Changeset

Disables content / file protection of the memory mapped file, using the NSURL / NSURLFileProtection APIs.

Considered using lower-level APIs - fcntl with F_GETPROTECTIONCLASS and F_SETPROTECTIONCLASS is available but the protection class definitions are private to xnu and their mappings to corresponding NSURLFileProtectionType undocumented.

/*
 * Protection classes vary in their restrictions on read/writability.
 * A is generally the strictest, and D is effectively no restriction.
 */

#define PROTECTION_CLASS_A 1 // -> NSFileProtectionComplete
#define PROTECTION_CLASS_B 2 // -> NSFileProtectionCompleteUnlessOpen
#define PROTECTION_CLASS_C 3 // -> NSFileProtectionCompleteUntilFirstUserAuthentication
#define PROTECTION_CLASS_D 4 // -> NSFileProtectionNone
#define PROTECTION_CLASS_E 5
#define PROTECTION_CLASS_F 6

Testing

Reproduced the crash locally by adding the Data Protection Entitlement and a UIBackgroundTask to a sample app. After locking the device, the app would crash upon completion of a 10s background task (it appears that content gets protected after a 10 second grace period.)

Was unable to reproduce the crash with this fix in place.

@nickdowell nickdowell requested review from kstenerud and kattrali June 20, 2022 10:42
@nickdowell nickdowell force-pushed the nickdowell/fix-mmap-crash branch from 987b053 to f63ee41 Compare June 20, 2022 10:51
@github-actions
Copy link

github-actions bot commented Jun 20, 2022

Bugsnag.framework binary size increased by 128 bytes from 814,440 to 814,568

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.1%    +208  +0.1%    +208    __TEXT,__text
  +0.2%     +60  +0.2%     +60    __TEXT,__objc_methname
  +0.3%     +59  +0.3%     +59    __TEXT,__cstring
  +1.7%     +48  +1.7%     +48    Binding Info
  +0.0%     +48  +0.0%     +48    String Table
  +0.0%     +32  +0.0%     +32    Symbol Table
  +0.2%     +32  +0.2%     +32    __DATA,__cfstring
  +5.0%     +16  +5.0%     +16    __DATA,__got
  +0.2%     +16  +0.2%     +16    __DATA,__objc_selrefs
  +0.5%      +8  +0.5%      +8    Indirect Symbol Table
  -0.4%      -8  -0.4%      -8    Rebase Info
  -0.7%     -64  -0.4%     -64    [__DATA]
  [ = ]       0  -2.7%    -128    [__LINKEDIT]
  -1.3%    -327  -1.3%    -327    [__TEXT]
  +0.0%    +128  [ = ]       0    TOTAL

Generated by 🚫 Danger

@nickdowell nickdowell requested a review from kstenerud June 20, 2022 15:18
@nickdowell nickdowell merged commit e8e0c5f into next Jun 21, 2022
@nickdowell nickdowell deleted the nickdowell/fix-mmap-crash branch June 21, 2022 14:44
@nickdowell nickdowell mentioned this pull request Jun 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants