GitLab

Detail:
  Early in OS startup, certain kernel memory areas (zero page, the privileged
  mode stacks, system heap, etc) are initially allocated only in the L2PT.
  The soft CAM is initialised later, using the L2PT as it is at that point.
  However, the pointer to the table that maps from page table cache policy
  bit layouts for the current CPU back to the platform-independent
  (OS_DynamicArea style) flags was corrupted, meaning that the CAM entries
  for these memory areas were initialised with a default value, which was
  non-cacheable non-bufferable. Application slots and most dynamic areas were
  unaffected, because once enough of the kernel was initialised to be able to
  use AMBControl or OS_ChangeDynamicArea, this function was no longer used.
  The problem comes when those pages come to be remapped; this could be due
  to requests for specific physical RAM pages, or (what I was actually
  investigating) DDT changing the access permissions on them. The problem was
  that as far as the CPU was concerned, the pages were cacheable/bufferable,
  but BangCam examined the soft CAM to decide what cache management
  operations to perform, and so got it wrong. The subsequent poke of the L2PT
  resulted in undefined CPU behaviour; in particular it seems to cause L2
  caches to throw a strop (enough so that disabling the L2 cache was enough
  to make DDT significantly more reliable).
Admin:
  It looks like this bug has been present on all HAL versions of RISC OS.
  Tested with DDT on a Beagleboard, previously the most crashy platform.
  There remains an IRQ (and FIQ) hole in OS_SetMemMapEntries when changing
  permissions on the page containing the processor vectors, which I haven't
  attempted to fix. Arguably, it should also issue Service_PagesSafe/Unsafe,
  in case anyone is DMAing to/from the remapped pages.

Version 5.35, 4.79.2.212. Tagged as 'Kernel-5_35-4_79_2_212'