Apple Exclaves के बारे में

 (medium.com/@randomaugustine)
1 पॉइंट द्वारा GN⁺ 2025-03-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple के Exclaves एक isolation feature हैं, जिनका उद्देश्य XNU kernel के compromise होने पर भी कुछ sensitive resources को अलग क्षेत्र में सुरक्षित रखना है; M4 और A18 के लिए XNU source release से इसकी संरचना का कुछ हिस्सा सामने आया
  • XNU Mach-based है, लेकिन वास्तविक system functions उसी privilege boundary में केंद्रित हैं, इसलिए यह monolithic kernel की तरह काम करता है; Exclaves, Secure Enclave, PPL और SPTM से आगे बढ़ती defense-in-depth दिशा पर आधारित हैं
  • Exclaves boot के समय परिभाषित domains और resources से बने होते हैं, और shared memory buffers, audio buffers, sensors, Conclave, services आदि को SPTM के नए page types के जरिए XNU से protect करते हैं
  • Secure Kernel(SK) XNU जैसे ही application processor पर चलता है, और source clues के आधार पर seL4 family तथा ARM TrustZone secure world के उपयोग की संभावना है, लेकिन internal implementation का काफी हिस्सा public नहीं है
  • वास्तविक security effect इस पर निर्भर करता है कि कौन-से components Exclaves में move किए जाते हैं; मौजूदा build images camera/microphone security indicators, Apple Neural Engine के कुछ हिस्सों, कुछ drivers और Secure Enclave communication components के उपयोग की ओर इशारा करती हैं

Monolithic kernel और Apple की isolation मजबूत करने की दिशा

  • Modern operating systems आम तौर पर user mode और kernel mode नाम के दो protection domains में काम करते हैं
    • Applications file access या network communication जैसे high-privilege tasks सीधे नहीं कर सकते, और system calls के जरिए kernel से request करते हैं
    • Kernel access permissions check करने के बाद open file को दर्शाने वाले handle जैसे results user mode में लौटाता है
  • अधिकांश operating systems monolithic kernel architecture इस्तेमाल करते हैं, जिसमें kernel के पास hardware, memory और पूरे user data तक unrestricted access होता है
    • Kernel जितना बड़ा होता है, vulnerabilities पैदा होने की संभावना भी उतनी बढ़ती है
    • Kernel vulnerability का exploitation पूरे system compromise में बदल सकता है
  • Microkernel kernel के अंदर functions को घटाकर अधिकतर tasks को अलग unprivileged processes में भेज सकता है, जिससे security isolation बेहतर हो सकती है
    • Performance issues और application software complexity में बढ़ोतरी इसके drawbacks बने रहते हैं
  • iOS, macOS, tvOS, visionOS और watchOS द्वारा साझा किया जाने वाला XNU Mach microkernel पर आधारित है, लेकिन implementation में कई system functions एक ही privilege boundary में हैं, इसलिए व्यवहार में यह monolithic kernel की तरह काम करता है

Exclaves से पहले Apple security isolation

  • 2013 में iPhone 5s में Secure Enclave introduce किया गया
    • Dedicated hardened CPU core पर SepOS नाम का microkernel-based OS चलता है
    • SepOS का kernel Apple के L4-embedded custom version cL4 पर आधारित है
    • इसका उपयोग encryption keys और Face ID जैसे biometric information को protect करने के लिए होता है
    • iOS kernel compromise होने पर भी, Secure Enclave को target करने वाला अतिरिक्त exploit न हो तो आम तौर पर उस पर असर नहीं पड़ता
    • Secure Enclave और Secure Exclaves अलग-अलग targets हैं
  • 2017 में A11-based iPhone 8 और iPhone X में Page Protection Layer(PPL) introduce हुआ
    • Memory page tables modify करने का अधिकार kernel के केवल कुछ हिस्सों को दिया गया, और बाकी kernel को सीधे modify करने से रोका गया
    • Attack surface छोटा होने के कारण bypass कम थे, लेकिन बाकी kernel के पास अभी भी data compromise के लिए जरूरी कई permissions मौजूद रहे
  • 2021~2023 में A15 और iOS 17 में Secure Page Table Monitor(SPTM) ने PPL को replace और improve किया
    • यह अतिरिक्त memory features को protect करता है और छोटे kernel components के स्तर पर isolation करता है
    • Apple-signed होने की जांच करने वाला code signing verification भी अलग किया गया
    • इसी समय XNU source में exclaves के indirect references दिखे, और तब इसे SPTM द्वारा managed subsystem माना गया

2024 में XNU Exclaves का आगमन

  • M4 और A18-based systems को support करने वाले XNU source release से Exclaves structure का कुछ हिस्सा सामने आया
    • Target में iPhone 16 जैसे systems शामिल हैं
    • पुराने processors पर Exclaves enabled नहीं हैं
  • Exclaves XNU से अलग resources को दर्शाते हैं, और kernel compromise होने पर भी protected region के रूप में design किए गए हैं
    • Resources OS build time पर पहले से define होते हैं
    • इन्हें name या ID से identify किया जाता है
    • इनका type होता है और boot time पर initialize होते हैं
    • ये unique domains में organized होते हैं
  • SPTM Exclave-specific page type के जरिए Exclave memory को XNU से protect करता है
  • Confirmed resource types दिखाते हैं कि XNU और Exclave के बीच boundary कहां बनती है
    • Shared memory buffers, जिन्हें XNU और Exclave दोनों access कर सकते हैं
      • XNU के perspective से इन्हें read-only या read-write के रूप में set किया जा सकता है
    • Camera/microphone access indicators जैसी feature security में इस्तेमाल होने वाले audio buffers और sensors
    • कई resources को अपने security domain में bundle करने वाला Conclave और Conclave Manager
    • ऐसी services जिनमें XNU thread call करने पर Exclave space में code execute हो सकता है

Secure Kernel और secure world

  • Exclave services को XNU से isolated state में execute कराने के लिए Apple ने Secure Kernel(SK) introduce किया
  • SK image file में “cL4” version string शामिल है
    • IPC structure original SepOS cL4 के L4-embedded की तुलना में seL4 के ज्यादा करीब दिखता है
    • SK strings में capability, frame, untyped memory, minting जैसे seL4-family terms अक्सर दिखाई देते हैं
    • Apple ने अप्रैल 2024 में seL4 Foundation में शामिल होने की बात public की
  • SepOS के dedicated processor पर चलने के विपरीत, SK XNU/iOS जैसे ही high-speed application processor पर चलता है
  • इस structure को अतिरिक्त processor privilege level की जरूरत होती है, और possible आधार के रूप में virtualization extensions, Apple के SPTM additional features, और ARM TrustZone का उल्लेख किया जाता है
    • XNU source में TrustZone के secure world transition से जुड़े references हैं
    • इसे ऐसे structure के रूप में समझा जाता है जिसमें XNU और iOS insecure world में, और SK secure world में operate करते हैं
  • SK Exclave, resources और services के लिए limited operating environment देता है
    • यह ARM द्वारा proposed Trusted Applications design pattern से अलग है
    • Exclave services और Secure Kernel का attack surface limited है, इसलिए secure world से escape करके XNU compromise करना, insecure world से सीधे XNU पर attack करने की तुलना में काफी कठिन हो सकता है
  • XNU source में secure world transition को RINGGATE कहा गया है
    • SPTM transition manage कर सकता है—यह हिस्सा केवल अनुमान है, और संबंधित area open source नहीं है, इसलिए binary analysis की जरूरत है

Domains, resources और Conclave

  • XNU boot के दौरान मिले Exclave resource information को रखने के लिए 2-level kernel table structure initialize करता है
    • root_table name से domain identify करता है
    • हर domain उस domain के resources रखने वाली second-level table को reference करता है
  • Confirmed domain structure इस प्रकार है
    • com.apple.kernel
      • इसमें Conclave launcher, debug service, security indicator lights के लिए ExclaveIndicatorController, log service, और ExclaveKit boot में इस्तेमाल होने वाला FrameMint शामिल हैं
      • इसमें shared memory buffer com.apple.storage.backend भी शामिल है, जिसका इस्तेमाल Exclave services upcall के जरिए XNU space में file I/O करने के लिए करती हैं
      • इसमें हर Conclave के लिए एक Conclave Manager resource शामिल है
    • com.apple.darwin
      • Open source components में कोई use case नहीं है
    • com.apple.conclave.name
      • हर Conclave के लिए एक domain मौजूद होता है
      • इसमें services, audio buffers, shared memory buffers आदि शामिल हो सकते हैं
    • com.apple.driver.*name*
      • Comments के आधार पर device-driver-specific domain के रूप में इसके अस्तित्व का उल्लेख है, लेकिन open source code में असल में confirm नहीं हुआ
  • Conclave कई resources रख सकने वाला resource type भी है, और ऐसा security unit भी है जो services और resources को एक-दूसरे तक shared access देता है
    • Mach task के callable Conclaves limited होते हैं
    • हर Conclave में kernel domain में स्थित Conclave Manager होता है
    • Conclave का lifecycle attach, launch, stop, detach जैसे stages रखता है
    • launching, stopping जैसे transition states भी मौजूद हैं

Conclave creation, connection और execution

  • XNU का posix_spawn() task_add_conclave() call करके task और Conclave Manager resource को connect कर सकता है
    • Relationship 1:1 है
    • एक task केवल एक Conclave Manager से connect होता है, और उल्टा भी यही है
  • Conclave spawn कर सकने वाली entity launchd या com.apple.private.exclaves.conclave-spawn entitlement वाला task है
    • com.apple.private.exclaves.conclave-host entitlement को नया task spawn करने के बजाय खुद को attach करने की permission के करीब समझा जाता है
  • Kernel target Conclave से जुड़े Conclave Manager resource को com.apple.kernel domain में खोजता है
    • इसके बाद Conclave resource struct में Conclave Manager endpoint की ओर जाने वाला Tightbeam endpoint store करता है
    • Tightbeam Exclave components के बीच communication के लिए RPC framework जैसा दिखता है
  • Conclave execution connected Conclave Manager task में ही किया जाना चाहिए
    • Launch attempt तब तक wait करता है जब तक Exclaves EXCLAVES_BS_BOOTED_EXCLAVEKIT state तक पूरी तरह boot नहीं हो जाते
    • नया Mach trap _exclaves_ctl_trap() function में enter करता है, और EXCLAVES_CTL_OP_LAUNCH_CONCLAVE Conclave execution के लिए इस्तेमाल होता है
    • Production environment में launched Conclave host tainted state में हो सकता है, और बाद में exit() kernel panic पैदा कर सकता है

Exclaves के लिए नया Mach trap

  • _exclaves_ctl_trap() Exclave features handle करने वाला नया Mach trap है
    • यह operation parameter के आधार पर कई actions perform करता है
    • आम तौर पर called operation के लिए required entitlement verify करता है
  • EXCLAVES_CTL_OP_BOOT system boot के दौरान दो बार call होता है
    • Exclaves boot stage 2 शुरू करना
    • ExclaveKit boot
    • Caller launchd होना चाहिए या उसके पास com.apple.private.exclaves.boot entitlement होना चाहिए
  • बाकी प्रमुख operations के लिए कम से कम current task के पास com.apple.private.exclaves.kernel-domain entitlement होना चाहिए या वह संबंधित Conclave Manager task होना चाहिए
    • EXCLAVES_CTL_OP_LOOKUP_SERVICES: current task के Exclave domain में services खोजता है, और fail होने पर permissions के अनुसार Darwin domain और kernel domain check करता है
    • EXCLAVES_CTL_OP_ENDPOINT_CALL: current task domain के Exclave service endpoint को call करता है, जिससे current thread secure world में transition होकर specific code execute करता है
    • named buffer creation और copyin/copyout
    • audio buffer creation और copyout
    • sensor creation, start, stop, status
    • notification resource lookup

Downcall और Upcall

  • Downcall secure world में मौजूद Exclave service endpoint call है, और यही secure world code execution शुरू होने की जगह है
  • Downcall current thread को secure world में transition करता है और secure code के entry point से execution शुरू करता है
    • यह किसी दूसरे thread को work hand off करने वाला तरीका नहीं है
    • Calling task के पास kernel domain entitlement होना चाहिए या वह उस service Conclave से connected Conclave Manager task होना चाहिए
    • Conclave अधिकतम 128 callable services रख सकता है
  • XNU sk_enter() के जरिए thread को Secure Kernel पर schedule करता हुआ दिखता है
    • संभव है कि SK के independent threads न हों, और XNU secure world के सभी thread scheduling को handle करता हो
    • Secure world में चल रहा thread yield, wait, suspend, interrupt जैसे सामान्य scheduler actions कर सकता है
    • इस स्थिति में thread secure world छोड़कर XNU kernel context में लौटता है, और बाद में Exclave scheduling code द्वारा फिर से secure world में schedule किया जाता है
  • Downcall का IPC structure secure world में enter करने से पहले request/response buffers के रूप में set होता है
    • Final IPC request structure तैयार करने और sk_enter() call करने के दौरान interrupts और preemption disabled रहते हैं
    • ऐसा इसलिए है क्योंकि यह structure हर CPU core पर केवल एक होता है
    • Downcall response interrupt, upcall, yield, rescheduling के कारण किसी दूसरे CPU के per-core response buffer में लौट सकता है
  • Upcall वह तरीका है जिसमें secure world में चल रहा thread XNU की मदद चाहिए होने पर Tightbeam के जरिए Exclaves upcall handler को call करता है
    • यह allowed specific XNU functions तक सीमित है
    • Upcall में मौजूद thread user mode में वापस नहीं जा सकता
    • Secure world में फिर से downcall करके re-enter करना भी allowed नहीं है
    • Thread को उसी point के secure world context में लौटना होता है जहां से उसने upcall किया था
  • Source में confirmed upcall categories memory, file storage, DriverKit, DriverKit Apple Neural Engine, और Conclave control हैं

XNUProxy और boot stages

  • XNUProxy के references बहुत हैं, लेकिन इसकी exact location और role तय नहीं है
    • यह independent Exclave domain हो सकता है
    • com.apple.kernel domain में specific downcalls handle करने वाली service या service bundle हो सकता है
    • Secure world में downcall perform करने वाला SPTM subsystem भी हो सकता है
  • Exclaves_L4.h comment कहता है कि XNU Proxy कई Exclaves को reachable बनाता है
    • user app template
    • audio driver
    • ExclaveDriverKit
    • Always On Processor और Display Coprocessor के लिए SecureRTBuddy
    • Conclave control, Conclave debug आदि
  • Exclaves boot को insecure world और secure world के बीच coordination चाहिए, और problem आने पर आम तौर पर panic() तक जाता है
  • Boot तीन stages में बंटा है
    • Stage 1 open source में नहीं दिखता, और संभव है कि यह secure boot process हो जो SK को memory में load करता है, code signing verify करता है, और उसे executable बनाता है
    • Stage 2 upcall server initialization, secure kernel boot information collection, Exclave scheduler initialization, XrtHostedXNU kext initialization, multicore initialization, XNU Proxy initialization, static Exclave resource discovery, Conclave Manager endpoint creation आदि करता है
    • Stage 3 com.apple.service.FrameMint service खोजता है, framemint_framemint__init(), framemint_framemint_populate() से जुड़े calls perform करता है, और फिर EXCLAVES_BS_BOOTED_EXCLAVEKIT state में जाता है

SPTM memory types और बाकी limitations

  • SPTM subsystem-wise access control के लिए memory pages को type assign करता है
    • Existing types में XNU_USER_EXEC, XNU_USER_DEBUG, XNU_USER_JIT, XNU_ROZONE, XNU_KERNEL_RESTRICTED, TXM/DART-related types आदि हैं
  • Exclaves नए SK-related types add करते हैं
    • SK_DEFAULT: केवल SK के लिए, XNU access नहीं
    • SK_IO: केवल SK के लिए, XNU access नहीं
    • SK_SHARED_RO: SK और XNU shared, लेकिन XNU के लिए read-only
    • SK_SHARED_RW: SK और XNU shared, और XNU के लिए read-write allowed
  • Exclaves को Apple operating systems में defence in depth add करने के लिए बड़ा investment माना जा सकता है
    • Sensitive resources isolate करके potential attack surface घटाते हैं
    • Single kernel compromise के impact को कम करने की दिशा है
  • असल में कौन-से components kernel से Exclaves में move होते हैं, इसका direct analysis नहीं किया गया है
    • Build images security camera/microphone indicators, Apple Neural Engine की कुछ functionality, कुछ device drivers, और Secure Enclave से communication करने वाले components के उपयोग की ओर इशारा करती हैं
    • भविष्य में और components Exclaves में move हो सकते हैं
    • Exclaves के बाहर का XNU area अभी भी attack target है
  • Analysis Apple Open Source XNU build 11215 पर आधारित है
    • ExclaveKit, ExclaveDriverKit, XNUProxy की exact location, XNU का secure world transition method, Secure Kernel, और secure world userspace ऐसे areas हैं जिनके लिए आगे analysis की जरूरत है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-03-10
Hacker News की राय

  • Apple के हालिया फोन और लैपटॉप SoC में nested virtualization hardware support शामिल है, जिसमें camera LED के लिए exclave इस्तेमाल करने वाला M4 iPad Pro भी शामिल है
    उम्मीद है कि Apple Platform Security guide के अगले संशोधन में SK exclave और Wi‑Fi radar detection के लिए baseband mitigations को कवर किया जाएगा: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
    Apple के SPTM additions पर SPTM reverse engineering का एक लेख भी है: https://www.df-f.com/blog/sptm3
    XNU को microkernel-प्रेरित architecture के रूप में refactor किया जा रहा है, code base को घटाते हुए security-sensitive कामों को बाहर ले जाने की दिशा में। Memory space isolation में Secure Page Table Monitor(SPTM) मदद करता है, और code signing, entitlement verification, Developer Mode, Restricted Execution Mode जैसे काम Trusted eXecution Monitor(TXM) संभालता है
    TrustZone से जुड़े CVE 150 से ज्यादा हैं: https://www.cve.org/CVERecord/SearchResults?query=trustzone
    Google ने भी कुछ साल पहले Pixel में hardware nested virtualization इस्तेमाल करने वाला pKVM लागू किया था, और pKVM L0 की तुलना में TrustZone privileges को cooperative तरीके से घटाने वाला code भी Linux mainline में डाला था। हालांकि Debian “Linux Terminal” VM के अलावा pKVM/AVF का इस्तेमाल करने वाली defensive features की घोषणा नहीं की गई

    • TrustZone CVE में से ज्यादातर उन vulnerable software से जुड़े हैं जिन्हें manufacturers ने TrustZone protected environment में डाला था। ऐसे software में बहुत कुछ बेहद खराब भी है, और hardware-level vulnerability reports बहुत कम हैं
    • लेखक ने follow-up लेख और संशोधित diagram डाला है: https://randomaugustine.medium.com/more-speculation-on-excla...
      शुरू में TrustZone के उपयोग का अनुमान लगाया गया था, लेकिन exclave मौजूदा SPTM और GXF(Guarded Execution) privilege levels का भी इस्तेमाल कर सकता है। अगर ऐसा है, तो RAM requirements और development effort को छोड़ दें, तो iPhone 13 और उससे ऊपर पर support न कर पाने की कोई बुनियादी वजह नहीं हो सकती। बेशक Apple के लिए भी यह बहुत बड़ा काम है

  • Steve सचमुच मानते थे कि “laptop किसी व्यक्ति की diary है”, और Apple की जिम्मेदारी है कि वह उसकी रक्षा करे
    लगता है Tim भी Steve जैसी ही आस्था न रखते, तो CEO नहीं बन पाते। अजीब लग सकता है, लेकिन Steve सच में याद आते हैं
    https://www.youtube.com/watch?v=Ij-jlF98SzA

    • Industrial और scientific equipment बनाने वाले के नजरिए से Apple के consumer-oriented devices पूरी तरह बेकार हैं। पर्याप्त सक्षम computing devices को इस तरह lock down कर देना बर्बादी जैसा लगता है
      Device ownership बदल जाने के बाद भी Apple जिस तरह device और software market को control करता है, वह भी पसंद नहीं है। मैं ऐसे ecosystem से पूरी तरह बचता हूं, और समझ नहीं आता कि इतने सारे तथाकथित “hackers” उन systems पर क्यों फिदा हैं जिनका bonnet वेल्ड करके बंद कर दिया गया है
    • Jobs divisive थे और अक्सर रूखे भी, और शुरुआत में ही सवाल उठता है कि किसी tech billionaire को याद क्यों किया जाए। फिर भी Mac, iPod, iPad जैसे पसंदीदा products बनाने में योगदान देने वाले Jobs और Apple के लोगों के प्रति एक तरह का ऋण महसूस होता है
      Jobs की कही कई बातें आज भी असर करती हैं। हाल में Apple ने “classic Mac” screen saver निकाला, जो दिखाता है कि मूल Mac GUI कितनी बारीकी से design किया गया था। उन दिनों को कोई याद नहीं करेगा जब app bugs operating system को crash कर देते थे, लेकिन काश Apple आज भी उतनी ही details के प्रति obsession रखता
    • Jobs के लिए लोगों की सच्ची भावनाएं देखकर सोचता हूं कि क्या LLM इस्तेमाल और अनुभव करते समय भी कुछ वैसा ही काम करता है
      थोड़ा साफ कहूं तो इसमें कोई mystical या religious तत्व लगता है। जैसे कोई चमत्कार, oracle, सुंदर products और rituals, और एक smooth, समृद्ध, eternal future देने वाले ईश्वर-जैसे दयालु पुरुष की तीव्र चाह हो। मानो किसी तरह का आध्यात्मिक “hole” भर रहा हो
      Jobs या LLM को पसंद करने वालों को नीचा दिखाने का इरादा नहीं है, बस अपना observation साझा कर रहा हूं
    • समझ आता है कि exclave वाला लेख Steve के बारे में विचार ले आया, लेकिन एक बात दूसरी तक कैसे पहुंची, यह ठीक से समझ नहीं आया। क्या समझा सकते हैं?

  • संबंधित thread: “Apple rearranged its XNU kernel with exclaves” https://news.ycombinator.com/item?id=43314171

    • उस लेख के summary के मुताबिक exclave का मतलब main kernel यानी XNU से अलग किए गए specific resources है, और बताया गया है कि kernel compromise होने पर भी उन तक पहुंच नहीं हो सकती
      यह भी कहा गया है कि macOS की intermediate releases में अगले major version की तैयारी वाली features आना असामान्य नहीं है, और Sonoma 14.4, iOS 17.4, iPadOS 17.4, watchOS 10.4 में जोड़ी गई सबसे fundamental और important feature exclave हो सकती है
      https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

  • भौतिक कैमरा LED control के लिए secure exclave का इस्तेमाल करना काफी हैरान करने वाला है, और ऐसा लगता है जैसे एक सरल काम के लिए ज़रूरत से ज़्यादा जटिल design किया गया हो
    लगता है कैमरा module में बहुत छोटा dedicated hardware logic डालना ही काफी होता। Digital input/output या कैमरा power को gate किया जा सकता था, और ऐसे attacks रोकने के लिए कि कैमरा logic को तेजी से on/off किया जाए, एक pulse stretcher रखा जा सकता था ताकि LED हर बार कम से कम कुछ seconds तक on रहे
    microphone के लिए भी इसी तरह का circuit और अलग रंग की physical LED होना अच्छा होगा। Screen पर software से दिखने वाला dot भर काफी नहीं है

    • यह जितना दिखता है उससे ज्यादा जटिल है। “Camera” कई components का bundle है। आप CMOS sensor power को आधार बनाना चाहेंगे, लेकिन standby, power-saving, idle जैसे कई power stages होते हैं। इसलिए hardware circuit को शायद voltage के साथ-साथ current भी जानना पड़े। या फिर ऊपर के level पर I2C जैसे messages parse करके power mode change पढ़ना पड़ सकता है
      LED driver को भी screen brightness या ambient light sensor की जानकारी चाहिए। Direct sunlight में दिखने लायक bright होना चाहिए, लेकिन वही brightness अंधेरे माहौल में असहज हो सकती है और normal camera use में बाधा डाल सकती है
      अगर आप मानते हैं कि SK सुरक्षित है, तो उसे इस्तेमाल करना ज्यादा सरल और बेहतर हो सकता है। अगर SK सुरक्षित नहीं है, तो वैसे भी सारी assumptions टूट जाती हैं
    • यह over-engineering नहीं है। ऐसी research और Charlie Miller जैसे अन्य researchers के findings की वजह से इसकी जरूरत है
      Apple आम तौर पर बिना valid reason चीजों को जानबूझकर जटिल नहीं बनाता
      https://news.ycombinator.com/item?id=42260379
    • सोच रहा हूँ कि यह over-engineering है, या फिर बहुत बड़ी संख्या में phones ship करते हुए मिली किसी चीज का समाधान है। मैंने camera को security vector के तौर पर नहीं सोचा था, लेकिन शायद Apple ऐसा सोचता हो
    • संबंधित background यहाँ और विस्तार से है: https://news.ycombinator.com/item?id=42260379
    • लगता है बात सिर्फ camera LED की नहीं है, बल्कि जब कोई app microphone, camera या screen recording access करता है तो menu bar में दिखने वाले orange, green, blue dots जैसे screen indicators भी इससे जुड़े हैं

  • जानना चाहूँगा कि यह लेखक कौन है। लेख बहुत परिष्कृत और अच्छी तरह लिखा गया है, और exclave को follow कर रहे व्यक्ति के नजरिए से भी अच्छी तरह व्यवस्थित है

  • यह Linux के Virtualization Based Security से कैसे compare होता है, यह जानना चाहूँगा
    जिस page पर video है उसके अनुसार, यह security feature kernel को harden करता है और kernel compromise होने पर भी important kernel resources में छेड़छाड़ न हो यह guarantee कर सकता है। VBS hardware virtualization और hypervisor Hyper‑V का उपयोग करके higher trust level, Virtual Trust Level 1(VTL1), में चलने वाला isolated virtual environment बनाता है, और VTL1 के पास Guest kernel से अलग अपना kernel, Secure Kernel, होता है
    https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

    • Exclave parallel trust level में चलता है

  • Exclave महत्वपूर्ण है, लेकिन intermediate step जैसा लगता है। Apple XNU को कम risky बना रहा है, लेकिन microkernel architecture को पूरी तरह अपनाने के बजाय अभी defensive तरीके से आगे बढ़ रहा है
    अगर शर्त लगानी हो तो मुझे लगता है exclave किसी बड़े बदलाव की ओर एक bridge है। यह Fuchsia जैसा ज्यादा modular operating system भी हो सकता है, या hardware level पर memory safety enforce करने वाला CHERI-style security model भी
    Apple consumer operating system security में आगे है, लेकिन exclave system design को पूरी तरह नए सिरे से सोचने का परिणाम कम और patchwork-style सुधार ज्यादा लगता है। फिर भी पिछले 10 सालों में mainstream operating system design में यह शायद सबसे बड़ा security change है, और इसका पूरा असर सामने आने में कुछ साल लगेंगे

    • यह पुराने microkernel की ओर लौटने जैसा लगता है। फर्क इतना है कि इसमें modern solutions और नई requirements को शामिल किया गया है
      जब Mach बनाया गया था, तब security आज जितनी बड़ी चिंता नहीं थी। आज की machines इतनी powerful हैं कि microkernel processes के बीच communication से बनने वाला overhead शायद negligible हो गया हो

  • मैं इस level की चीजों से परिचित नहीं हूँ, लेकिन देखने में ऐसा लगता है कि enclave itself पर attack करके kernel से भी higher privilege तक escalate किया जा सकता है। सोच रहा हूँ कि क्या hardware का यह हिस्सा किसी co-processor जैसा है

    • Exclave hardware नहीं है, बल्कि isolated software है जो ऐसे specific sensitive tasks संभालता है जिन तक kernel की access नहीं होनी चाहिए
      इसलिए इसे exploit करने पर kernel के पास न होने वाली access मिलना सही है। लेकिन यही तो intent है। लक्ष्य यह है कि kernel compromise हो जाए तब भी उस sensitive area तक access न मिले

  • Apple documentation के अनुसार SPTM इस्तेमाल नहीं होता, इसलिए सोच रहा हूँ कि इसका macOS security पर क्या असर होगा: https://support.apple.com/guide/security/operating-system-in...
    फिलहाल camera indicator दिखाने वाले existing exclave जैसी चीजें macOS पर ज्यादा लागू नहीं लगतीं, क्योंकि MacBook में dedicated hardware है। लेकिन आगे चलकर macOS पर भी लागू होने वाले exclave आ सकते हैं

    • उस footnote को फिर से पढ़ना चाहिए। इसमें लिखा है कि Page Protection Layer(PPL) और Secure Page Table Monitor(SPTM), macOS को छोड़कर सभी platforms पर signed और trusted code execution enforce करते हैं। क्योंकि macOS arbitrary code चलाने के लिए design किया गया है। Page table protection सहित अन्य security properties सभी supported platforms पर मौजूद हैं
      यानी इसका मतलब यह नहीं कि macOS SPTM इस्तेमाल नहीं करता। मतलब यह है कि macOS unsigned code execution रोकने के लिए SPTM का इस्तेमाल नहीं करता। क्योंकि macOS में users को कुछ steps के बाद unsigned code भी चला पाने की सुविधा होनी चाहिए

  • यह जानने की उत्सुकता है कि क्या ऐप डेवलपर Exclave इस्तेमाल कर सकते हैं। Apple अक्सर अंदरूनी तौर पर कमाल के नए फीचर बनाता है और फिर डेवलपर्स के लिए उन्हें पूरी तरह बंद रखता है, यह बात खलती है। नतीजा यह होता है कि banking apps, wallets, secure messengers जैसी चीज़ों को अब भी कम सुरक्षित user space में ही चलना पड़ता है

    • ज़रूरी नहीं कि ऐसा ही हो। Apple का user space भी लगातार ज़्यादा सुरक्षित होता गया है
      एक सरल उदाहरण के तौर पर, हाल के macOS में ऐप्स स्पष्ट रूप से न चुनें तब भी सभी ऐप्स sandbox के अंदर चलते हैं। यह sandbox ऐप्स को एक-दूसरे की फ़ाइलें संशोधित करने से रोकता है, जबकि पहले यह हिस्सा security system की बड़ी कमजोरी था। वजह यह थी कि bundle signature सिर्फ़ पहली बार launch पर जाँचा जाता था, हर run पर नहीं
    • मेरी समझ के अनुसार मौजूदा design में यह संभव नहीं है। Exclave पूरे operating system में integrated है और boot process के हिस्से के रूप में शुरू होता है, इसलिए यह अपेक्षाकृत static है। सुरक्षा कारणों से इन components के relationships भी संभवतः static रूप से तय हैं
      अभी यह kernel-to-kernel architecture भी है, इसलिए अगर third-party support हो भी, तो वह संभवतः security device driver जैसी चीज़ implement करने तक सीमित रहेगा। लेकिन Apple third-party drivers को hypervisor के बजाय user space में धकेलने की कोशिश करता रहा है। यह transition exclave development के साथ-साथ चल रहा है, इसे देखते हुए ऐसा नहीं लगता कि Apple third-party driver developers को exclave इस्तेमाल कराने की दिशा में जाएगा
      Apple के लिए ऐसी kernel-enforced platform features को बाहर सार्वजनिक करने से पहले internally बहुत अधिक स्थिर करना आम बात है। arm64e का pointer authentication भी ऐसा ही एक उदाहरण है
    • फिलहाल नहीं