OH Halvorsen, D. Clarke

O.H. Halvorsen, D. Clarke OS X and iOS Kernel Programming ▶ OS X and i. OS share a common core. ▶ Authors Henry Halvorsen and Doug Clarke deliver detail and insight into that core in OS X and i. OS Kernel Programming, which enables readers to write device drivers and extremely efficient applications. ▶ This book offers the necessary context and knowledge to graduate to the master class of i. OS and OS X programmers! OS X and iOS Kernel Programming combines essential operating system and kernel architecture knowledge with a highly practical approach that will help you write effective kernel-level code. You’ll learn fundamental concepts such as memory management and thread synchronization, as well as the I/O Kit framework. You’ll also learn how to write your own kernel-level extensions, such as device drivers for USB and Thunderbolt devices, 1st ed., XIX, 484 p. including networking, storage and audio drivers. A product of Apress OS X and iOS Kernel Programming provides an incisive and complete introduction to Printed book the XNU kernel, which runs iPhones, iPads, iPods, and Mac OS X servers and clients. Then, you’ll expand your horizons to examine Mac OS X and iOS system architecture. Softcover Understanding Apple’s operating systems will allow you to write efficient device drivers, ISBN 978-1-4302-3536-1 such as those covered in the book, using I/O Kit. ▶ 49,99 € | £44.99 ▶ *53,49 € (D) | 54,99 € (A) | CHF 59.00 With OS X and iOS Kernel Programming, you’ll: • Discover classical kernel architecture topics such as memory management and thread synchronization • Become well-versed in the intricacies of the kernel development process by applying kernel debugging and profiling tools • Learn how to deploy your kernel-level projects and how to successfully package them • Write code that interacts with hardware devices • Examine easy to understand example code that can also be used in your own projects • Create network filters Whether you’re a hobbyist, student, or professional engineer, turn to OS X andiOS Kernel Programming and find the knowledge you need to start developing The first € price and the £ and $ price are net prices, subject to local VAT. Prices indicated with * include VAT for books; the €(D) includes 7% for Germany, the €(A) includes 10% for Austria. Prices indicated with ** include VAT for electronic products; 19% for Germany, 20% for Austria. All prices exclusive of carriage charges. Prices and other details are subject to change without notice. All errors and omissions excepted..

Copy Link

Recommended publications

App Frameworks #WWDC16
App Frameworks #WWDC16 Improving Existing Apps Using modern best practices Session 213 Woody L., � to the Knowledge © 2016 Apple Inc. All rights reserved. Redistribution or public display not permitted without written permission from Apple. Agenda Reduce Technical Debt Asset Catalogs Dependency Injection Live Playgrounds Cycle of Development You down with ‘Dub-DC? Yeah, you know me. Lots of Requests Your boss More Requests Your customers Technical Debt //TODO: Write and clean up Customer’s Perspective Actuality Duarte requesting hi-res photo AppStore New API zsh AppKit CF AirPortUtility PreferencesApp iCal Foundation AVFoundation AirPortAssistant AirPortSettings AirPortAssistant OpenCL GameKit Dock Mail MapKit MobileMusicPlayer xnu AppKit AppStore MobileSafari zsh QuickTime udf WebKit BlueToothSettings cups Messages Dock ActivityMonitor MobileSafari bash Mail AccessibilitySettings GameKit GameKitServices MediaPlayerUI MediaPlayer MediaStream MobileMail Swift 3 Source code compatibility New and Updated Platforms A Dev’s Run Loop Bug Fixes Technical Debt New and Platforms ♽Updated APIs Customer Roadmap A Dev’s Run Loop Bug Fixes Technical Debt New and Platforms ♽Updated APIs Customer Roadmap A Dev’s Run Loop Bug Fixes Technical Debt New and Platforms ♽Updated APIs Customer Roadmap The Essentials A very good place to start Earlier iOS 8 5% 11% Minimum Deployment of iOS 8 • 95% of Devices iOS 9 84% As measured by the App Store on May 9, 2016 Pick a Deployment Target Latest update of previous release Deprecated API Deprecated API Treat Warnings
[Show full text]
Chapter 1. Origins of Mac OS X
1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
[Show full text]
*OS Internals::Kernel & Hardware
12 Ceci n'est pas une "heap"*: Kernel Memory Management Thankfully, kernel KPI users seldom have to deal with the physical layer, and most calls can remain in the virtual layer. We detail how the kernel manages its own vm_map - the kernel_map - through kmem_alloc* and kalloc*. We next present the very important abstractions of kernel zones. Special care is given to the nooks and crannies of the zone allocator, due to their significance over the years in exploitation. Before concluding, we reintroduce memory pressure - also presented in I/8, but described here from the kernel's perspective. The gentle memorystatus of MacOS and the ruthless jetsam of *OS are both detailed. This continues with a discussion of XNU's proprietary purgeable memory, which helps deal with memory pressure automatically. Lastly, we conclude with a rough map of the kernel's address space, and consider the kernel slide. * - Kernel memory is often incorrectly refered to as the the "kernel heap". This term (apparently used within Apple as well) is technically wrong - the heap refers to the data strcuture used in user-mode in backing malloc(3), as opposed to the automatic, thread-local memory of the stack (although the pedantic will correctly argue that user mode "heaps" no longer use the heap structure as well...). Though the kernel does make use of stack memory (for its threads and user-mode threads when in-kernel), the heap data structure is not used in any way in maintaining kernel memory, which is merely segmented into zones, similar to the Linux Slab allocator. Kernel Memory Allocation XNU makes use of multiple memory allocation facilities in the kernel.
[Show full text]
Auditing and Exploiting Apple IPC Ianbeer
Auditing and Exploiting Apple IPC ianbeer Jailbreak Security Summit May 2015 About me: ● Security Researcher with Project Zero ● Won pwn4fun last year with a JavaScriptCore bug and some kernel bugs ● That macbook air now runs ubuntu :) ● Over the last year reported ~60 OS X sandbox escapes/priv-escs (10 still unpatched) ● Some accidentally also present on iOS This talk: ● Overview of (almost) all IPC mechanisms on iOS/OS X ● Quick look at Mach Message fundamentals ● Deep-dive into XPC services ● Exploiting XPC bugs ● fontd IPC and exploiting fontd bugs ● Mitigations and the future socketpair semaphores AppleEvents IPC Zoo signals domain sockets fifo shmem Pasteboard CFMessage Distributed NSXPC A B Port Notifications D CFPort MIG XPC O Mach Messages XNU Why care about IPC? Sandboxing You probably get initial code execution in some kind of sandbox in userspace… ● renderer/plugin process ● quicklook-satellite ● ntpd Plenty of stuff is still unsandboxed on OS X ● appstore app though (...Adobe Reader...) Sandbox escape models Privilege separation: Two parts of the same application work together to isolate dangerous code Untrusted helper Trusted “broker” IPC Sandboxed Unsandboxed Sandbox escape models Privilege separation: Two parts of the same application work together to isolate dangerous code Chrome PPAPI Plugin Browser IPC Sandboxed Unsandboxed Sandbox escape models Privilege separation: Two parts of the same application work together to isolate dangerous code WebContent WebKit2/Safari IPC Sandboxed Unsandboxed Sandbox escape models Privilege
[Show full text]
Openafs Client for Macos
OpenAFS client for macOS Marcio Barbosa 2021 OpenAFS Workshop AGENDA • A high-level view of XNU • Kernel Extensions • Securing Modular Architecture • System Extensions • Apple Silicon • Conclusion • References / Contact A HIGH-LEVEL VIEW OF XNU A HIGH-LEVEL VIEW OF XNU • The Mac OS X kernel is called XNU. • Stands for X is Not UNIX. • Microkernel architecture? No, XNU is a hybrid kernel. FreeBSD Mach MONOLITHIC KERNELS • "Classic" kernel architecture. • Predominant in the UNIX and Linux realms. • All kernel functionality in one address space. • If any service fails, the whole system crashes. • Hard to extend. MICROKERNELS • Consists of only the core kernel functionality. • The rest of the functionality exported to external servers. • There exists complete isolation between the individual servers. • Communication between them is carried out by message passing. • Failure is contained. • Monolithic kernel failures usually trigger a complete kernel panic. • Performance can be an issue. HYBRID KERNELS • Hybrid kernels attempt to synthesize the best of both worlds. • The innermost core of the kernel is self-contained. • All other services are outside this core, but in the same memory space. • XNU is a hybrid. • The kernel is modular and allows for pluggable Kernel Extensions. • Absence of isolation exposes the system to bugs introduced by KEXTs. MONOLITHIC, MICROKERNELS, AND HYBRID Golftheman, Public domain, via Wikimedia Commons https://commons.wikimedia.org/wiki/File:OS-structure2.svg KERNEL EXTENSIONS KERNEL EXTENSIONS • No kernel can completely accommodate all the hardware, peripheral devices, and services available. • KEXTs are kernel modules, which may be dynamically inserted or removed on demand. • Augments kernel functionality with entirely self-contained subsystems.
[Show full text]
Copyrighted Material
Part I Mac OS X Basics COPYRIGHTED MATERIAL 995363c01.indd5363c01.indd 1 11/25/09/25/09 44:39:27:39:27 PPMM 995363c01.indd5363c01.indd 2 11/25/09/25/09 44:39:27:39:27 PPMM CHAPTER 1 Mac OS X Architecture This chapter begins by addressing many of the basics of a Mac OS X system. This includes the general architecture and the tools necessary to deal with the architecture. It then addresses some of the security improvements that come with version 10.5 “Leopard”, the most recent version of Mac OS X. Many of these security topics will be discussed in great detail throughout this book. Basics Before we dive into the tools, techniques, and security of Mac OS X, we need to start by discussing how it is put together. To understand the details of Leopard, you need ﬁ rst to understand how it is built, from the ground up. As depicted in Figure 1-1, Mac OS X is built as a series of layers, including the XNU kernel and the Darwin operating system at the bottom, and the Aqua interface and graphical applications on the top. The important components will be discussed in the following sections. 3 995363c01.indd5363c01.indd 3 11/25/09/25/09 44:39:27:39:27 PPMM 4 Part I ■ Mac OS X Basics Applications Safari, Mail, iCal, etc. GUI Aqua Application Environments BSD, X11, Carbon, Cocoa, AWT, Swing Libraries URL parsing, Networking, Core Audio, HTML rendering, etc. Kernel BSD (signals, sockets, etc.) Mach (virtual memory, IPC, etc.) Firmware EFI Hardware Apple hardware Figure 1-1: Basic architecture of a Mac OS X system XNU The heart of Mac OS X is the XNU kernel.
[Show full text]
Magicpairing: Apple's Take on Securing Bluetooth Peripherals
MagicPairing: Apple’s Take on Securing Bluetooth Peripherals Dennis Heinze Jiska Classen Felix Rohrbach Secure Mobile Networking Lab Secure Mobile Networking Lab Cryptoplexity TU Darmstadt, Germany TU Darmstadt, Germany TU Darmstadt, Germany [email protected] [email protected] [email protected] ABSTRACT Most problems originated from the initial key negotiation and con- Device pairing in large Internet of Things (IoT) deployments is a nection setup. In Bluetooth, trust is established on first use by challenge for device manufacturers and users. Bluetooth offers a generating a permanent key. This permanent key protects device comparably smooth trust on first use pairing experience. Bluetooth, authenticity, message integrity, and message confidentiality [7, p. though, is well-known for security flaws in the pairing process. 269]. It is established individually between each pair of devices In this paper, we analyze how Apple improves the security of Blue- and only changes when a user manually deletes and reestablishes tooth pairing while still maintaining its usability and specification a pairing. In Classic Bluetooth, the permanent key is called Link compliance. The proprietary protocol that resides on top of Blue- Key (LK), while it is called Long Term Key (LTK) in Bluetooth Low tooth is called MagicPairing. It enables the user to pair a device Energy (BLE)—however, they can be converted into each other [7, once with Apple’s ecosystem and then seamlessly use it with all p. 280]. For the duration of each Bluetooth connection, a session their other Apple devices. key is derived from the permanent key. Thus, if a device is out of We analyze both, the security properties provided by this protocol, reach or switched off, this invalidates a session key.
[Show full text]
Eternal War in XNU Kernel Objects
Eternal War in XNU Kernel Objects Min(Spark) Zheng, Xiaolong Bai, Hunter Alibaba Orion Security Lab whoami • SparkZheng @ Twitter，蒸米spark @ Weibo • Alibaba Security Expert • CUHK PhD, Blue-lotus and Insight-labs • Gave talks at RSA, BlackHat, DEFCON, HITB, ISC, etc • Xiaolong Bai (bxl1989 @ Twitter&Weibo) • Alibaba Security Engineer • Ph.D. graduated from Tsinghua University • Published papers on S&P, Usenix Security, CCS, NDSS Apple Devices & Jailbreaking • Jailbreaking in general means breaking the device out of its “jail”. • Apple devices (e.g., iPhone, iPad) are most famous “jail” devices among the world. • iOS, macOS, watchOS, and tvOS are operating systems developed by Apple Inc and used in Apple devices. XNU • All systems deploy a same hybrid kernel structure called XNU. • There are cases that kernel vulnerabilities have been used to escalate the privileges of attackers and get full control of the system (hence jailbreak the device). • Accordingly, Apple has deployed multiple security mechanisms that make the exploitation of the device harder. Mitigation - DEP/KASLR • Apple deployed Data Execution Prevention (DEP) and Kernel Address Space Layout Randomization (KASLR) from iOS 6 and macOS 10.8. • DEP enables the system to mark relevant pages of memory as non-executable to prevent code injection attack. To break the DEP protection, code-reuse attacks (e.g., ROP) were proposed. • To make these addresses hard to predict, KASLR memory protection randomizes the locations of various memory segments. To bypass KASLR, attackers usually need to leverage information leakage bugs. Mitigation - Freelist Randomization • In previous XNU, the freelist that contains all the freed kernel objects inside a zone uses the LIFO (last-in-first-out) policy.
[Show full text]
Ios Security Ios 11
iOS Security iOS 11 January 2018 Contents Page 4 Introduction Page 5 System Security Secure boot chain System Software Authorization Secure Enclave Touch ID Face ID Page 12 Encryption and Data Protection Hardware security features File Data Protection Passcodes Data Protection classes Keychain Data Protection Access to Safari saved passwords Keybags Security Certifications and programs Page 22 App Security App code signing Runtime process security Extensions App Groups Data Protection in apps Accessories HomeKit SiriKit HealthKit ReplayKit Secure Notes Shared Notes Apple Watch Page 34 Network Security TLS VPN Wi-Fi Bluetooth Single Sign-on AirDrop security Wi-Fi password sharing Page 39 Apple Pay Apple Pay components How Apple Pay uses the Secure Element How Apple Pay uses the NFC controller Credit, debit, and prepaid card provisioning Payment authorization iOS Security Guide—White Paper | January 2018 2 Transaction-specific dynamic security code Contactless payments with Apple Pay Paying with Apple Pay within apps Paying with Apple Pay on the web or with Handoff Rewards cards Apple Pay Cash Suica Cards Suspending, removing, and erasing cards Page 49 Internet Services Apple ID iMessage FaceTime iCloud iCloud Keychain Siri Continuity Safari Suggestions, Siri Suggestions in Search, Lookup, #images, News App, and News Widget in Non-News Countries Page 64 Device Controls Passcode protection iOS pairing model Configuration enforcement Mobile device management (MDM) Shared iPad Apple School Manager Device Enrollment Apple Configurator 2 Supervision Restrictions Remote Wipe Lost Mode Activation Lock Page 71 Privacy Controls Location Services Access to personal data Privacy policy Page 73 Apple Security Bounty Page 74 Conclusion A commitment to security Page 75 Glossary Page 77 Document Revision History iOS Security Guide—White Paper | January 2018 3 Introduction Apple designed the iOS platform with security at its core.
[Show full text]
Native Execution of Ios Apps on Android
Cider Native Execution of iOS Apps on Android Jeremy Andrus ([email protected]) Alexander Van't Hof, Naser AlDuaij, Christoffer Dall, Nicolas Viennot, Jason Nieh Columbia University In the City of New York March 4, 2014 ASPLOS 2014, Salt Lake City, UT !1 Presentation © 2014, Jeremy C. Andrus Motivation The Goal Presentation © 2014, Jeremy C. Andrus !3 Motivation Virtualization Presentation © 2014, Jeremy C. Andrus !4 Motivation Binary Compatibility Wine API Reimplementation ✤ immense implementation! ✤ 20 years later: still incomplete Presentation © 2014, Jeremy C. Andrus !5 Motivation Overview Binary Compatibility Kernel ABI Compatibility BSD Linux Compatibility ✤ missing kernel subsystem! ✤ opaque driver interfaces Presentation © 2014, Jeremy C. Andrus !6 Motivation Overview Cider : OS Compatibility ✤ Direct execution of unmodiﬁed iOS apps" ✤ Reuse existing libraries" ✤ Reuse existing open source kernel code" ✤ iOS apps can use Android libraries Presentation © 2014, Jeremy C. Andrus !7 Motivation Overview Personas Duct Tape Diplomats Evaluation iOS Android Cider : OS Compatibility ✤ Personas" ➡ distinguish iOS and Linux threads" ✤ Duct Tape" ➡ XNU code in the Linux kernel" ✤ Diplomats" ➡ iOS apps use Android libraries Presentation © 2014, Jeremy C. Andrus !8 Motivation Overview Personas Duct Tape Diplomats Evaluation iOS Android Cider : OS Compatibility XNU syscall Linux syscall Interface Interface Cider Linux Kernel Mach-O Loader Presentation © 2014, Jeremy C. Andrus !9 Motivation Overview Personas Duct Tape Diplomats Evaluation iOS Android Per-Thread Personas XNU syscall Linux syscall Interface Interface Cider Linux Kernel Persona Mach-O Management Loader Presentation © 2014, Jeremy C. Andrus !10 Motivation Overview Personas Duct Tape Diplomats Evaluation iOS Android Cider : OS Compatibility XNU Source XNU syscall Linux syscall Interface Interface Mach IPC Cider Linux Kernel Persona Mach-O Management Loader Presentation © 2014, Jeremy C.
[Show full text]
XNU: a Security Evaluation XNU: a Security Evaluation
XNU: a security evaluation XNU: a security evaluation D Keuper (s1019775) University of Twente and Certified Secure December 13, 2012 Abstract The XNU kernel is the kernel that powers Apple's OS X and iOS operating system. Originally developed by Next, but later acquired by Apple it has been around for more then twenty years. It is only since the introduction of code signing on iOS that hackers have developed a real interest in XNU. Prior to iOS 2.0 only a handful of articles were published on XNU in the context of security. In the past few years the interest of hackers increased by the popularity of jailbreaking (the process of removing the security restrictions of iOS) and iOS security is often discussed at the various security conferences. The interest of hackers in the XNU kernel has not gone unnoticed by Apple, which started to harden the security of their XNU kernel. In the latest releases of their operating systems they added different mitigation techniques such as kernel ASLR. The latest release of OS X (Mountain Lion) and iOS (6) are hardened with new protection mechanisms, which should reduce the risk of successful exploitation. In this thesis we describe all techniques that are meant to protect the kernel from attackers and their implementation. We argue the effectiveness of those techniques and how an attacker might try to circumvent them. We conclude this thesis with a comparison with other kernels, our opinion on the current security state of the XNU kernel and some recommendations on how to further improve the security.
[Show full text]
Macos Hardening Guide
Appendix - Mac OS Security Hardening Guide A MacOS Hardening Guide The default configuration of MacOS remains quite permissive, but it's generally simple to enforce in MacOS a hardened level of security approaching (but still not quite as strong as) that of iOS. Any security hardening may impact performance and usability across the system. It's highly recommended to try these recommendations out gradually on a test system before applying them fully in any production environment. There are many approaches to hardening, and quite a few guides (such as CIS Apple OSX Security Benchmark), including automated tools (e.g. osx-config-check) exist. Most, however, go a little bit overboard in some recommendations (e.g. disabling Javascript in the browser which - while greatly improving security - propels the innocent user into the nostalgic WWW of the 1990s). The recommendations presented here try to greatly enhance the overall security posture, while minimizing user pain and suffering as much as possible. There are also some recommendations here which are overlooked by other common documents. I also tried to focus on "built-in" and "out of box" functions and settings, and stayed away from pointing out Anti- Virus, Anti-Malware, or in general third party products, save from pointing out they exist, where applicable. Because approaches do differ, I originally did not think of adding such a guide to my book. Following a question by Sebastien Volpe, however, I realized it would be a good addition as somewhat of an informal "conclusion" to the book,
[Show full text]