On Mon, 24 Aug 2026 13:26:15 GMT, Andrew Haley <[email protected]> wrote:

>>> However, I don't think that can happen in practice because of the 
>>> `@IntrinsicCandidate` annotation. A transform based on profiling info could 
>>> only be used when compiling `conditionalSet` in which case a call to the 
>>> intrinsic would override the inlining operation and speculative 
>>> transformation.
>> 
>> If there is an intrinsic, sure. I'm saying that security should not depend 
>> on whether an intrinsic is enabled. To be more explicit: constant-time 
>> execution is part of the specification of this method, and it fails to meet 
>> its specification. Now, you might argue that it is impossible to guarantee 
>> constant time in a method written in Java, and I might agree.
>> 
>> What we really need is a value speculation barrier. That doesn't sound so 
>> difficult: it could be a node that has a value-range type as its input and 
>> the corresponding type as its output. Either that, or we have a two-input 
>> selection node semantically `t ? a : b` and we make sure it gets propagated 
>> all the way through C2. Anything less is just rearranging the deck chairs.
>
>> constant-time execution is part of the specification of this method
> 
> Mea culpa: the spec is "branchless", but I think we know the implication.
> 
>> `t ? a : b`
> 
> Or, more generally, any permutation:
> 
> `anR = t ? R(a, b) : R(b, a);`

> If there is an intrinsic, sure. I'm saying that security should not depend on 
> whether an intrinsic is enabled. To be more explicit: constant-time execution 
> is part of the specification of this method, and it fails to meet its 
> specification. Now, you might argue that it is impossible to guarantee 
> constant time in a method written in Java, and I might agree.

Well, yes, but that's a general problem that we face irrespective of what we do 
with regard to this test i.e. it's a problem for a follow-up RFE to fix, not 
this one. The simplest action needed to allow this test to be useful for the 
cases where we *do* have an intrinsic is to disable inlining of 
`conditionalSet`. We could perhaps also limit it to only run on os/cpu 
combinations where we have an intrinsic so we don't get a bogus result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/32047#discussion_r3844032495

Reply via email to