> -----Original Message-----
> From: Sasha Levin [mailto:sashal@kernel.org]
> Sent: Wednesday, February 5, 2020 3:45 PM
> To: Sasha Levin <sashal(a)kernel.org>; Roberto Sassu
> <roberto.sassu(a)huawei.com>; zohar(a)linux.ibm.com;
> James.Bottomley(a)HansenPartnership.com
> Cc: linux-integrity(a)vger.kernel.org; stable(a)vger.kernel.org;
> stable(a)vger.kernel.org
> Subject: Re: [PATCH v2 2/8] ima: Switch to ima_hash_algo for boot
> aggregate
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.5.1, v5.4.17, v4.19.101, v4.14.169,
> v4.9.212, v4.4.212.
>
> v5.5.1: Build OK!
> v5.4.17: Build OK!
> v4.19.101: Failed to apply! Possible dependencies:
> 100b16a6f290 ("tpm: sort objects in the Makefile")
> 1ad6640cd614 ("tpm: move tpm1_pcr_extend to tpm1-cmd.c")
> 70a3199a7101 ("tpm: factor out tpm_get_timeouts()")
> 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with PCR
> read")
Hi Sasha
this patch is necessary. However, backporting it won't be that easy
as it was part of a patch set. Before this patch, users of the TPM driver
could only read the SHA1 PCR bank. The IMA patch needs to read also
other PCR banks.
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
This question should be for Jarkko (added in CC), as some patches for the
TPM driver must be backported to apply the IMA patch.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
According to the "Intel 64 and IA-32 Architectures Software Developer’s
Manual Volume 4: Model-Specific Registers" on Cherry Trail (Airmont)
devices the 4 lowest bits of the MSR_FSB_FREQ mask indicate the bus freq
unlike on e.g. Bay Trail where only the lowest 3 bits are used.
This is also the reason why MAX_NUM_FREQS is defined as 9, since
Cherry Trail SoCs have 9 possible frequencies, so we need to mask
the lo value from the MSR with 0x0f, not with 0x07 otherwise the
9th frequency will get interpreted as the 1st.
This commits bumps MAX_NUM_FREQS to 16 to avoid any possibility of
addressing the array out of bounds and makes the mask part of
the cpufreq struct so that we can set it per model.
While at it also log an error when the index points to an uninitialized
part of the freqs lookup-table.
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
arch/x86/kernel/tsc_msr.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 5fa41ac3feb1..95030895fffa 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -15,7 +15,7 @@
#include <asm/param.h>
#include <asm/tsc.h>
-#define MAX_NUM_FREQS 9
+#define MAX_NUM_FREQS 16 /* 4 bits to select the frequency */
/*
* If MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be
@@ -27,6 +27,7 @@
struct freq_desc {
bool use_msr_plat;
u32 freqs[MAX_NUM_FREQS];
+ u32 mask;
};
/*
@@ -37,37 +38,44 @@ struct freq_desc {
static const struct freq_desc freq_desc_pnw = {
.use_msr_plat = false,
.freqs = { 0, 0, 0, 0, 0, 99840, 0, 83200 },
+ .mask = 0x07,
};
static const struct freq_desc freq_desc_clv = {
.use_msr_plat = false,
.freqs = { 0, 133200, 0, 0, 0, 99840, 0, 83200 },
+ .mask = 0x07,
};
static const struct freq_desc freq_desc_byt = {
.use_msr_plat = true,
.freqs = { 83300, 100000, 133300, 116700, 80000, 0, 0, 0 },
+ .mask = 0x07,
};
static const struct freq_desc freq_desc_cht = {
.use_msr_plat = true,
.freqs = { 83300, 100000, 133300, 116700, 80000, 93300, 90000,
88900, 87500 },
+ .mask = 0x0f,
};
static const struct freq_desc freq_desc_tng = {
.use_msr_plat = true,
.freqs = { 0, 100000, 133300, 0, 0, 0, 0, 0 },
+ .mask = 0x07,
};
static const struct freq_desc freq_desc_ann = {
.use_msr_plat = true,
.freqs = { 83300, 100000, 133300, 100000, 0, 0, 0, 0 },
+ .mask = 0x0f,
};
static const struct freq_desc freq_desc_lgm = {
.use_msr_plat = true,
.freqs = { 78000, 78000, 78000, 78000, 78000, 78000, 78000, 78000 },
+ .mask = 0x0f,
};
static const struct x86_cpu_id tsc_msr_cpu_ids[] = {
@@ -93,6 +101,7 @@ unsigned long cpu_khz_from_msr(void)
const struct freq_desc *freq_desc;
const struct x86_cpu_id *id;
unsigned long res;
+ int index;
id = x86_match_cpu(tsc_msr_cpu_ids);
if (!id)
@@ -109,13 +118,17 @@ unsigned long cpu_khz_from_msr(void)
/* Get FSB FREQ ID */
rdmsr(MSR_FSB_FREQ, lo, hi);
+ index = lo & freq_desc->mask;
/* Map CPU reference clock freq ID(0-7) to CPU reference clock freq(KHz) */
- freq = freq_desc->freqs[lo & 0x7];
+ freq = freq_desc->freqs[index];
/* TSC frequency = maximum resolved freq * maximum resolved bus ratio */
res = freq * ratio;
+ if (freq == 0)
+ pr_err("Error MSR_FSB_FREQ index %d is unknown\n", index);
+
#ifdef CONFIG_X86_LOCAL_APIC
lapic_timer_period = (freq * 1000) / HZ;
#endif
--
2.24.1
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 4.4+
The bot has tested the following trees: v5.5.1, v5.4.17, v4.19.101, v4.14.169, v4.9.212, v4.4.212.
v5.5.1: Build OK!
v5.4.17: Build OK!
v4.19.101: Build OK!
v4.14.169: Build OK!
v4.9.212: Build failed! Errors:
fs/btrfs/extent_map.c:238:6: error: implicit declaration of function ‘refcount_read’ [-Werror=implicit-function-declaration]
v4.4.212: Build failed! Errors:
fs/btrfs/extent_map.c:238:6: error: implicit declaration of function ‘refcount_read’ [-Werror=implicit-function-declaration]
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
Congratulations,
Your email was randomly selected for the 2020 first quarter reimbursement via certified ATM CARD. Please reach Mrs. Sarah Buchiri with your code:U.N.D.C/2020/10/0109 for more information.
Contact Name: Mrs. Sarah Buchiri
Email: sarah.buchiri(a)gmail.com
Robert Andrew Piper
Assistant Secretary-General for Development Coordination