Hi Soby,
The programmer can induce unaligned access though, although I am struggling to understand why the programmer would want to do that. The case you have pointed out seems like an error which needs to be corrected in platform code IMO.
Yes, it's an error, no question. My concern is just that those errors can be subtle and you're not guaranteed to find them, even with SCTLR.A set. In the concrete case that I had here, the code was just something like
static uint8_t alloc_buffer[512]; static int alloc_offset;
if (alloc_offset < sizeof(alloc_buffer)) { uint16_t *p = &alloc_buffer[alloc_offset]; alloc_offset += sizeof(uint16_t); ... }
And that is bad code that can easily be fixed, no question. But we had been testing this for over a year before it suddenly started crashing at an inopportune time after we already thought our code was stable. If SCTLR.A was unset, we would've never found this, but it also wouldn't really have hurt anyone in practice.
I think the same can happen with much more subtle situations, too. Consider code like this:
... smc_handler(uint32_t smc_fid, u_register_t base_address, u_register_t size, ...) { ...range check base_address, size... mmap_surrounding_page(base_address, size); struct somestruct *s = (void *)base_address; ... }
This code is wrong, too, but would reviewers really spot that? You're extremely unlikely to ever get an alignment fault in practice here because a kernel allocating a data structure to pass through an SMC would almost certainly allocate it aligned. But on the odd chance it doesn't (or if an attacker intentionally forces that), you suddenly have an EL3 panic that you never knew was there. If SCTLR.A was unset, the code would still work fine in that situation (with maybe a miniscule performance penalty).
I think this combination of "it's extremely hard to 100% prevent alignment fault risks throughout the code base" and "on the odd chance misaligned accesses do happen, they don't really cause a notable problem (when SCTLR.A is off)" is the reason that most other code bases I've seen (e.g. Linux) chose to treat avoiding misaligned accesses as a best-effort thing and leave SCTLR.A off. Accepting the occasional misaligned access doesn't actually hurt as much as crashing the whole system through an alignment fault. (After all, that's also how some other architectures like x86 work by default.)
But if you're really concerned about keeping unaligned accesses out of the code base at all costs, I understand that that flag is useful and that just enabling it for DEBUG builds may not be enough. I'll consider making this change downstream for the platform port I'm concerned about, then.