linux-kernel - Re: 32bit resctrl? (was Re: [PATCH v2] fs/resctrl: fix domid loss precision issue)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 15 Mar 2024 09:56:50 -0700
From: Peter Newman <peternewman@...gle.com>
To: babu.moger@....com
Cc: Reinette Chatre <reinette.chatre@...el.com>, Rex Nie <rex.nie@...uarmicro.com>, 
	james.morse@....com, "x86@...nel.org" <x86@...nel.org>, "Luck, Tony" <tony.luck@...el.com>, 
	Borislav Petkov <bp@...en8.de>, fenghua.yu@...el.com, ilpo.jarvinen@...ux.intel.com, 
	linux-kernel@...r.kernel.org
Subject: Re: 32bit resctrl? (was Re: [PATCH v2] fs/resctrl: fix domid loss
 precision issue)

On Fri, Mar 15, 2024 at 9:17 AM Moger, Babu <bmoger@....com> wrote:
>
>
> On 3/14/2024 10:25 AM, Reinette Chatre wrote:
> > +x86 maintainers, Tony, Babu, Peter
> >
> > Hi Everybody,
> >
> > On 3/12/2024 12:53 AM, Rex Nie wrote:
> >> diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
> >> index 7a6f46b4edd0..096317610949 100644
> >> --- a/fs/resctrl/internal.h
> >> +++ b/fs/resctrl/internal.h
> >> @@ -94,7 +94,7 @@ union mon_data_bits {
> >>      struct {
> >>              unsigned int rid                : 10;
> >>              enum resctrl_event_id evtid     : 8;
> >> -            unsigned int domid              : 14;
> >> +            u32                             domid;
> >>      } u;
> >>   };
> >>
> > resctrl currently supports 32bit builds. Fixing this issue* in this way
>
> I have never bothered about 32bit builds.   Is Intel still testing 32bit
> builds?

I can confirm we don't have any 32-bit builds.


> The structure pointer "union mon_data_bits priv;" is created in stack
> and passed to create mondata directory. We are reading it later again in
> rdtgroup_mondata_show.
>
> How is this pointer valid again?  Shouldn't we use static pointer or
> allocate memory for the pointer?

The union is copied by value into the pointer-sized field, hence the
need for pointers to be large enough to hold this value.

-Peter