; Example: indirect function pointer stored in a struct ; suppose X1 contains a function pointer PACDA X1, X2 ; sign data pointer X1 with context X2 STR X1, [X0] ; store signed pointer

; later retrieval: LDR X1, [X0] AUTDA X1, X2 ; authenticate & strip BLR X1 ; branch to valid target

; Example: stripping for comparison (unsafe) LDR X1, [X0] XPACI X1 ; strip PAC (instruction domain) CMP X1, #some_label_address BEQ matched_label

</details>

<details>
<summary>Example</summary>
Ένα buffer overflow αντικαθιστά μια return address στο stack. Ο επιτιθέμενος γράφει την target gadget address αλλά δεν μπορεί να υπολογίσει το σωστό PAC. Όταν η συνάρτηση επιστρέφει, η εντολή `AUTIA` της CPU προκαλεί σφάλμα λόγω ασυμφωνίας PAC. Η αλυσίδα αποτυγχάνει.
Η ανάλυση του Project Zero για το A12 (iPhone XS) έδειξε πώς χρησιμοποιείται το Apple PAC και μεθόδους πλαστογράφησης PACs αν ένας attacker διαθέτει memory read/write primitive.
</details>


### 9. **Branch Target Identification (BTI)**
**Εισήχθη με ARMv8.5 (πιο πρόσφατο hardware)**
Το BTI είναι ένα hardware χαρακτηριστικό που ελέγχει τα **indirect branch targets**: κατά την εκτέλεση `blr` ή indirect calls/jumps, ο στόχος πρέπει να αρχίζει με ένα **BTI landing pad** (`BTI j` ή `BTI c`). Το άλμα σε gadget addresses που δεν έχουν το landing pad προκαλεί exception.

Η υλοποίηση του LLVM σημειώνει τρεις παραλλαγές των BTI εντολών και πώς αντιστοιχίζονται σε τύπους branch.

| BTI Variant | What it permits (which branch types) | Typical placement / use case |
|-------------|----------------------------------------|-------------------------------|
| **BTI C** | Targets of *call*-style indirect branches (e.g. `BLR`, or `BR` using X16/X17) | Put at entry of functions that may be called indirectly |
| **BTI J** | Targets of *jump*-style branches (e.g. `BR` used for tail calls) | Placed at the beginning of blocks reachable by jump tables or tail-calls |
| **BTI JC** | Acts as both C and J | Can be targeted by either call or jump branches |

- Σε κώδικα που έχει compile-αριστεί με branch target enforcement, οι compilers εισάγουν μια BTI εντολή (C, J, ή JC) σε κάθε έγκυρο indirect-branch target (αρχές συναρτήσεων ή blocks προσβάσιμα με jumps) ώστε τα indirect branches να επιτυγχάνονται μόνο σε αυτά τα σημεία.
- Οι **direct branches / calls** (π.χ. fixed-address `B`, `BL`) **δεν περιορίζονται** από το BTI. Η υπόθεση είναι ότι οι code pages είναι trusted και ο attacker δεν μπορεί να τις αλλάξει (άρα τα direct branches θεωρούνται ασφαλή).
- Επίσης, οι **RET / return** εντολές γενικά δεν περιορίζονται από το BTI επειδή οι return addresses προστατεύονται μέσω PAC ή μηχανισμών return signing.

#### Mechanism and enforcement

- Όταν η CPU αποκωδικοποιεί ένα **indirect branch (BLR / BR)** σε μια σελίδα που είναι σημασμένη ως “guarded / BTI-enabled,” ελέγχει αν η πρώτη εντολή στον target address είναι έγκυρο BTI (C, J ή JC όπως επιτρέπεται). Αν όχι, συμβαίνει **Branch Target Exception**.
- Η κωδικοποίηση της BTI εντολής σχεδιάστηκε ώστε να επαναχρησιμοποιεί opcodes που προηγουμένως προορίζονταν για NOPs (σε παλαιότερες ARM εκδόσεις). Έτσι, τα BTI-enabled binaries παραμένουν backward-compatible: σε hardware χωρίς BTI υποστήριξη, αυτές οι εντολές λειτουργούν ως NOPs.
- Τα compiler passes που προσθέτουν BTIs τα εισάγουν μόνο όπου είναι απαραίτητο: σε συναρτήσεις που μπορεί να κληθούν indirectly, ή σε basic blocks που στοχεύονται από jumps.
- Κάποιες patches και κώδικας του LLVM δείχνουν ότι το BTI δεν εισάγεται για *όλα* τα basic blocks — μόνο για αυτά που είναι πιθανοί branch targets (π.χ. από switch / jump tables).

#### BTI + PAC synergy

Το PAC προστατεύει την τιμή του pointer (πηγή) — εξασφαλίζει ότι η ακολουθία των indirect calls / returns δεν έχει παραποιηθεί.

Το BTI εξασφαλίζει ότι ακόμα και ένας έγκυρος pointer πρέπει να στοχεύει μόνο σημειωμένα entry points.

Σε συνδυασμό, ένας attacker χρειάζεται και έναν έγκυρο pointer με σωστό PAC και το target να έχει τοποθετημένο BTI. Αυτό αυξάνει το βαθμό δυσκολίας στην κατασκευή exploit gadgets.

#### Example


<details>
<summary>Example</summary>
Ένα exploit προσπαθεί να κάνει pivot σε gadget στο `0xABCDEF` που δεν ξεκινά με `BTI c`. Η CPU, κατά την εκτέλεση `blr x0`, ελέγχει τον στόχο και προκαλεί σφάλμα επειδή η αρχή της εντολής δεν περιλαμβάνει έγκυρο landing pad. Επομένως πολλά gadgets γίνονται μη χρησιμοποιήσιμα εκτός αν έχουν το BTI prefix.
</details>


### 10. **Privileged Access Never (PAN) & Privileged Execute Never (PXN)**
**Εισήχθη σε πιο πρόσφατες επεκτάσεις ARMv8 / υποστήριξη σε iOS (για hardened kernel)**

#### PAN (Privileged Access Never)

- Το **PAN** είναι ένα χαρακτηριστικό εισαγμένο στο **ARMv8.1-A** που αποτρέπει τον **privileged code** (EL1 ή EL2) από το να **διαβάζει ή γράφει** μνήμη που έχει σημασθεί ως **user-accessible (EL0)**, εκτός αν το PAN απενεργοποιηθεί ρητά.
- Η ιδέα: ακόμα κι αν ο kernel παραβιαστεί, δεν μπορεί αυθαίρετα να dereference-άρει user-space pointers χωρίς πρώτα να *καθαρίσει* το PAN, μειώνοντας τους κινδύνους από `ret2usr` style exploits ή κακή χρήση buffer που ελέγχεται από χρήστη.
- Όταν το PAN είναι ενεργοποιημένο (PSTATE.PAN = 1), οποιαδήποτε privileged load/store εντολή που προσπελαύνει μια virtual address που είναι “accessible at EL0” προκαλεί **permission fault**.
- Ο kernel, όταν πρέπει νόμιμα να προσπελάσει user-space memory (π.χ. copy data to/from user buffers), πρέπει **προσωρινά να απενεργοποιήσει το PAN** (ή να χρησιμοποιήσει “unprivileged load/store” εντολές) για να επιτρέψει την πρόσβαση αυτή.
- Σε Linux σε ARM64, η υποστήριξη PAN εισήχθη περίπου το 2015: patches στον kernel πρόσθεσαν ανίχνευση του feature και αντικατέστησαν `get_user` / `put_user` κ.λπ. με παραλλαγές που καθαρίζουν το PAN γύρω από προσβάσεις σε user memory.

**Κύρια λεπτομέρεια / περιορισμός / bug**
- Όπως επισήμαναν ο Siguza και άλλοι, ένα σφάλμα σε specification (ή ασαφής συμπεριφορά) στο σχεδιασμό του ARM σημαίνει ότι οι **execute-only user mappings** (`--x`) μπορεί **να μην ενεργοποιούν το PAN**. Με άλλα λόγια, αν μια user page είναι σημασμένη ως executable χωρίς read permission, η προσπάθεια ανάγνωσης από τον kernel μπορεί να παρακάμψει το PAN επειδή η αρχιτεκτονική θεωρεί ότι “accessible at EL0” απαιτεί read δικαίωμα, όχι μόνο execute. Αυτό οδηγεί σε PAN bypass σε ορισμένες υλοποιήσεις.
- Εξαιτίας αυτού, αν το iOS / XNU επιτρέπει execute-only user pages (όπως σε κάποιες JIT ή code-cache ρυθμίσεις), ο kernel μπορεί κατά λάθος να διαβάσει από αυτές ακόμη και με ενεργό PAN. Αυτό είναι γνωστό λεπτό εκμεταλλεύσιμο σημείο σε μερικά ARMv8+ συστήματα.

#### PXN (Privileged eXecute Never)

- Το **PXN** είναι ένα flag στον page table (στα page table entries, leaf ή block entries) που υποδεικνύει ότι η σελίδα **δεν είναι εκτελέσιμη όταν τρέχει σε privileged mode** (δηλ. όταν εκτελείται στο EL1).
- Το PXN αποτρέπει τον kernel (ή οποιονδήποτε privileged κώδικα) από το να κάνει jump ή να εκτελέσει εντολές από user-space pages ακόμη και αν ο έλεγχος ροής αποκλίνει. Στην ουσία, εμποδίζει το kernel-level control-flow redirection προς user memory.
- Σε συνδυασμό με το PAN, αυτό εξασφαλίζει ότι:
1. Ο kernel δεν μπορεί (κατά προεπιλογή) να διαβάσει ή να γράψει user-space δεδομένα (PAN)
2. Ο kernel δεν μπορεί να εκτελέσει user-space κώδικα (PXN)
- Στο ARMv8 page table format, τα leaf entries έχουν bit `PXN` (και επίσης `UXN` για unprivileged execute-never) στα attribute bits τους.

Έτσι, ακόμη κι αν ο kernel έχει διεφθαρμένο function pointer που δείχνει σε user memory και επιχειρήσει να branch εκεί, το PXN bit θα προκαλέσει fault.

#### Memory-permission model & how PAN and PXN map to page table bits

Για να κατανοήσετε πώς δουλεύουν PAN / PXN, πρέπει να δείτε το μοντέλο μετάφρασης και αδειών του ARM (απλοποιημένο):

- Κάθε page ή block entry έχει attribute πεδία που περιλαμβάνουν τα **AP[2:1]** για access permissions (read/write, privileged vs unprivileged) και τα **UXN / PXN** bits για execute-never περιορισμούς.
- Όταν το PSTATE.PAN = 1 (ενεργοποιημένο), το hardware εφαρμόζει τροποποιημένη σημασιολογία: privileged προσβάσεις σε σελίδες που χαρακτηρίζονται ως “accessible by EL0” (δηλ. user-accessible) απαγορεύονται (fault).
- Λόγω του αναφερόμενου bug, σελίδες που είναι σημασμένες μόνο ως executable (χωρίς read permission) μπορεί να μην μετριούνται ως “accessible by EL0” σε ορισμένες υλοποιήσεις, άρα να παρακάμπτουν το PAN.
- Όταν το PXN bit μιας σελίδας είναι set, ακόμη κι αν το fetch εντολής προέρχεται από υψηλότερο privilege level, η εκτέλεση απαγορεύεται.

#### Kernel usage of PAN / PXN in a hardened OS (e.g. iOS / XNU)

Σε ένα hardened kernel design (όπως πιθανώς χρησιμοποιεί η Apple):

- Ο kernel ενεργοποιεί το PAN ως προεπιλογή (έτσι ο privileged κώδικας περιορίζεται).
- Σε μονοπάτια που νόμιμα χρειάζεται να διαβάσει/γράψει user buffers (π.χ. syscall buffer copy, I/O, read/write user pointer), ο kernel προσωρινά **απενεργοποιεί το PAN** ή χρησιμοποιεί ειδικές εντολές για override.
- Μετά το πέρας της πρόσβασης στα user δεδομένα, πρέπει να επανενεργοποιεί το PAN.
- Το PXN επιβάλλεται μέσω page tables: οι user pages έχουν PXN = 1 (έτσι ο kernel δεν μπορεί να τις εκτελέσει), οι kernel pages δεν έχουν PXN (έτσι ο kernel κώδικας μπορεί να εκτελεστεί).
- Ο kernel πρέπει να διασφαλίζει ότι κανένα code path δεν οδηγεί σε εκτέλεση μέσα σε user memory regions (που θα παρακάμπτει το PXN) — επομένως οι exploit chains που βασίζονται σε “jump into user-controlled shellcode” μπλοκάρονται.

Εξαιτίας του PAN bypass μέσω execute-only pages, σε ένα πραγματικό σύστημα η Apple μπορεί να απαγορεύει execute-only user pages ή να εφαρμόζει patches γύρω από την ασθενή πλευρά της προδιαγραφής.

#### Attack surfaces, bypasses, and mitigations

- **PAN bypass via execute-only pages**: όπως συζητήθηκε, η προδιαγραφή αφήνει ένα κενό: user pages με execute-only (χωρίς read perm) μπορεί να μην θεωρούνται “accessible at EL0,” έτσι το PAN δεν θα εμποδίσει kernel reads σε αυτές σε ορισμένες υλοποιήσεις. Αυτό δίνει στον attacker μια ασυνήθιστη οδό να περάσει δεδομένα μέσω “execute-only” τμημάτων.
- **Temporal window exploit**: αν ο kernel απενεργοποιεί το PAN για παράθυρο μεγαλύτερο από το απαραίτητο, μια race ή κακόβουλος δρόμος μπορεί να εκμεταλλευτεί αυτό το παράθυρο για να πραγματοποιήσει ανεπιθύμητη πρόσβαση σε user memory.
- **Forgotten re-enable**: αν κάποιο code path ξεχάσει να επανενεργοποιήσει το PAN, επακόλουθες kernel ενέργειες μπορεί να προσπελάσουν λανθασμένα user memory.
- **Misconfiguration of PXN**: αν οι page tables δεν θέσουν PXN στις user pages ή χαρτογραφήσουν λάθος user code pages, ο kernel μπορεί να εξαπατηθεί να εκτελέσει user-space κώδικα.
- **Speculation / side-channels**: ανάλογα με speculative bypasses, μπορεί να υπάρξουν microarchitectural παρενέργειες που προκαλούν παροδική παράκαμψη των PAN / PXN ελέγχων (παρόλο που τέτοιες επιθέσεις εξαρτώνται πολύ από το design της CPU).
- **Complex interactions**: σε πιο προηγμένες λειτουργίες (π.χ. JIT, shared memory, code-cache regions), ο kernel χρειάζεται λεπτομερή έλεγχο για να επιτρέψει ορισμένες προσβάσεις ή εκτέλεση σε user-mapped περιοχές· το σχεδιασμό αυτού με ασφάλεια κάτω από PAN/PXN περιορισμούς είναι μη-τρивιαλ.

#### Example

<details>
<summary>Code Example</summary>
Εδώ υπάρχουν ενδεικτικές pseudo-assembly ακολουθίες που δείχνουν το enabling/disabling του PAN γύρω από πρόσβαση σε user memory, και πώς μπορεί να προκύψει fault.
</details>
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">  </span></div>

// Suppose kernel entry point, PAN is enabled (privileged code cannot access user memory by default)

; Kernel receives a syscall with user pointer in X0 ; wants to read an integer from user space mov X1, X0 ; X1 = user pointer

; disable PAN to allow privileged access to user memory MSR PSTATE.PAN, #0 ; clear PAN bit, disabling the restriction

ldr W2, [X1] ; now allowed load from user address

; re-enable PAN before doing other kernel logic MSR PSTATE.PAN, #1 ; set PAN

; ... further kernel work ...

; Later, suppose an exploit corrupts a pointer to a user-space code page and jumps there BR X3 ; branch to X3 (which points into user memory)

; Because the target page is marked PXN = 1 for privileged execution, ; the CPU throws an exception (fault) and rejects execution

Εάν ο kernel **δεν** είχε ορίσει PXN σε εκείνη τη σελίδα χρήστη, τότε το branch μπορεί να πετύχει — κάτι που θα ήταν ανασφαλές.

Εάν ο kernel ξεχάσει να ενεργοποιήσει ξανά το PAN μετά από πρόσβαση στη μνήμη χρήστη, ανοίγει ένα παράθυρο όπου περαιτέρω λογική του kernel μπορεί κατά λάθος να διαβάσει/γράψει αυθαίρετη μνήμη χρήστη.

Εάν ο δείκτης χρήστη δείχνει σε σελίδα μόνο-εκτέλεσης (σελίδα χρήστη με μόνο δικαίωμα εκτέλεσης, χωρίς ανάγνωση/εγγραφή), υπό το σφάλμα του spec PAN, `ldr W2, [X1]` μπορεί να **μην** προκαλέσει fault ακόμα και με το PAN ενεργοποιημένο, επιτρέποντας παράκαμψη exploit, ανάλογα με την υλοποίηση.

</details>

<details>
<summary>Παράδειγμα</summary>
Μια ευπάθεια στον kernel προσπαθεί να πάρει έναν pointer συνάρτησης που παρέχει ο χρήστης και να τον καλέσει στο πλαίσιο του kernel (π.χ. `call user_buffer`). Υπό PAN/PXN, αυτή η ενέργεια απαγορεύεται ή προκαλεί fault.
</details>

---

### 11. **Παράβλεψη Ανώτερου Byte (TBI) / Pointer Tagging**
**Εισήχθη στο ARMv8.5 / νεότερο (ή προαιρετική επέκταση)**
TBI σημαίνει ότι το ανώτερο byte (το πιο σημαντικό byte) ενός 64-bit pointer παραβλέπεται στην μετάφραση διευθύνσεων. Αυτό επιτρέπει στο OS ή στο hardware να ενσωματώσει bits tag στο ανώτατο byte του pointer χωρίς να επηρεάζει την πραγματική διεύθυνση.

- TBI είναι συντομογραφία για Top Byte Ignore (μερικές φορές αποκαλείται Address Tagging). Είναι μια λειτουργία hardware (διαθέσιμη σε πολλές υλοποιήσεις ARMv8+) που **παραβλέπει τα ανώτερα 8 bits** (bits 63:56) ενός 64-bit pointer όταν εκτελείται **μετάφραση διευθύνσεων / load/store / ανάκτηση εντολών**.
- Στην πράξη, η CPU αντιμετωπίζει έναν δείκτη `0xTTxxxx_xxxx_xxxx` (όπου `TT` = το ανώτερο byte) ως `0x00xxxx_xxxx_xxxx` για τις ανάγκες μετάφρασης διευθύνσεων, αγνοώντας (masking off) το ανώτερο byte. Το ανώτερο byte μπορεί να χρησιμοποιηθεί από το software για αποθήκευση **metadata / tag bits**.
- Αυτό δίνει στο software "δωρεάν" in-band χώρο για να ενσωματώσει ένα byte tag σε κάθε δείκτη χωρίς να αλλάζει τη μνήμη στην οποία αναφέρεται.
- Η αρχιτεκτονική διασφαλίζει ότι οι φορτώσεις, αποθηκεύσεις και οι ανάκτες εντολών χειρίζονται τον δείκτη με το ανώτερο byte masked (δηλαδή χωρίς το tag) πριν εκτελέσουν την πραγματική πρόσβαση μνήμης.

Έτσι το TBI αποσυνδέει τον **λογικό δείκτη** (δείκτης + tag) από τη **φυσική διεύθυνση** που χρησιμοποιείται για τις λειτουργίες μνήμης.

#### Γιατί TBI: Χρήσεις και κίνητρα

- **Pointer tagging / metadata**: Μπορείτε να αποθηκεύσετε επιπλέον metadata (π.χ. τύπο αντικειμένου, version, bounds, integrity tags) σε εκείνο το ανώτερο byte. Όταν αργότερα χρησιμοποιήσετε τον δείκτη, το tag αγνοείται σε επίπεδο hardware, οπότε δεν χρειάζεται χειροκίνητο strip για την πρόσβαση μνήμης.
- **Memory tagging / MTE (Memory Tagging Extension)**: Το TBI είναι ο βασικός μηχανισμός hardware πάνω στον οποίο χτίζει το MTE. Στο ARMv8.5, το Memory Tagging Extension χρησιμοποιεί τα bits 59:56 του δείκτη ως **λογικό tag** και τα ελέγχει σε σχέση με ένα **allocation tag** που αποθηκεύεται στη μνήμη.
- **Ενισχυμένη ασφάλεια & ακεραιότητα**: Συνδυάζοντας το TBI με pointer authentication (PAC) ή runtime checks, μπορείτε να επιβάλετε όχι μόνο τη σωστή τιμή του δείκτη αλλά και το σωστό tag. Ένας εισβολέας που υπεργράφει έναν δείκτη χωρίς το σωστό tag θα προκαλέσει ασυμφωνία tag.
- **Συμβατότητα**: Επειδή το TBI είναι προαιρετικό και τα tag bits αγνοούνται από το hardware, ο υπάρχων μη-επισημασμένος κώδικας συνεχίζει να λειτουργεί κανονικά. Τα tag bits ουσιαστικά γίνονται "don't care" bits για legacy κώδικα.

#### Παράδειγμα
<details>
<summary>Παράδειγμα</summary>
Ένας pointer συνάρτησης περιείχε ένα tag στο ανώτερο byte του (π.χ. `0xAA`). Ένα exploit υπεργράφει τα χαμηλά bits του δείκτη αλλά παραλείπει το tag, οπότε όταν ο kernel επαληθεύει ή καθαρίζει, ο δείκτης απορρίπτεται ή αποτυγχάνει.
</details>

---

### 12. **Page Protection Layer (PPL)**
**Εισήχθη σε νεότερο iOS / σύγχρονο hardware (iOS ~17 / Apple silicon / high-end models)** (κάποιες αναφορές δείχνουν PPL σε macOS / Apple silicon, αλλά η Apple φέρνει ανάλογες προστασίες στο iOS)

- Το PPL έχει σχεδιαστεί ως ένα **ενδο-kerneλ όριο προστασίας**: ακόμα κι αν ο kernel (EL1) έχει συμβιβαστεί και έχει δικαιώματα read/write, **δεν θα πρέπει να μπορεί ελεύθερα να τροποποιεί** ορισμένες **ευαίσθητες σελίδες** (ειδικά page tables, code-signing metadata, kernel code pages, entitlements, trust caches κ.λπ.).
- Δημιουργεί ουσιαστικά έναν **“kernel μέσα στον kernel”** — ένα μικρότερο εμπιστευμένο συστατικό (PPL) με **ανώτερα προνόμια** που μόνο αυτό μπορεί να τροποποιήσει προστατευόμενες σελίδες. Άλλος kernel κώδικας πρέπει να καλεί ρουτίνες PPL για να κάνει αλλαγές.
- Αυτό μειώνει την επιφάνεια επίθεσης για exploits του kernel: ακόμα και με πλήρη αυθαίρετο R/W/execute σε kernel mode, ο κώδικας του exploit πρέπει επίσης να αποκτήσει πρόσβαση στον τομέα PPL (ή να παρακάμψει το PPL) για να τροποποιήσει κρίσιμες δομές.
- Σε νεότερο Apple silicon (A15+ / M2+), η Apple μεταβαίνει σε **SPTM (Secure Page Table Monitor)**, το οποίο σε πολλές περιπτώσεις αντικαθιστά το PPL για την προστασία των page tables σε αυτές τις πλατφόρμες.

Ακολουθεί πώς πιστεύεται ότι λειτουργεί το PPL, βάσει δημόσιας ανάλυσης:

#### Χρήση του APRR / δρομολόγηση δικαιωμάτων (APRR = Access Permission ReRouting)

- Το Apple hardware χρησιμοποιεί έναν μηχανισμό που ονομάζεται **APRR (Access Permission ReRouting)**, ο οποίος επιτρέπει οι εγγραφές page table (PTEs) να περιέχουν μικρούς δείκτες (indices) αντί για πλήρη bits δικαιωμάτων. Αυτοί οι δείκτες αντιστοιχίζονται μέσω καταχωρητών APRR στα πραγματικά δικαιώματα. Αυτό επιτρέπει δυναμική επαναχάρτιση δικαιωμάτων ανά domain.
- Το PPL αξιοποιεί το APRR για να διαχωρίσει τα προνόμια εντός του kernel context: μόνο το domain PPL επιτρέπεται να ενημερώνει την αντιστοίχιση μεταξύ δεικτών και των αποτελεσματικών δικαιωμάτων. Δηλαδή, όταν μη-PPL kernel κώδικας γράφει ένα PTE ή προσπαθεί να αλλάξει bits δικαιωμάτων, η λογική APRR το αποτρέπει (ή εφαρμόζει read-only αντιστοίχιση).
- Ο κώδικας PPL ο ίδιος τρέχει σε μια περιορισμένη περιοχή (π.χ. `__PPLTEXT`) η οποία κανονικά δεν είναι εκτελέσιμη ή εγγράψιμη μέχρι οι πύλες εισόδου να την επιτρέψουν προσωρινά. Ο kernel καλεί σημεία εισόδου PPL ("PPL routines") για να εκτελέσει ευαίσθητες λειτουργίες.

#### Πύλη / Είσοδος & Έξοδος

- Όταν ο kernel χρειάζεται να τροποποιήσει μια προστατευόμενη σελίδα (π.χ. να αλλάξει δικαιώματα μιας σελίδας κώδικα kernel, ή να τροποποιήσει page tables), καλεί μια **περίβλεπτη ρουτίνα PPL**, η οποία εκτελεί έλεγχους και μετά μεταβαίνει στο domain PPL. Εκτός αυτού του domain, οι προστατευόμενες σελίδες είναι ουσιαστικά read-only ή μη-τροποποιήσιμες από τον κύριο kernel.
- Κατά την είσοδο στο PPL, οι αντιστοιχίσεις APRR προσαρμόζονται έτσι ώστε οι περιοχές μνήμης στο PPL να είναι **εκτελέσιμες & εγγράψιμες** εντός PPL. Μετά την έξοδο, επαναφέρονται σε read-only / μη εγγράψιμες. Αυτό διασφαλίζει ότι μόνο καλά ελεγχόμενες ρουτίνες PPL μπορούν να γράψουν σε προστατευόμενες σελίδες.
- Εκτός PPL, οι προσπάθειες από kernel κώδικα να γράψουν σε αυτές τις προστατευόμενες σελίδες θα προκαλέσουν fault (permission denied) επειδή η αντιστοίχιση APRR για εκείνο το domain δεν επιτρέπει εγγραφή.

#### Κατηγορίες προστατευμένων σελίδων

Οι σελίδες που το PPL συνήθως προστατεύει περιλαμβάνουν:

- Δομές των page tables (translation table entries, mapping metadata)
- Kernel code pages, ειδικά αυτές που περιέχουν κρίσιμη λογική
- Code-sign metadata (trust caches, signature blobs)
- Πίνακες entitlements, πίνακες επιβολής signatures
- Άλλες δομές υψηλής αξίας του kernel όπου ένα patch θα επέτρεπε παράκαμψη ελέγχων υπογραφής ή χειρισμό διαπιστευτηρίων

Η ιδέα είναι ότι ακόμη κι αν η μνήμη του kernel ελέγχεται πλήρως, ο εισβολέας δεν μπορεί απλά να πατσάρει ή να ξαναγράψει αυτές τις σελίδες, εκτός αν επίσης συμβιβάσει ρουτίνες PPL ή παρακάμψει το PPL.

#### Γνωστές Παράκαμψεις & Ευπάθειες

1. **Project Zero’s PPL bypass (stale TLB trick)**

- Μια δημόσια ανάλυση από το Project Zero περιγράφει μια παράκαμψη που περιλαμβάνει **stale TLB entries**.
- Η ιδέα:

1. Allocate δύο φυσικές σελίδες A και B, επισημάνετέ τες ως PPL σελίδες (ώστε να προστατεύονται).
2. Map δύο virtual διευθύνσεις P και Q των οποίων οι L3 translation table pages προέρχονται από A και B.
3. Εκκινήστε ένα thread που συνεχώς προσπελάζει το Q, κρατώντας το TLB entry του ζωντανό.
4. Κάλεσε `pmap_remove_options()` για να αφαιρέσεις mappings που ξεκινούν από το P· λόγω ενός bug, ο κώδικας καταλάθος αφαιρεί τα TTEs για τόσο το P όσο και το Q, αλλά μόνο το TLB entry για το P γίνεται invalidated, αφήνοντας το stale entry του Q ζωντανό.
5. Επανεκμεταλλεύσου το B (το page του table του Q) για να map-άρεις αυθαίρετη μνήμη (π.χ. PPL-protected pages). Επειδή το stale TLB entry εξακολουθεί να χαρτογραφεί το παλιό mapping του Q, εκείνο το mapping παραμένει έγκυρο για εκείνο το context.
6. Μέσω αυτού, ο επιτιθέμενος μπορεί να θέσει εγγράψιμες αντιστοιχίσεις των PPL-protected pages χωρίς να περάσει από το interface του PPL.

- Αυτό το exploit απαιτούσε λεπτό έλεγχο των φυσικών αντιστοιχήσεων και της συμπεριφοράς του TLB. Δείχνει ότι ένα όριο ασφαλείας που βασίζεται σε σωστή συμπεριφορά TLB / mapping πρέπει να είναι εξαιρετικά προσεκτικό ως προς τις invalidations και τη συνοχή των mappings.

- Το Project Zero σχολίασε ότι παρακάμψεις σαν αυτή είναι λεπτές και σπάνιες, αλλά δυνατές σε σύνθετα συστήματα. Παρ' όλα αυτά, θεωρούν το PPL ως μια σοβαρή μείωση κινδύνου.

2. **Άλλοι πιθανοί κίνδυνοι & περιορισμοί**

- Εάν ένα kernel exploit μπορεί άμεσα να εισέλθει σε ρουτίνες PPL (μέσω κλήσης των PPL wrappers), μπορεί να παρακάμψει περιορισμούς. Επομένως ο έλεγχος των ορισμάτων είναι κρίσιμος.
- Σφάλματα στον ίδιο τον κώδικα PPL (π.χ. overflow αρίθμησης, έλεγχοι ορίων) μπορούν να επιτρέψουν out-of-bounds τροποποιήσεις μέσα στο PPL. Το Project Zero παρατήρησε ότι ένα τέτοιο bug στο `pmap_remove_options_internal()` εκμεταλλεύθηκε στην παράκαμψή τους.
- Το όριο PPL είναι άρρηκτα συνδεδεμένο με την επιβολή hardware (APRR, memory controller), οπότε είναι τόσο ισχυρό όσο και η υλοποίηση του hardware.

#### Παράδειγμα
<details>
<summary>Code Example</summary>
Εδώ ένα απλοποιημένο pseudocode / λογική που δείχνει πώς ο kernel μπορεί να καλέσει το PPL για να τροποποιήσει προστατευόμενες σελίδες:
</details>
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

```c
// In kernel (outside PPL domain)
function kernel_modify_pptable(pt_addr, new_entry) {
// validate arguments, etc.
return ppl_call_modify(pt_addr, new_entry)  // call PPL wrapper
}

// In PPL (trusted domain)
function ppl_call_modify(pt_addr, new_entry) {
// temporarily enable write access to protected pages (via APRR adjustments)
aprr_set_index_for_write(PPL_INDEX)
// perform the modification
*pt_addr = new_entry
// restore permissions (make pages read-only again)
aprr_restore_default()
return success
}

// If kernel code outside PPL does:
*pt_addr = new_entry  // a direct write
// It will fault because APRR mapping for non-PPL domain disallows write to that page

PPL → SPTM / Αντικαταστάσεις / Μέλλον

• On Apple’s modern SoCs (A15 or later, M2 or later), Apple supports SPTM (Secure Page Table Monitor), which replaces PPL for page table protections.
• Apple calls out in documentation: “Page Protection Layer (PPL) and Secure Page Table Monitor (SPTM) enforce execution of signed and trusted code … PPL manages the page table permission overrides … Secure Page Table Monitor replaces PPL on supported platforms.”
• The SPTM architecture likely shifts more policy enforcement into a higher-privileged monitor outside kernel control, further reducing the trust boundary.

MTE | EMTE | MIE

Εδώ είναι μια σε υψηλότερο επίπεδο περιγραφή του πώς λειτουργεί το EMTE υπό την MIE ρύθμιση της Apple:

1. Tag assignment

• Όταν μνήμη δεσμεύεται (π.χ. στον kernel ή στον user space μέσω secure allocators), σε εκείνο το block ανατίθεται ένα secret tag.
• Ο pointer που επιστρέφεται στον χρήστη ή στον kernel περιλαμβάνει αυτό το tag στα υψηλά του bits (χρησιμοποιώντας TBI / top byte ignore mechanisms).

2. Tag checking on access

• Όποτε εκτελείται ένα load ή store χρησιμοποιώντας έναν pointer, το hardware ελέγχει ότι το tag του pointer ταιριάζει με το tag του memory block (allocation tag). Σε περίπτωση mismatch, γίνεται άμεσο fault (επειδή είναι synchronous).
• Επειδή είναι synchronous, δεν υπάρχει “delayed detection” παράθυρο.

3. Retagging on free / reuse

• Όταν η μνήμη απελευθερώνεται, ο allocator αλλάζει το tag του block (ώστε παλαιότεροι pointers με παλιά tags να μην ταιριάζουν πλέον).
• Ένας use-after-free pointer θα έχει έτσι stale tag και θα προκαλεί mismatch όταν επιχειρήσει πρόσβαση.

4. Neighbor-tag differentiation to catch overflows

• Γειτονικές allocations λαμβάνουν διακριτά tags. Αν ένα buffer overflow spills into neighbor’s memory, το tag mismatch προκαλεί fault.
• Αυτό είναι ιδιαίτερα αποτελεσματικό στην ανίχνευση μικρών overflows που διασχίζουν όρια.

5. Tag confidentiality enforcement

• Η Apple πρέπει να αποτρέψει τα tag values από being leaked (επειδή αν ο attacker μάθει το tag, θα μπορούσε να κατασκευάσει pointers με σωστά tags).
• Περιλαμβάνονται protections (microarchitectural / speculative controls) για να αποφευχθεί side-channel leakage των tag bits.

6. Kernel and user-space integration

• Η Apple χρησιμοποιεί το EMTE όχι μόνο στον user-space αλλά και σε kernel / OS-critical components (για την προστασία του kernel από memory corruption).
• Το hardware/OS διασφαλίζει ότι οι κανόνες των tags εφαρμόζονται ακόμα και όταν ο kernel εκτελείται εκ μέρους του user space.

</details>

#### Περιορισμοί & προκλήσεις

- **Intrablock overflows**: Αν το overflow παραμένει στην ίδια κατανομή (δεν διασχίζει όριο) και το tag μένει ίδιο, το tag mismatch δεν το ανιχνεύει.
- **Tag width limitation**: Διατίθενται μόνο λίγα bits για tag (π.χ. 4 bits, ή μικρό domain) — περιορισμένος namespace.
- **Side-channel leaks**: Εάν τα tag bits μπορούν να διαρρεύσουν (via cache / speculative execution), ο attacker μπορεί να μάθει έγκυρα tags και να παρακάμψει. Η επιβολή του Apple για tag confidentiality αποσκοπεί στη μείωση αυτού.
- **Performance overhead**: Οι έλεγχοι tag σε κάθε load/store προσθέτουν κόστος· η Apple πρέπει να βελτιστοποιήσει το hardware για να κρατήσει το overhead χαμηλό.
- **Compatibility & fallback**: Σε παλαιότερο hardware ή κομμάτια που δεν υποστηρίζουν EMTE, πρέπει να υπάρχει fallback. Η Apple ισχυρίζεται ότι το MIE ενεργοποιείται μόνο σε συσκευές με υποστήριξη.
- **Complex allocator logic**: Ο allocator πρέπει να διαχειρίζεται tags, retagging, alignment των ορίων, και να αποφεύγει collisions από mis-tag. Bugs στη λογική του allocator μπορούν να εισάγουν ευπάθειες.
- **Mixed memory / hybrid areas**: Μνήμη μπορεί να παραμείνει untagged (legacy), κάνοντας την αλληλεπίδραση πιο περίπλοκη.
- **Speculative / transient attacks**: Όπως με πολλές microarchitectural προστασίες, speculative execution ή micro-op fusions μπορούν να παρακάμψουν ελέγχους transiently ή να leak tag bits.
- **Limited to supported regions**: Η Apple μπορεί να εφαρμόσει EMTE μόνο σε επιλεγμένες, υψηλού κινδύνου περιοχές (kernel, security-critical subsystems), όχι ολικά.



---

## Key enhancements / differences compared to standard MTE

Εδώ είναι οι βελτιώσεις και οι αλλαγές που τονίζει η Apple:

| Χαρακτηριστικό | Original MTE | EMTE (Apple’s enhanced) / MIE |
|---|---|---|
| **Check mode** | Υποστηρίζει synchronous και asynchronous modes. Στο async, τα tag mismatches αναφέρονται αργότερα (delayed) | Η Apple επιμένει σε **synchronous mode** ως default—τα tag mismatches εντοπίζονται άμεσα, χωρίς καθυστέρηση/παράθυρα race. |
| **Coverage of non-tagged memory** | Οι προσβάσεις σε non-tagged memory (π.χ. globals) μπορεί να παρακάμπτουν ελέγχους σε κάποιες υλοποιήσεις | Το EMTE απαιτεί ότι οι προσβάσεις από tagged region προς non-tagged memory επίσης επικυρώνουν γνώση του tag, δυσκολεύοντας τα bypass με mixing allocations. |
| **Tag confidentiality / secrecy** | Tags μπορεί να είναι observable ή να leaks μέσω side channels | Η Apple προσθέτει **Tag Confidentiality Enforcement**, που προσπαθεί να αποτρέψει το leakage των τιμών tag (via speculative side-channels κ.λπ.). |
| **Allocator integration & retagging** | Το MTE αφήνει μεγάλο μέρος της λογικής allocator στο software | Οι secure typed allocators της Apple (kalloc_type, xzone malloc, κ.λπ.) ενσωματώνονται με το EMTE: όταν μνήμη allocated ή freed, τα tags διαχειρίζονται σε λεπτή κοκκομετρία. |
| **Always-on by default** | Σε πολλές πλατφόρμες, το MTE είναι optional ή off by default | Η Apple ενεργοποιεί EMTE / MIE by default σε υποστηριζόμενο hardware (π.χ. iPhone 17 / A19) για kernel και πολλές user processes. |

Εφόσον η Apple ελέγχει και το hardware και το software stack, μπορεί να επιβάλλει στενά το EMTE, να αποφύγει performance pitfalls και να κλείσει side-channel τρύπες.

---

## How EMTE works in practice (Apple / MIE)

Εδώ είναι μια υψηλού επιπέδου περιγραφή του πώς λειτουργεί το EMTE στο πλαίσιο του Apple / MIE:

1. **Tag assignment**
- Όταν η μνήμη κατανεμηθεί (π.χ. στον kernel ή στο user space μέσω secure allocators), σε αυτό το μπλοκ ανατίθεται ένα **secret tag**.
- Ο pointer που επιστρέφεται στον χρήστη ή στον kernel περιλαμβάνει αυτό το tag στα high bits (using TBI / top byte ignore mechanisms).

2. **Tag checking on access**
- Κάθε φορά που εκτελείται ένα load ή store με χρήση pointer, το hardware ελέγχει ότι το tag του pointer ταιριάζει με το tag του μπλοκ μνήμης (allocation tag). Σε mismatch, γίνεται immediate fault (εφόσον synchronous).
- Επειδή είναι synchronous, δεν υπάρχει «delayed detection» παράθυρο.

3. **Retagging on free / reuse**
- Όταν η μνήμη freed, ο allocator αλλάζει το tag του μπλοκ (ώστε παλιότεροι pointers με παλιά tags να μην ταιριάζουν πλέον).
- Ένας use-after-free pointer θα έχει επομένως stale tag και θα κάνει mismatch όταν προσπελαστεί.

4. **Neighbor-tag differentiation to catch overflows**
- Γειτονικές allocations λαμβάνουν διαφορετικά tags. Εάν ένα buffer overflow χυθεί στη μνήμη του γείτονα, το tag mismatch προκαλεί fault.
- Αυτό είναι ιδιαίτερα ισχυρό για την ανίχνευση μικρών overflows που διασχίζουν όριο.

5. **Tag confidentiality enforcement**
- Η Apple πρέπει να αποτρέψει το να διαρρεύσουν οι τιμές tag (επειδή αν ο attacker μάθει το tag, μπορεί να δημιουργήσει pointers με σωστά tags).
- Περιλαμβάνουν προστασίες (microarchitectural / speculative controls) για να αποφευχθεί το side-channel leakage των tag bits.

6. **Kernel and user-space integration**
- Η Apple χρησιμοποιεί EMTE όχι μόνο στο user-space αλλά και στον kernel / OS-critical components (για να προστατεύσει τον kernel από memory corruption).
- Το hardware/OS διασφαλίζει ότι οι κανόνες tag εφαρμόζονται ακόμη και όταν ο kernel εκτελείται εκ μέρους του user space.

Εφόσον το EMTE είναι ενσωματωμένο στο MIE, η Apple χρησιμοποιεί EMTE σε synchronous mode σε βασικές επιφάνειες επίθεσης, όχι ως opt-in ή debugging mode.



---

## Exception handling in XNU

Όταν συμβαίνει μια **exception** (π.χ. `EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC`, κ.λπ.), το **Mach layer** του XNU kernel είναι υπεύθυνο να την παρεμβάλει πριν αυτή μετατραπεί σε UNIX-style **signal** (όπως `SIGSEGV`, `SIGBUS`, `SIGILL`, ...).

Αυτή η διαδικασία περιλαμβάνει πολλαπλά στρώματα propagation και handling πριν φτάσει στο user space ή μετατραπεί σε BSD signal.


### Exception Flow (High-Level)

1.  **CPU triggers a synchronous exception** (π.χ. invalid pointer dereference, PAC failure, illegal instruction, κ.λπ.).

2.  **Low-level trap handler** τρέχει (`trap.c`, `exception.c` στο XNU source).

3.  Ο trap handler καλεί **`exception_triage()`**, τον πυρήνα του Mach exception handling.

4.  Το `exception_triage()` αποφασίζει πώς θα δοθεί η exception:

-   Πρώτα στο **thread's exception port**.

-   Έπειτα στο **task's exception port**.

-   Έπειτα στο **host's exception port** (συχνά `launchd` ή `ReportCrash`).

Αν κανένα από αυτά τα ports δεν χειριστεί την exception, ο kernel μπορεί:

-   **Να τη μετατρέψει σε BSD signal** (για user-space processes).

-   **Να κάνει panic** (για kernel-space exceptions).


### Core Function: `exception_triage()`

Η συνάρτηση `exception_triage()` δρομολογεί τις Mach exceptions κατά μήκος της αλυσίδας πιθανών handlers μέχρι κάποιος να τη χειριστεί ή μέχρι να καταστεί τελικά μοιραία. Ορίζεται σε `osfmk/kern/exception.c`.
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

Zone page (64-byte chunks for example):
[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]

Freelist view:
HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
(next ptrs stored at start of freed chunks)

Before corruption:
HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL

After attacker overwrite of F1->next:
HEAD ──► [ F1 ]
(next) ──► 0xDEAD_BEEF_CAFE_BABE  (attacker-chosen)

Next alloc of this zone → kernel hands out memory at attacker-controlled address.