An alternative to the slot system

[RedGl0w]

Problem you'd like to fix

In epsilon 16 was introduced a slot system : each slots has a kernel, a userland and after that space for external apps. The group kernel + userland signature is checked when booting up, and if it is correct, the kernel is executed. However, this system isn't very attractive, because :

• all the signature system is in the bootloader. This won't allow external signed apps
• the apps are limited to 3MB, which is pretty tiny for some apps which can't be ported without dark magic

Describe the solution you'd like

@boricj already talked about a FS in external flash, and it could be indeed a very nice solution. In the external flash, we would have firstly a kernel, which is run only when bootloader asserts it is well signed, and then a pretty big file system, with userlands, apps and files (like python script, screenshot, ...) in it. This would firstly be super attractive, but also would allow some big apps to be ported, and to have signed apps one day, if needed (this would be very cool by the way). The main things needed are so :

• a FS in the kernel
• a dynamic linker / loader in the kernel, but it is already needed for the external apps (because it's impossible not to have data and bss section currently)

[Ecco]

Hi @RedGl0w !

all the signature system is in the bootloader. This won't allow external signed apps

If we were to add signed apps, then I think the proper way to do this would be to use a chain-of-trust approach: a signed kernel would in turn verify signed apps. I don't think the current design prevents this, does it?

the apps are limited to 3MB, which is pretty tiny for some apps which can't be ported without dark magic

Well, 3MB is also ~3x the entire OS 😄

The value of the slot system resides in the fact that a botched update will still result in a machine that boots a working OS (kernel+userland). By design, we want to keep some amount of duplication (i.e. at least two copies of userland + kernel). That being said, if kernel+userland is 1MB, then we could indeed "share" the remaining free space and offer 6MB for external content 😄

[RedGl0w]

Hi @RedGl0w !

Hi @Ecco

If we were to add signed apps, then I think the proper way to do this would be to use a chain-of-trust approach: a signed kernel would in turn verify signed apps. I don't think the current design prevents this, does it?

Nope, it doesn't prevent it indeed, but would need a restart after adding apps, and if apps and files are mixed in a fs, this would require to have the fs in bootloader. It seems a bit heavy.

Well, 3MB is also ~3x the entire OS 😄

You're right, but blocking 3 other MB without dark magic seems a bit dumb :p

The value of the slot system resides in the fact that a botched update will still result in a machine that boots a working OS (kernel+userland). By design, we want to keep some amount of duplication (i.e. at least two copies of userland + kernel). That being said, if kernel+userland is 1MB, then we could indeed "share" the remaining free space and offer 6MB for external content 😄

Nice to hear that you want that. I'll take again a look at how the linker scripts of e16 work :p

[RedGl0w]

By the way, even if it is not related to this issue, have you already so will to have official external apps ? This could be cool to have an atomic table, a RPN input and a spreadsheet, but you already know that :p

[LukasMFR]

Are apps signed now in E16 ?

[RedGl0w]

Are apps signed now in E16 ?

Yes and no Userland (which contains the main apps) and kernel are signed together. External apps aren't signed.