netdev - RE: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD

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]
Message-ID:
 <DM6PR12MB2619198AA122E528AA22BF9EE42EA@DM6PR12MB2619.namprd12.prod.outlook.com>
Date: Tue, 4 Jul 2023 03:24:28 +0000
From: "Quan, Evan" <Evan.Quan@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: "rafael@...nel.org" <rafael@...nel.org>, "lenb@...nel.org"
	<lenb@...nel.org>, "Deucher, Alexander" <Alexander.Deucher@....com>, "Koenig,
 Christian" <Christian.Koenig@....com>, "Pan, Xinhui" <Xinhui.Pan@....com>,
	"airlied@...il.com" <airlied@...il.com>, "daniel@...ll.ch" <daniel@...ll.ch>,
	"johannes@...solutions.net" <johannes@...solutions.net>,
	"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "Limonciello, Mario"
	<Mario.Limonciello@....com>, "mdaenzer@...hat.com" <mdaenzer@...hat.com>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"tzimmermann@...e.de" <tzimmermann@...e.de>, "hdegoede@...hat.com"
	<hdegoede@...hat.com>, "jingyuwang_vip@....com" <jingyuwang_vip@....com>,
	"Lazar, Lijo" <Lijo.Lazar@....com>, "jim.cromie@...il.com"
	<jim.cromie@...il.com>, "bellosilicio@...il.com" <bellosilicio@...il.com>,
	"andrealmeid@...lia.com" <andrealmeid@...lia.com>, "trix@...hat.com"
	<trix@...hat.com>, "jsg@....id.au" <jsg@....id.au>, "arnd@...db.de"
	<arnd@...db.de>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "amd-gfx@...ts.freedesktop.org"
	<amd-gfx@...ts.freedesktop.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "linux-wireless@...r.kernel.org"
	<linux-wireless@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>
Subject: RE: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism
 introduced by AMD

[AMD Official Use Only - General]

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Saturday, July 1, 2023 8:51 AM
> To: Quan, Evan <Evan.Quan@....com>
> Cc: rafael@...nel.org; lenb@...nel.org; Deucher, Alexander
> <Alexander.Deucher@....com>; Koenig, Christian
> <Christian.Koenig@....com>; Pan, Xinhui <Xinhui.Pan@....com>;
> airlied@...il.com; daniel@...ll.ch; johannes@...solutions.net;
> davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; Limonciello, Mario <Mario.Limonciello@....com>;
> mdaenzer@...hat.com; maarten.lankhorst@...ux.intel.com;
> tzimmermann@...e.de; hdegoede@...hat.com; jingyuwang_vip@....com;
> Lazar, Lijo <Lijo.Lazar@....com>; jim.cromie@...il.com;
> bellosilicio@...il.com; andrealmeid@...lia.com; trix@...hat.com;
> jsg@....id.au; arnd@...db.de; linux-kernel@...r.kernel.org; linux-
> acpi@...r.kernel.org; amd-gfx@...ts.freedesktop.org; dri-
> devel@...ts.freedesktop.org; linux-wireless@...r.kernel.org;
> netdev@...r.kernel.org
> Subject: Re: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism
> introduced by AMD
>
> > +   argv4 = kzalloc(sizeof(*argv4) * (2 * num_of_ranges + 2 + 1),
> GFP_KERNEL);
> > +   if (!argv4)
> > +           return -ENOMEM;
> > +
> > +   argv4[arg_idx].package.type = ACPI_TYPE_PACKAGE;
> > +   argv4[arg_idx].package.count = 2 + 2 * num_of_ranges;
> > +   argv4[arg_idx++].package.elements = &argv4[1];
> > +   argv4[arg_idx].integer.type = ACPI_TYPE_INTEGER;
> > +   argv4[arg_idx++].integer.value = num_of_ranges;
> > +   argv4[arg_idx].integer.type = ACPI_TYPE_INTEGER;
> > +   argv4[arg_idx++].integer.value = action;
>
> There is a lot of magic numbers in that kzalloc. It is being used as an array,
> kcalloc() would be a good start to make it more readable.
> Can some #define's be used to explain what the other numbers mean?
Sure, will update accordingly.
>
> > +   /*
> > +    * Bit 0 indicates whether there's support for any functions other than
> > +    * function 0.
> > +    */
>
> Please make use of the BIT macro to give the different bits informative names.
Sure.
>
> > +   if ((mask & 0x1) && (mask & funcs) == funcs)
> > +           return true;
> > +
> > +   return false;
> > +}
> > +
>
> > +int acpi_amd_wbrf_retrieve_exclusions(struct device *dev,
> > +                                 struct wbrf_ranges_out *out) {
> > +   struct acpi_device *adev = ACPI_COMPANION(dev);
> > +   union acpi_object *obj;
> > +
> > +   if (!adev)
> > +           return -ENODEV;
> > +
> > +   obj = acpi_evaluate_wbrf(adev->handle,
> > +                            WBRF_REVISION,
> > +                            WBRF_RETRIEVE);
> > +   if (!obj)
> > +           return -EINVAL;
> > +
> > +   WARN(obj->buffer.length != sizeof(*out),
> > +           "Unexpected buffer length");
> > +   memcpy(out, obj->buffer.pointer, obj->buffer.length);
>
> You WARN, and then overwrite whatever i passed the end of out?  Please at
> least use min(obj->buffer.length, sizeof(*out)), but better still:
>
>    if (obj->buffer.length != sizeof(*out)) {
>          dev_err(dev, "BIOS FUBAR, ignoring wrong sized WBRT information");
>        return -EINVAL;
>    }
OK. Sounds reasonable. Will update as suggested.
>
> > +#if defined(CONFIG_WBRF_GENERIC)
> >  static struct exclusion_range_pool wbrf_pool;
> >
> >  static int _wbrf_add_exclusion_ranges(struct wbrf_ranges_in *in) @@
> > -89,6 +92,7 @@ static int _wbrf_retrieve_exclusion_ranges(struct
> > wbrf_ranges_out *out)
> >
> >     return 0;
> >  }
> > +#endif
>
> I was expecting you would keep these tables, and then call into the BIOS as
> well. Having this table in debugfs seems like a useful thing to have for
> debugging the BIOS.
I'm not sure. Since these interfaces what we designed now kind of serve as a library.
When and where the debugfs should be created will be quite tricky.
>
> > +#ifdef CONFIG_WBRF_AMD_ACPI
> > +#else
> > +static inline bool
> > +acpi_amd_wbrf_supported_consumer(struct device *dev) { return false;
> > +} static inline bool acpi_amd_wbrf_supported_producer(struct device
> > +*dev) {return false; } static inline int
> > +acpi_amd_wbrf_remove_exclusion(struct device *dev,
> > +                          struct wbrf_ranges_in *in) { return -ENODEV; }
> static
> > +inline int acpi_amd_wbrf_add_exclusion(struct device *dev,
> > +                       struct wbrf_ranges_in *in) { return -ENODEV; } static
> inline
> > +int acpi_amd_wbrf_retrieve_exclusions(struct device *dev,
> > +                             struct wbrf_ranges_out *out) { return -
> ENODEV; }
>
> Do you actually need these stub versions?
Yes, these can be dropped. Let me update accordingly.

Evan
>
>       Andrew