stefanrueger / urboot

Small AVR bootloader using urprotocol
GNU General Public License v3.0
55 stars 8 forks source link

Proposal: EXEC command #30

Closed Plecra closed 5 months ago

Plecra commented 5 months ago

Sending the bootloader exec(addr) will start execution at the address, allowing the host to start running programs from anywhere in program memory.

I need to add this to bootloaders on my own boards to allow hosts to enter my debug entrypoints without rewriting my vector tables each boot and wearing out flash. Could it fit in urboot as an optional feature?

stefanrueger commented 5 months ago

Neat idea for debugging.

The proposal can be implemented outside the bootloader. As such, given the urboot project is about small bootloaders, it is outside scope.

Have you thought about security? Out of necessity, bootloaders contain the SPM opcode. The proposal gives any user with access to the physical board the ability to jump to an arbitrary address, which can create a security problem or enable the user to brick the board. I realise many projects have cooperative and benign users, but if not the consequences don't bear thinking about.

I am sure your proposal is useful for debugging, but all things considered I do not recommend implementing that in a bootloader.

Plecra commented 5 months ago

Thankyou for your thoughts. Would you suggest making the application implement the handshake logic on startup instead? Reimplementing protocol logic and losing more rom space feels like a shame but I can definitely understand where you're coming from, this is firmly a debugger feature rather than a bootloader one.

I don't see any security hazards to the feature beyond what urboot already provides, though. Surely any undesirable jump would also be possible by patching the reset vector?

stefanrueger commented 5 months ago

suggest making the application implement the handshake logic on startup instead

Yes, exactly. (And if your project is hard up for space you can use an external programmer in lieu of a bootloader)

Surely any undesirable jump would also be possible by patching the reset vector?

Good point: bootloaders are already inherently insecure in some sense. While urboot has a compile-time option to protect the reset vector (urboot itself then ensures that writing page 0 will set the reset vector to jump to the bootloader), other insecurities still exist.