Re: [PATCH v5 02/10] x86/resctrl: Protect against bad shift

[Reinette Chatre]

Hi Boris,

On 7/21/26 5:50 PM, Borislav Petkov wrote:
> On Tue, Jul 21, 2026 at 04:50:32PM -0700, Reinette Chatre wrote:
>> I see how such change could be considered absurd. I am ok to drop it from
>> the series and just keep treating it's report locally as a false positive.
> 
> Nah, but I'd like you, pls, to rewrite the commit message and explain more
> prominently
> 
> 1. resctrl does not support values than u32 max_bw
> 
> 2. what this is really fixing and where the potential issue can come from and
>    what the situation is today.
> 
> I'd like to have more background in the commit message why we even arrived at
> this patch.
> 
> I wouldnt've even done it - we have bigger fish to fry - but if you think it
> is important for resctrl, sure.
I am trying to help with bigger things in resctrl and find it easier to do so when
working on a baseline that is without implicit assumptions.

I plan to use changelog below that aims to address the items you highlighted and also
changed the math to make the bandwidth boundary where resctrl stop working clear:
	
	x86/resctrl: Protect against bad shift

	The size of the bandwidth field is enumerated from AMD hardware. resctrl uses   
	this field width to determine the maximum bandwidth supported that is stored in 
	resctrl_membw::max_bw. User space allocation requests ("control values") are    
	compared against this maximum for validity before being programmed to hardware. 
                                                                                
	resctrl filesystem and resctrl x86 architecture code only support u32 control   
	values: resctrl_membw::max_bw is a u32, the control value provided by user space
	is parsed into u32 local variables, and after validity checks, the control value
	is staged into the u32 resctrl_staged_config::new_ctrl for architecture         
	consumption. The resctrl x86 architecture code in turn caches the new control   
	value into the u32 array rdt_hw_ctrl_domain::ctrl_val[].                        
                                                                                
	The AMD bandwidth field to which control values are written can be up to 64 bits
	wide. While not an issue with current hardware (bandwidths that require more than
	a u32, more than 536870911.875 GB/s, seem unreasonable today), it is theoretically
	possible that enumeration of maximum bandwidth field width will return values   
	that are according to specification but cannot be supported by resctrl.         
                                                                                
	Static checkers complain about this size mismatch.                              
                                                                                
	Fix the static checker complaint by explicitly encoding the fact that resctrl is
	unable to support all values that the hardware specification allows. Switch to  
	BIT() instead of open-coding the bitshift to avoid signed integer overflow if   
	the number of bits is a valid 31.                        

Reinette