[monocasa]

> For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack.

Do what now?

Edit: seriously what does that sentence mean? Executing off the stack is super dangerous. Even on an M3 you can (and should) setup the MPU to have a non executable stack.

[Arnavion]

It means the firmware does not have a heap for dynamic allocation, not that it's generating and executing code in buffers on the stack.

[monocasa]

That also doesn't make sense. You commonly have a heap but no runtime allocation under such circumstances.

MISRA, JSF C++, and even NASA code guidelines say no dynamic allocation after initialization.

If it's written in C or C++, that's also crazy town, and you're pretty much guaranteed to have dangling pointers as auto allocated objects are left behind on old stack frames.

[camgunz]

I don't know about "commonly". In my experience with embedded C, if you needed things you declared them statically and never used malloc. It's not like you're calling alloca and letting those pointers escape -- any (valid) pointer you might have is to a static allocation or memory mapped address.

C++ is a different game and I don't know anything about it though.

But yeah the way I read this is they don't use malloc, which is pretty standard. This is how I've heard it referred to many times, and nothing else makes any sense.

[monocasa]

> I don't know about "commonly". In my experience with embedded C, if you needed things you declared them statically and never used malloc.

I mean, it's common enough that MISRA, the JSF standard, and the NASA standard all specifically call it out to allow it under these conditions.

> It's not like you're calling alloca and letting those pointers escape -- any (valid) pointer you might have is to a static allocation or memory mapped address.

You only need to call alloca on dynamically sized stack allocations. You can always leak pointers to fixed size objects by:

  void* woah_dont_do_this(void) {
    int value = 0;
    return &value;
  }

and boom, the pointer that gets returned is pointing at invalid memory. Of course, no one would write it like this, but it's way easier than you might think to accidentally do this once there's some abstraction.

[ummonk]

That isn’t really a heap then. Just normal static allocation.

[monocasa]

Nah, you can still call malloc/new. Worked on a sweet RTOS that had tons of default overrides for new that ultimately let you define all layout from your top level module despite following these guidelines. Let you share tons of code across boards, but still make decisions like "this guy's buffers should be this big, and stored in this ram bank" all from the top level C++ file for each board.

And it's definitely not stack allocated like the original point of this thread.

[camgunz]

Well but regardless, if you have a malloc or new implementation that uses a static buffer, then you're still not touching the heap. In fairness and as you point out, it's not the stack either, but they're obviously not letting stack allocations escape. Nothing would ever work.

[monocasa]

> Well but regardless, if you have a malloc or new implementation that uses a static buffer, then you're still not touching the heap.

What do you think the heap is on systems without an MMU?

> In fairness and as you point out, it's not the stack either, but they're obviously not letting stack allocations escape. Nothing would ever work.

You can go for an awfully long time without knowing that you dangling pointers to auto allocated objects.

[ianhowson]

The very next sentence doesn't make sense either:

> And to reduce flash-wear, RAM contents can be preserved even during low-power mode when most hardware modules are turned off.

Flash wear only occurs during erases, so... why does it matter to reduce wear in low-power mode? Why would they be writing to flash during normal operation, except perhaps an authentication counter?

One would hope that they're executing the program out of the flash (that they've previously verified and locked) rather than out of 'stack'. This isn't an operation that causes wear.

[monocasa]

Maybe they're saying that the other low power mode would slurp all of sram into flash?

But that still doesn't make sense, SRAM lasts for years on a battery of you're not clocking it, and every little uC I know of that vaguely cares about power lets you do that. Why call it out. Hell, NES games keep their SRAM saves going for decades off a little coin cell.