[MODERATED] Re: [PATCH] Raffle 0

[MODERATED] Re: [PATCH] Raffle 0

[Greg KH]

On Mon, Jul 13, 2020 at 05:03:44PM -0700, speck for Pawan Gupta wrote:
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Subject: [PATCH] powercap: restrict energy meter to root access
> 
> From: Len Brown <len.brown@intel.com>
> 
> Remove non-privileged user access to power data contained in
> /sys/class/powercap/intel_rapl/*/energy_uj
> 
> Non-privileged users currently have read access to power data and can
> use this data to form a security attack.  Some privileged
> drivers/applications need read access to this data but don't expose it
> to non-privileged users.
> 
> For example, thermald uses this data to ensure that power management
> works correctly.  Thus removing non-privileged access is preferred over
> completely disabling this power reporting capability with
> CONFIG_INTEL_RAPL=n.
> 
> Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter")
> Signed-off-by: Len Brown <len.brown@intel.com>

So you forwarded on a patch from someone else but did not put your own
signed-off-by on it?  That's not good :(

Also, why is this being sent to speck?  What is wrong with the normal
development process?

thanks,

greg k-h

[MODERATED] Re: [PATCH] Raffle 0

[Greg KH]

On Mon, Jul 13, 2020 at 05:03:44PM -0700, speck for Pawan Gupta wrote:
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Subject: [PATCH] powercap: restrict energy meter to root access
> 
> From: Len Brown <len.brown@intel.com>
> 
> Remove non-privileged user access to power data contained in
> /sys/class/powercap/intel_rapl/*/energy_uj
> 
> Non-privileged users currently have read access to power data and can
> use this data to form a security attack.  Some privileged
> drivers/applications need read access to this data but don't expose it
> to non-privileged users.
> 
> For example, thermald uses this data to ensure that power management
> works correctly.  Thus removing non-privileged access is preferred over
> completely disabling this power reporting capability with
> CONFIG_INTEL_RAPL=n.
> 
> Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter")
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/powercap/powercap_sys.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Also, any reason you didn't run this through checkpatch.pl first?

[MODERATED] Re: [PATCH] Raffle 0

[Greg KH]

On Mon, Jul 13, 2020 at 05:03:44PM -0700, speck for Pawan Gupta wrote:
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Subject: [PATCH] powercap: restrict energy meter to root access
> 
> From: Len Brown <len.brown@intel.com>
> 
> Remove non-privileged user access to power data contained in
> /sys/class/powercap/intel_rapl/*/energy_uj
> 
> Non-privileged users currently have read access to power data and can
> use this data to form a security attack.  Some privileged
> drivers/applications need read access to this data but don't expose it
> to non-privileged users.
> 
> For example, thermald uses this data to ensure that power management
> works correctly.  Thus removing non-privileged access is preferred over
> completely disabling this power reporting capability with
> CONFIG_INTEL_RAPL=n.
> 
> Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter")
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/powercap/powercap_sys.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c
> index f808c5fa9838..3f0b8e2ef3d4 100644
> --- a/drivers/powercap/powercap_sys.c
> +++ b/drivers/powercap/powercap_sys.c
> @@ -367,9 +367,9 @@ static void create_power_zone_common_attributes(
>  					&dev_attr_max_energy_range_uj.attr;
>  	if (power_zone->ops->get_energy_uj) {
>  		if (power_zone->ops->reset_energy_uj)
> -			dev_attr_energy_uj.attr.mode = S_IWUSR | S_IRUGO;
> +			dev_attr_energy_uj.attr.mode = S_IWUSR | S_IRUSR;
>  		else
> -			dev_attr_energy_uj.attr.mode = S_IRUGO;
> +			dev_attr_energy_uj.attr.mode = S_IRUSR;
>  		power_zone->zone_dev_attrs[count++] =
>  					&dev_attr_energy_uj.attr;
>  	}

On a meta-level, this function is all wrong.  The list of attributes
should always be fixed, and the "is_visable" callback should be the
thing that both sets the mode, and determines if the specific attribute
should be present or not for that specific device.

So fixing that all up to work "properly" would make a lot more sense.

thanks,

greg k-h

[MODERATED] Re: [PATCH] Raffle 0

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On 14/07/2020 06:57, speck for Greg KH wrote:
> Also, why is this being sent to speck?  What is wrong with the normal
> development process?

This has a CVE attached to it, and an embargo in November (both of which
ought to be more clear in the email and/or commit message IMO).

Researchers have demonstrated a power analysis side-channel to recover
keys from the AES-NI instructions, usable by unprivileged userspace
given these world-usable perms.

~Andrew

[MODERATED] Re: [PATCH] Raffle 0

[Greg KH]

On Tue, Jul 14, 2020 at 09:03:41AM +0100, speck for Andrew Cooper wrote:
> On 14/07/2020 06:57, speck for Greg KH wrote:
> > Also, why is this being sent to speck?  What is wrong with the normal
> > development process?
> 
> This has a CVE attached to it, and an embargo in November (both of which
> ought to be more clear in the email and/or commit message IMO).

That was totally not obvious, how were we supposed to guess that?

> Researchers have demonstrated a power analysis side-channel to recover
> keys from the AES-NI instructions, usable by unprivileged userspace
> given these world-usable perms.

Ok, then why send this to us now, why not just submit this to upstream
at the proper time when the embargo expires?  Why do we now need to sit
on this for the next 4 fricken months?

You all are just asking for us to be hauled up before a government
committee _again_, aren't you?

{sigh}

greg k-h

[MODERATED] Re: [PATCH] Raffle 0

[Greg KH]

On Tue, Jul 14, 2020 at 10:14:09AM +0200, speck for Greg KH wrote:
> On Tue, Jul 14, 2020 at 09:03:41AM +0100, speck for Andrew Cooper wrote:
> > On 14/07/2020 06:57, speck for Greg KH wrote:
> > > Also, why is this being sent to speck?  What is wrong with the normal
> > > development process?
> > 
> > This has a CVE attached to it, and an embargo in November (both of which
> > ought to be more clear in the email and/or commit message IMO).
> 
> That was totally not obvious, how were we supposed to guess that?
> 
> > Researchers have demonstrated a power analysis side-channel to recover
> > keys from the AES-NI instructions, usable by unprivileged userspace
> > given these world-usable perms.
> 
> Ok, then why send this to us now, why not just submit this to upstream
> at the proper time when the embargo expires?  Why do we now need to sit
> on this for the next 4 fricken months?

And why sit on this at all anyway?  Just submit the patch changing the
permissions as it's probably the right thing to do independent of
anything else anyway.

After the submitter fixes up the things I pointed out, of course.

thanks,

greg k-h

[MODERATED] Re: [PATCH] Raffle 0

[Andrew Cooper]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On 14/07/2020 09:20, speck for Greg KH wrote:
> On Tue, Jul 14, 2020 at 10:14:09AM +0200, speck for Greg KH wrote:
>> On Tue, Jul 14, 2020 at 09:03:41AM +0100, speck for Andrew Cooper wrote:
>>> On 14/07/2020 06:57, speck for Greg KH wrote:
>>>> Also, why is this being sent to speck?  What is wrong with the normal
>>>> development process?
>>> This has a CVE attached to it, and an embargo in November (both of which
>>> ought to be more clear in the email and/or commit message IMO).
>> That was totally not obvious, how were we supposed to guess that?

Clearly need to improve our divination skills...

(It is part of the bundle of issues for the next IPU.)

>>> Researchers have demonstrated a power analysis side-channel to recover
>>> keys from the AES-NI instructions, usable by unprivileged userspace
>>> given these world-usable perms.
>> Ok, then why send this to us now, why not just submit this to upstream
>> at the proper time when the embargo expires?  Why do we now need to sit
>> on this for the next 4 fricken months?
> And why sit on this at all anyway?

The companion CVE, for a malicious kernel attacking SGX with this
mechanism, needs a microcode change, which is why they are bundled together.

~Andrew

[MODERATED] Re: [PATCH] Raffle 0

[Greg KH]

On Tue, Jul 14, 2020 at 09:36:47AM +0100, speck for Andrew Cooper wrote:
> On 14/07/2020 09:20, speck for Greg KH wrote:
> > On Tue, Jul 14, 2020 at 10:14:09AM +0200, speck for Greg KH wrote:
> >> On Tue, Jul 14, 2020 at 09:03:41AM +0100, speck for Andrew Cooper wrote:
> >>> On 14/07/2020 06:57, speck for Greg KH wrote:
> >>>> Also, why is this being sent to speck?  What is wrong with the normal
> >>>> development process?
> >>> This has a CVE attached to it, and an embargo in November (both of which
> >>> ought to be more clear in the email and/or commit message IMO).
> >> That was totally not obvious, how were we supposed to guess that?
> 
> Clearly need to improve our divination skills...
> 
> (It is part of the bundle of issues for the next IPU.)

I don't know what "IPU" means :(

> >>> Researchers have demonstrated a power analysis side-channel to recover
> >>> keys from the AES-NI instructions, usable by unprivileged userspace
> >>> given these world-usable perms.
> >> Ok, then why send this to us now, why not just submit this to upstream
> >> at the proper time when the embargo expires?  Why do we now need to sit
> >> on this for the next 4 fricken months?
> > And why sit on this at all anyway?
> 
> The companion CVE, for a malicious kernel attacking SGX with this
> mechanism, needs a microcode change, which is why they are bundled together.

But again, that's independant of this sysfs file permissions, right?
Why can't you just fix this now, so when the other mess is finally
public you don't have to worry about it.

Much like I did for the random number stuff, we fixed the kernel up to
not depend on it way before Intel came up with BIOS fixes and the other
stuff.  Get ahead of the issue if at all possible.

thanks,

greg k-h

[MODERATED] Do we need this list anymore? (was Re: [PATCH] Raffle 0)

[Greg KH]

On Tue, Jul 14, 2020 at 09:03:41AM +0100, speck for Andrew Cooper wrote:
> On 14/07/2020 06:57, speck for Greg KH wrote:
> > Also, why is this being sent to speck?  What is wrong with the normal
> > development process?
> 
> This has a CVE attached to it, and an embargo in November (both of which
> ought to be more clear in the email and/or commit message IMO).
> 
> Researchers have demonstrated a power analysis side-channel to recover
> keys from the AES-NI instructions, usable by unprivileged userspace
> given these world-usable perms.

Ok, that's something new, can we just tear down this list now and if we
need new lists, create them as we have documented in:
	https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html

That way, when we create a new list, we know what it is for, there's a
set time limit on it, and no one is confused like this patch caused.

We are already doing this for other issues happening, why shouldn't we
do it for this one as well?

thanks,

greg k-h

Re: Do we need this list anymore? (was Re: [PATCH] Raffle 0)

[Thomas Gleixner]

speck for Greg KH <speck@linutronix.de> writes:
> Ok, that's something new, can we just tear down this list now and if we
> need new lists, create them as we have documented in:
> 	https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
>
> That way, when we create a new list, we know what it is for, there's a
> set time limit on it, and no one is confused like this patch caused.
>
> We are already doing this for other issues happening, why shouldn't we
> do it for this one as well?

I'm happy to shut this thing down.

[MODERATED] Re: [PATCH] Raffle 0

[Pawan Gupta]

On Tue, Jul 14, 2020 at 08:01:28AM +0200, speck for Greg KH wrote:
> On Mon, Jul 13, 2020 at 05:03:44PM -0700, speck for Pawan Gupta wrote:
> > From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > Subject: [PATCH] powercap: restrict energy meter to root access
> > 
> > From: Len Brown <len.brown@intel.com>
> > 
> > Remove non-privileged user access to power data contained in
> > /sys/class/powercap/intel_rapl/*/energy_uj
> > 
> > Non-privileged users currently have read access to power data and can
> > use this data to form a security attack.  Some privileged
> > drivers/applications need read access to this data but don't expose it
> > to non-privileged users.
> > 
> > For example, thermald uses this data to ensure that power management
> > works correctly.  Thus removing non-privileged access is preferred over
> > completely disabling this power reporting capability with
> > CONFIG_INTEL_RAPL=n.
> > 
> > Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter")
> > Signed-off-by: Len Brown <len.brown@intel.com>
> > ---
> >  drivers/powercap/powercap_sys.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c
> > index f808c5fa9838..3f0b8e2ef3d4 100644
> > --- a/drivers/powercap/powercap_sys.c
> > +++ b/drivers/powercap/powercap_sys.c
> > @@ -367,9 +367,9 @@ static void create_power_zone_common_attributes(
> >  					&dev_attr_max_energy_range_uj.attr;
> >  	if (power_zone->ops->get_energy_uj) {
> >  		if (power_zone->ops->reset_energy_uj)
> > -			dev_attr_energy_uj.attr.mode = S_IWUSR | S_IRUGO;
> > +			dev_attr_energy_uj.attr.mode = S_IWUSR | S_IRUSR;
> >  		else
> > -			dev_attr_energy_uj.attr.mode = S_IRUGO;
> > +			dev_attr_energy_uj.attr.mode = S_IRUSR;
> >  		power_zone->zone_dev_attrs[count++] =
> >  					&dev_attr_energy_uj.attr;
> >  	}
> 
> On a meta-level, this function is all wrong.  The list of attributes
> should always be fixed, and the "is_visable" callback should be the
> thing that both sets the mode, and determines if the specific attribute
> should be present or not for that specific device.
> 
> So fixing that all up to work "properly" would make a lot more sense.

Thank you for your comments. These have been shared with the author.

Sorry for not giving enough context on the issue. The original author of
the patch is not on this list and I was acting as a messenger. There are
talks going on within Intel on the process improvement there will be
shared something soon.

Thanks,
Pawan

[MODERATED] Re: Do we need this list anymore? (was Re: [PATCH] Raffle 0)

[Gomez Iglesias, Antonio]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

Greg, Thomas,
 
We agree we can shut down this list and use new ones as required for
individual issues.
 
For those in this list but not in Keybase: if you are interested in
receiving futurue notifications and other information like presentations
and papers that we share on Keybase, send me your public key (
antonio.gomez.iglesias@linux.intel.com ). I’ll use it to share that
information with you.
 
Thomas, would you mind sharing with me the scripts that you used to
create this list?
 
Thanks,
Antonio

On 7/14/2020 08:34, speck for Thomas Gleixner wrote:
> speck for Greg KH <speck@linutronix.de> writes:
>> Ok, that's something new, can we just tear down this list now and if we
>> need new lists, create them as we have documented in:
>> 	https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
>>
>> That way, when we create a new list, we know what it is for, there's a
>> set time limit on it, and no one is confused like this patch caused.
>>
>> We are already doing this for other issues happening, why shouldn't we
>> do it for this one as well?
> I'm happy to shut this thing down.

Re: Do we need this list anymore? (was Re: [PATCH] Raffle 0)

[Thomas Gleixner]

speck for "Gomez Iglesias, Antonio" <speck@linutronix.de> writes:
> Thomas, would you mind sharing with me the scripts that you used to
> create this list?

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/remail.git

The kernel.org infrastructure provides a service for such list instances
and as Greg said, this is part of our process to handle such issues as
documented in:

 https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html

So we create the lists when a new issue is reported and manage it
according to our rules.

Thanks,

        tglx