Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: ARM is channeling the IBM 360
Date: Sat, 22 Jun 2024 15:37:49 -0500
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <v57cn0$3u221$1@dont-email.me>
References: <bebb9f88a6677b4894478a3dabc8b2c9@www.novabbs.org>
 <memo.20240622115820.956C@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 22 Jun 2024 22:37:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5dd14afd54cdbf97019dfe69595741cf";
	logging-data="4130881"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19+Ypd1RTBsryh7P4fLh8tKKy6rI31ONI8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IaXvQt9CKSjxctqX4Vc4BfM6VIo=
In-Reply-To: <memo.20240622115820.956C@jgd.cix.co.uk>
Content-Language: en-US
Bytes: 4869

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