On 07/04/2022 15:27, Jan Beulich wrote:
> On 07.04.2022 03:01, Andrew Cooper wrote:
>> c/s 1a914256dca5 increased the AMD max leaf from 0x8000001c to 0x80000021,
>> but
>> did not adjust anything in the calculate_*_policy() chain. As a result, on
>> hardware supporting these leaves, we read the real hardware values into the
>> raw policy, then copy into host, and all the way into the PV/HVM default
>> policies.
>>
>> All 4 of these leaves have enable bits (first two by TopoExt, next by SEV,
>> next by PQOS), so any software following the rules is fine and will leave
>> them
>> alone. However, leaf 0x8000001d takes a subleaf input and at least two
>> userspace utilities have been observed to loop indefinitely under Xen
>> (clearly
>> waiting for eax to report "no more cache levels").
>>
>> Such userspace is buggy, but Xen's behaviour isn't great either.
> Just another remark, since I stumbled across this again while preparing
> the backports: I'm not convinced such user space is to be called buggy.
> Generic CPUID dumping tools won't normally look for particular features.
> Their knowledge is usually limited to knowing where sub-leaves exist and
> how to determine how many of them there are. Anything beyond that would
> make a supposedly simple tool complicated.
It's basic input sanitisation.
If you have elected to ignore the rules AMD sets out to correctly
interpret the data, then you get to keep all the pieces when writing an
unbounded
do {
x = read_untrusted_input();
} while ( x != 0 );
loop. The only reason zeroing the data here unbreaks userspace is
because it aliases the loop exit condition.
~Andrew
