Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
  • Part 14: Security and Isolation7
    • Access Attributes
    • Firewalls and Filtering
    • Address Translation for Devices
    • Link Integrity and Encryption
    • Fabric Denial of Service
    • Isolation and Multi-Tenancy
    • Drills: Security and Isolation
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 14: Security and Isolation
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 14: Security and Isolation
  4. Drills: Security and Isolation

Part 14 · Security and Isolation · All levels

Drills: Security and Isolation

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 14.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself How does a memory controller know whether a request is secure?

    The request carries a security attribute (AXI AxPROT[1]) set by hardware from the requester's true state, carried unchanged and checked in front of memory.

    Check yourself What should a firewall do with a refused request?

    Keep it from the target, answer it with an error, log it and alert secure software.

    Check yourself Why put an IOMMU in front of devices?

    Without one, a DMA-capable device can access any physical memory; the IOMMU translates and checks each access with per-device tables.

    Check yourself Why isn't a CRC enough against tampering?

    It has no secret; an attacker recomputes it. Use keyed integrity tags, encryption and replay counters.

    Check yourself How can a requester deny service without breaking access rules?

    By volume: filling shared queues and buffers with allowed requests; bound it with per-requester queues, limits and regulators.

    Check yourself What does isolating tenants on one chip take?

    Identities for every request, per-tenant IOMMU tables, virtual functions, performance isolation, cache and bandwidth partitioning, and link protection.

    Whiteboard exercise

    Task. An SoC has a CPU cluster with secure and non-secure software, a DMA engine programmed by non-secure software, a PCIe port for an external accelerator, and DRAM with a secure region. Specify how each requester is identified, where checks happen, and how the secure region and the CPU's memory latency are protected.

    Check yourself Open a model answer

    Identity: the CPU sets AxPROT (privilege, non-secure) from its true state; the DMA engine's port forces non-secure and assigns a fixed master ID, since non-secure software programs it; PCIe requests carry a Requester ID, which an IOMMU uses. Checks: a TrustZone address space controller in front of DRAM refuses non-secure access to the secure region by region, security state and master ID, answering refused requests with errors and logging them; its configuration is writable only by secure software and locked after boot; it checks whole bursts. The DMA engine and the PCIe port go through an IOMMU (SMMU) with per-stream page tables set up by the operating system, so neither can reach memory outside its mappings, with invalidation completed before buffers are freed. Performance: per-requester queues and round-robin or weighted arbitration at the memory controller, outstanding-transaction limits and a bandwidth regulator on the PCIe and DMA ports, and QoS priority for the CPU with limits. If the PCIe link leaves a trusted enclosure, enable IDE.

    Checkpoint: ten questions

    Check yourself 1. Name the three AXI AxPROT bits.

    Privileged, non-secure, instruction.

    Check yourself 2. Who should set a DMA engine's security attribute?

    The fabric port it is attached to (or an IOMMU), not the engine or its software.

    Check yourself 3. What should a bridge without a security signal drive?

    A conservative value, normally non-secure.

    Check yourself 4. Why must a firewall check the whole burst?

    A burst starting in an allowed region can run into a protected one.

    Check yourself 5. Who may program a firewall's region table?

    Only secure, privileged software, or nobody after it is locked.

    Check yourself 6. How does an IOMMU pick a device's page tables?

    From its requester or stream ID, assigned by the fabric.

    Check yourself 7. What does ATS require when a mapping is removed?

    The IOMMU must invalidate the device's cached translation and wait for confirmation before the memory is reused.

    Check yourself 8. What three things does adversarial link protection need?

    Encryption, a keyed integrity tag covering the header too, and replay protection.

    Check yourself 9. In a shared FIFO, what sets the victims' latency under a flood?

    The attacker's number of queued requests.

    Check yourself 10. What does SR-IOV give each virtual machine?

    Its own virtual function of a shared device, with its own identity.

    Revisit

    • 14.1 Access Attributes

    • 14.2 Firewalls and Filtering

    • 14.3 Address Translation for Devices

    • 14.4 Link Integrity and Encryption

    • 14.5 Fabric Denial of Service

    • 14.6 Isolation and Multi-Tenancy

    Keep going

    Next: Part 15: Specifying and Verifying. How do we know it is correct?

    Previous

    195 / 234

    Next: Part 15: Specifying and Verifying

    Up next

    Up nextPart 15: Specifying and Verifying

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Access Attributes
    • Firewalls and Filtering
    • Address Translation for Devices