Re: [Suit] WG: WGLC on draft-ietf-suit-firmware-encryption-14 due on September 11, 2023

[David Brown <[e-mail]>]

Perhaps. The simple explanation is that although PIC may allow some users
to have images that run in either slot, there are going to continue to be
applications where this won't work, and image swapping will need to be
explicitly support by SUIT.

David

On Fri, Sep 15, 2023 at 2:35 AM Tschofenig, Hannes <
[e-mail]> wrote:

> David,
>
> I believe what you are saying is that regardless of PIC or not, we need to
> deal with image swap operations by the bootloader today.
>
> I am wondering whether I should expand the text to make this more clear.
>
> Ciao
> Hannes
>
> -----Ursprüngliche Nachricht-----
> Von: Suit <[e-mail]> Im Auftrag von David Brown
> Gesendet: Donnerstag, 14. September 2023 21:26
> An: Michael Richardson <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>; [e-mail]
> Betreff: Re: [Suit] WG: WGLC on draft-ietf-suit-firmware-encryption-14 due
> on September 11, 2023
>
> On Mon, Sep 11, 2023 at 03:14:06PM -0400, Michael Richardson wrote:
>
> > 6. Per-device-type ES. Singly Encrypted firmware.
> >
> >     >> Ditto comment about PIC becoming more and more common, and
> anyway, compile to
> >     >> two different slots.
> >
> >     > Where is PIC becoming more popular? Which RTOS supports PIC?
> >
> > My impression is that it is often default for RIOS-OS, and/or RISC-V.
> > My impression is that the problem has usually been compiler support.
>
> At least on Arm Cortex-M, PIC is pretty much the only way that the
> compiler will generate code. However, this is very distant from a
> particular application itself being position independent. That works for
> the code, but all pointers and such need to be made PIC as well, which
> usually involves code specifically to handle offset. For example, in
> Zephyr, we'd have to handle the vector tables, all function pointers, etc.
>
> David
>