Bugzilla – Bug 1178760
VUL-0: CVE-2020-12912: kernel-source: AMD: unprivileged access to RAPL allows for side channel attacks
Last modified: 2024-06-25 15:26:03 UTC
A flaw in the Linux kernels implementation of RAPL for AMD CPUS allowed a user with a local account to use the RAPL interface to infer CPU execution state. This could allow information leak of sensitive information across security boundaries. References: https://bugzilla.redhat.com/show_bug.cgi?id=1897402 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-12912 https://access.redhat.com/security/cve/CVE-2020-12912 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912 https://www.amd.com/en/corporate/product-security
(this is for AMD; not for Intel)
(In reply to Marcus Meissner from comment #1) > (this is for AMD; not for Intel) But they are both exporting data via the same powercap driver, right? So we should be only adding the CVE reference into the existing patch.
i do not know. the fix is in the common sysfs code, yes.
driver seems to be in drivers/hwmon/amd_energy.c using the hwmon framework hwmon seems to generally pass out world readable permisssions -> so different place, needing different fix?
seems to be however only Linux Kernel 5.8 or newer
(In reply to Marcus Meissner from comment #4) > driver seems to be in drivers/hwmon/amd_energy.c > > using the hwmon framework > > hwmon seems to generally pass out world readable permisssions > > -> so different place, needing different fix? If it's about hwmon, the sysfs creation is done in the core, but its permission is controlled via is_visible callback. I guess just adjusting the value in amd_energy_is_visible() to 0400 should work. Adding Jean to Cc, as he must have better clue for hwmon. (In reply to Marcus Meissner from comment #5) > seems to be however only Linux Kernel 5.8 or newer Yes, it looks so. SLE15-SP3 already has the backport, but SLE15-SP2 doesn't. So only TW is the released product.
As usual, all the references are incredibly vague as to what the actual attack vector is. Without a clear description of the problem, I can't possibly suggest a smart workaround. Oh well. Upstream went for mode 0440 for the sysfs attribute file: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60268b0e8258fdea9a3c9f4b51e161c123571db3 I suppose we want to backport this commit. Unfortunately this will make the driver essentially useless, as "sensors" and graphical front-ends to hwmon drivers are meant to run as non-root users. Note that sysfs attribute permissions can be changed by root at any time, the driver only decides the initial permissions. So people willing to take the risk can always undo the change above in user-space.
the attack is described in https://platypusattack.com/ (basically different power consumption depnding on cryptographic key material input allowed extracting it.) I was not aware that AMD also provded this kind of very finegrained power metering.
(In reply to Jean Delvare from comment #7) > As usual, all the references are incredibly vague as to what the actual > attack vector is. Without a clear description of the problem, I can't > possibly suggest a smart workaround. Oh well. > > Upstream went for mode 0440 for the sysfs attribute file: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=60268b0e8258fdea9a3c9f4b51e161c123571db3 > > I suppose we want to backport this commit. Unfortunately this will make the > driver essentially useless, as "sensors" and graphical front-ends to hwmon > drivers are meant to run as non-root users. > > Note that sysfs attribute permissions can be changed by root at any time, > the driver only decides the initial permissions. So people willing to take > the risk can always undo the change above in user-space. For the device file permissions, usually logind tweaks via ACL for desktop users. We might provide a similar trick if it's really needed. In anyway, if there's any other better way, I'm going to backport the fix to SLE15-SP2 and cve/* branches.
We have to follow upstream anyway. The amd_energy driver is not in SLE15 SP2 though, so you don't have to backport the patch there. It's only needed in SLE15 SP3 because there was a feature request to add the amd_energy driver thereto. I'm going to deal with SLE15 SP3 if that's OK with you, that way I get the opportunity to also backport all other upstream changes to the driver since my initial backport. That way our version of the driver in SP3 will be as close to the upstream one as possible.
(In reply to Jean Delvare from comment #10) > I'm going to deal with SLE15 SP3 if that's OK with you, that way I get the > opportunity to also backport all other upstream changes to the driver since > my initial backport. That way our version of the driver in SP3 will be as > close to the upstream one as possible. Sure, please go ahead. I reassign this to you now. Please reassign back to security team once after you backport finished. Thanks.
done
SUSE-SU-2023:4625-1: An update that solves three vulnerabilities and has one security fix can now be installed. Category: security (important) Bug References: 1170415, 1170446, 1178760, 1217513 CVE References: CVE-2020-12912, CVE-2020-8694, CVE-2020-8695 Sources used: Containers Module 12 (src): runc-1.1.10-16.40.1, docker-24.0.7_ce-98.103.1, containerd-1.7.8-16.88.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2023:4936-1: An update that solves three vulnerabilities, contains one feature and has five security fixes can now be installed. Category: security (important) Bug References: 1170415, 1170446, 1178760, 1210141, 1213229, 1213500, 1215323, 1217513 CVE References: CVE-2020-12912, CVE-2020-8694, CVE-2020-8695 Jira References: PED-6180 Sources used: openSUSE Leap Micro 5.3 (src): docker-24.0.7_ce-150000.190.4 openSUSE Leap Micro 5.4 (src): docker-24.0.7_ce-150000.190.4 openSUSE Leap 15.4 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4 openSUSE Leap 15.5 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro for Rancher 5.3 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro 5.3 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro for Rancher 5.4 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro 5.4 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro 5.5 (src): docker-24.0.7_ce-150000.190.4 Containers Module 15-SP4 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4 Containers Module 15-SP5 (src): rootlesskit-1.1.1-150000.1.3.3, docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise High Performance Computing 15 SP1 LTSS 15-SP1 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP3 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Server 15 SP1 LTSS 15-SP1 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Server for SAP Applications 15 SP1 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): docker-24.0.7_ce-150000.190.4 SUSE Enterprise Storage 7.1 (src): docker-24.0.7_ce-150000.190.4 SUSE CaaS Platform 4.0 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro 5.1 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro 5.2 (src): docker-24.0.7_ce-150000.190.4 SUSE Linux Enterprise Micro for Rancher 5.2 (src): docker-24.0.7_ce-150000.190.4 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.