Re: ARM is channeling the IBM 360

On 6/22/2024 5:58 AM, John Dallman wrote:

In article <bebb9f88a6677b4894478a3dabc8b2c9@www.novabbs.org>,
mitchalsup@aol.com (MitchAlsup1) wrote:
 

The 4 seconds part leads me to believe the attackers are using brute
force, since in 4 seconds one can try something like 2^28 patterns.

 Makes sense: there's probably a hash of the block address involved in
generating those 4-bit tags, and they're brute-forcing the salt.
 Memory Tagging Extension doesn't seem to have been heavily used as yet,
which may be why ARM aren't very worried about it.
 

To me, it sounds like they are using something annoying and expensive (memory tagging) in a way that is also not particularly effective (can be brute forced).
Granted, using memory tagging to validate pointers does arguably have less impact on code generation than, say, hardware bounds checking (by encoding bounds-check metadata inside the pointers / capabilities).
But, does add its own problems:
Say, to swap out memory pages, one also needs to keep track of and save/restore the tag bits associated with each memory page.
So, say, if you had 16K pages, one might need an additional 512 bytes or so for the tag bits (assuming 4 bits per 16 bytes or similar).
Would still be 512B with 4K pages, assuming one pads to a multiple of 512B.
So, say (going into OS design thinking here), do we have a separate pagefile, separate region in the pagefile, or do we make pagefile pages non power of 2, etc...
Though, non-power-of-2 pages seems extra bad for something like an SDcard or SSD as one may potentially end up effectively doubling the number of block updates per page-write operation. But, OTOH, if one tries to consolidate the tags into separately managed memory pages from the main memory, this would makes the pagefile management significantly more complex.
Though, admittedly, I had previously considered the possibility of a 2-level scheme where page updates would LZ compress pages, which would be packed into blocks and written out in a similar way to a log file system. While this could be less abusive towards an SDcard, it would have been complicated enough that I didn't want to mess with it (instead, the LZ compression being used merely to reduce the number of sectors read/written, but not necessarily to consolidate writes to the pagefile).
Granted, a linear log isn't too complicated initially, but gets much more complicated when one needs to wrap around back to the start of the log (and then needs to start consolidating any still-live data from these prior blocks into the new blocks being written; or across multiple blocks if consolidating would not free up enough space to add the new data; worst case potentially "pretty bad").
Though, worst case could be reduced if the block-packing code tries to avoid packing blocks to more than around 70% capacity or so.
...

Pointer Authentication Code in ARMv8.3 is usable within functions, but
has problems, in that compilers can't readily tell if stored pointers
have PAC signatures.
 Branch Target Indicators in ARMv8.5 work quite well, but need linker and
loader support.
 PAC and BTI use instructions that are no-ops in earlier versions of ARM64,
but you really ought to test that they work before releasing binaries
that include them. I've done that on Android, where I had the combination
of hardware, OS and compiler to do it.
 Once I can get an ARM Linux server with the hardware support, Linux
kernel 5.0 onwards and modern GCC will let me do it there. Windows and
macOS on ARM both lack some pieces, and iOS requires you to change ABIs
and drop support for older 64-bit devices.
 

Hmm.

John