Bootloader & Secure Boot Interview (80 Questions)

-

 

Section A – Bootloader Fundamentals (1–10)

1.

What is a Bootloader? Why is it required?

2.

What are the responsibilities of a Bootloader?

3.

Explain the complete boot sequence from Power-On Reset until the application starts.

4.

Difference between:

  • Primary Bootloader (PBL)
  • Secondary Bootloader (SBL)
  • Application Bootloader

5.

Explain the memory map of a typical automotive ECU containing:

  • Bootloader
  • Application
  • Calibration
  • NVM
  • Backup area

6.

Why is a Bootloader typically write-protected?

7.

What happens immediately after reset?

8.

How does a Bootloader determine whether to remain in programming mode or jump to the application?

9.

What validations are performed before transferring control to the application?

10.

Describe the complete Bootloader state machine.

Section B – Application Jump (11–18)

11.

How does a Bootloader jump to an application on ARM Cortex-M?

12.

Why must the Main Stack Pointer (MSP) be reinitialized before the jump?

13.

Why must the Vector Table Offset Register (VTOR) be updated?

14.

What happens if interrupts are not disabled before the jump?

15.

What steps should be completed before calling the application's Reset Handler?

16.

How do you verify that the application's vector table is valid?

17.

The Bootloader jumps to the application, but the application immediately enters a HardFault. What could cause this?

18.

How would you debug a Bootloader-to-Application handoff failure?

Section C – Secure Boot (19–30)

19.

What is Secure Boot? Why is it necessary?

20.

Explain the complete Secure Boot chain of trust.

21.

What is the Root of Trust (RoT)?

22.

Explain:

  • Symmetric Cryptography
  • Asymmetric Cryptography

23.

Why are public-key algorithms preferred for Secure Boot verification?

24.

Difference between:

  • Encryption
  • Hashing
  • Digital Signature

25.

Explain SHA-256.

Why is hashing performed before signature verification?

26.

Explain RSA and ECC.

Which would you choose for an automotive Bootloader and why?

27.

Describe the complete digital signature verification process during boot.

28.

What is certificate-based verification?

29.

Where should public keys be stored securely?

30.

What happens if signature verification fails?

Section D – Firmware Update (31–42)

31.

Explain the complete firmware update process.

32.

Describe the UDS flashing sequence using the following services:

  • Diagnostic Session Control
  • Security Access
  • Request Download
  • Transfer Data
  • Request Transfer Exit
  • Routine Control
  • ECU Reset

33.

What is a Verification Structure (VS)? What information does it typically contain?

34.

How is firmware integrity verified after programming?

35.

What is rollback protection? Why is it important?

36.

How would you implement A/B partitioning for firmware updates?

37.

How should power-loss during flashing be handled?

38.

What metadata should accompany a firmware image?

39.

How do you prevent firmware downgrade attacks?

40.

How is firmware compatibility verified across multiple logical blocks?

41.

How would you support partial updates while maintaining system consistency?

42.

How do you ensure a firmware image cannot be replayed after a newer version has been installed?

Section E – Automotive Bootloader (43–52)

43.

What is ISO 14229 (UDS)? How does it relate to Bootloaders?

44.

Explain ISO-TP (ISO 15765-2). Why is it required over CAN?

45.

How does a Bootloader handle segmented data transfer?

46.

What are Negative Response Codes (NRCs)? Give common examples used during flashing.

47.

Explain Security Access (UDS Service 0x27). How do seed/key exchanges work conceptually?

48.

How would you protect against brute-force attempts during Security Access?

49.

What is a Flash Driver? Why is it often downloaded to RAM?

50.

Why can't flash memory typically be programmed while executing code from the same flash bank?

51.

How is a Watchdog managed during long erase/program operations?

52.

How do Bootloader and Application coordinate ownership of hardware resources?

Section F – HSM & Key Management (53–60)

53.

What is a Hardware Security Module (HSM)?

54.

How does the Bootloader interact with an HSM during Secure Boot?

55.

Where should cryptographic keys be stored?

56.

How are keys provisioned during manufacturing?

57.

How do you securely update cryptographic keys in the field?

58.

What is anti-rollback protection for keys?

59.

How would you respond if a signing key is compromised?

60.

How do Secure Boot and Secure Firmware Update complement each other?

Section G – Debugging Scenarios (61–70)

61.

The Bootloader never jumps to the application. How would you investigate?

62.

Signature verification succeeds, but the application crashes immediately after startup. What would you check?

63.

A firmware update completes successfully, but the ECU repeatedly resets. What are the possible causes?

64.

Programming fails after 70% completion. Describe your debugging approach.

65.

A firmware image passes validation in the development environment but fails in production. What differences would you investigate?

66.

The Bootloader unexpectedly enters recovery mode after every reset. What could cause this?

67.

The Watchdog resets the ECU during flash programming. How would you address it?

68.

After an OTA update, one logical block is updated successfully while another is not. How should the Bootloader respond?

69.

The Bootloader occasionally reports a CRC mismatch on a valid image. What could explain intermittent failures?

70.

The Bootloader hangs before reaching the application. Outline your debugging methodology.

Section H – Architecture & Design (71–80)

71.

Design a Secure Boot architecture for an Automotive ECU.

72.

Design a Bootloader supporting:

  • CAN
  • Ethernet
  • OTA
  • UDS
  • Secure Boot

73.

Design a rollback-safe firmware update strategy for a dual-bank flash architecture.

74.

How would you design a Bootloader for a multicore MCU? How would you synchronize firmware validation and startup across cores?

75.

How would you support multiple software images (Bootloader, Main Application, Secondary Application, Calibration) within a single ECU?

76.

Describe a strategy for handling interrupted firmware updates while guaranteeing recoverability.

77.

How would you optimize Bootloader startup time without weakening security?

78.

What diagnostic information and logs would you preserve after a failed firmware update to support field debugging?

79.

Describe your approach to testing and validating a Bootloader before production release.

80.

You are asked to design the Bootloader for a next-generation Automotive ECU supporting:

  • Secure Boot
  • OTA updates
  • UDS service programming
  • CAN FD
  • Automotive Ethernet
  • HSM
  • A/B firmware partitions
  • Rollback protection
  • Multicore startup

Walk through your architecture, security model, update flow, fault handling, and recovery strategy.

Coding & Practical Questions

You may also be asked to implement or explain:

  1. Jump from Bootloader to Application on Cortex-M.
  2. CRC-32 verification of a firmware image.
  3. SHA-256 hash verification flow.
  4. Flash erase/program routines.
  5. UDS RequestDownload state handling.
  6. ISO-TP receive state machine.
  7. A Bootloader state machine.
  8. Dual-bank firmware update logic.
  9. Firmware version compatibility checks.
  10. Watchdog servicing during flash operations.

Comments

Post a Comment

Popular posts from this blog

Fundamental Secure Features in Automotive ECUs

-
Image
 With increasing connectivity and functionality in modern vehicles and IoT devices, security has become a non-negotiable aspect of embedded system design. Automotive ECUs and IoT MCUs are now exposed to threats that can compromise safety, privacy, and system integrity. To mitigate these risks, a suite of fundamental secure features is implemented across the lifecycle of embedded software. This blog outlines six core security pillars that serve as the foundation for robust ECU security: Fundamental Secure Feature I: Secure Boot Fundamental Secure Feature II: Secure Flash Fundamental Secure Feature III: Secure JTAG Fundamental Secure Feature IV: Secure LOG Fundamental Secure Feature V: Secure UDS Fundamental Secure Feature VI: Secure On-Board Communication (SecOC) These six foundational security features—Secure Boot, Secure Flash, Secure JTAG, Secure Log, Secure UDS, and Secure On-Board Communication (SecOC)—are critical for building a trustworthy embedded system. Whether in automoti...
Read more

Overview of ISO/SAE 21434 Standard

-
Image
ISO/SAE 21434, jointly published by the International Standardization Organization (ISO) and the Society of Automotive Engineers (SAE), serves as a comprehensive cybersecurity framework for electronic systems within road vehicles. Developed to bolster cybersecurity across the entire lifecycle of automotive products, this standard outlines essential vocabulary, objectives, requirements, and guidelines. Purpose and Scope: The primary objective of ISO/SAE 21434 is to enhance cybersecurity measures for vehicles throughout their lifecycle. By providing a standardized framework, this standard facilitates the establishment of cybersecurity policies, risk management practices, and a cybersecurity-oriented culture within organizations operating in the automotive industry. Three Pillars: ISO/SAE 21434 is structured around three main pillars: Cyber Security Governance:   Establishing policies, processes, and cultural norms to govern cybersecurity activities within organizations. Risk Man...
Read more

Embedded C Interview (50 Questions)

-
 Section A – C Fundamentals (1–10) 1. Q1. Explain the memory layout of a C program. A C program is divided into multiple memory sections by the linker. Each section has a specific purpose. High Address +----------------------------------+ | Stack | | Local Variables | | Function Parameters | +----------------------------------+ | | | Heap | | malloc(), calloc() | +----------------------------------+ | .bss | | Uninitialized Globals | | Static Variables | +----------------------------------+ | .data | | Initialized Globals | | Static Variables | +----------------------------------+ | .rodata | | const Variables | | String Literals | +------------------------------...
Read more