On Fri, May 15, 2020 at 01:53:32PM +0100, Szabolcs Nagy wrote:

The 05/15/2020 13:13, Catalin Marinas wrote:

quoted

On Fri, May 15, 2020 at 01:04:33PM +0100, Szabolcs Nagy wrote:

quoted

The 05/15/2020 12:27, Catalin Marinas wrote:

quoted

Thanks Szabolcs. While we are at this, no-one so far asked for the
GCR_EL1.RRND to be exposed to user (and this implies RGSR_EL1.SEED).
Since RRND=1 guarantees a distribution "no worse" than that of RRND=0, I
thought there isn't much point in exposing this configuration to the
user. The only advantage of RRND=0 I see is that the kernel can change

it seems RRND=1 is the impl specific algorithm.

Yes, that's the implementation specific algorithm which shouldn't be
worse than the standard one.

quoted

quoted

the seed randomly but, with only 4 bits per tag, it really doesn't
matter much.

Anyway, mentioning it here in case anyone is surprised later about the
lack of RRND configurability.

i'm not familiar with how irg works.

It generates a random tag based on some algorithm.

quoted

is the seed per process state that's set up at process startup in some
way? or shared (and thus effectively irg is non-deterministic in
userspace)?

The seed is only relevant if the standard algorithm is used (RRND=0).

i wanted to understand if we can get deterministic
irg behaviour in user space (which may be useful
for debugging to get reproducible tag failures).

i guess if no control is exposed that means non-
deterministic irg. i think this is fine.

Hmmm, I guess this might eventually be wanted.  But it's probably OK not
to have it to begin with.

Things like CRIU restores won't be reproducible unless the seeds can be
saved/restored.

Doesn't seem essential from day 1 though.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel