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.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/dd9fc3505c0ed250c5f14898b0ed6d7460a3cb82.1784753375.git.reinette.chatre@intel.com

0 files changed, 0 insertions, 0 deletions