summaryrefslogtreecommitdiff
path: root/fs/ecryptfs/ecryptfs_kernel.h
diff options
context:
space:
mode:
authorMark Rutland <mark.rutland@arm.com>2017-02-23 16:03:17 +0000
committerWill Deacon <will.deacon@arm.com>2017-02-24 11:14:12 +0000
commit638f863dbbc8da16834ee0acc6ac10754f79c486 (patch)
tree0cedb24f37dbbd00fd95d55d8ac6f1b0e2f85ed9 /fs/ecryptfs/ecryptfs_kernel.h
parentd81bbe6d882461dec4b71dbe2aa85565fcca4187 (diff)
arm64/cpufeature: check correct field width when updating sys_val
When we're updating a register's sys_val, we use arm64_ftr_value() to find the new field value. We use cpuid_feature_extract_field() to find the new value, but this implicitly assumes a 4-bit field, so we may extract more bits than we mean to for fields like CTR_EL0.L1ip. This affects update_cpu_ftr_reg(), where we may extract erroneous values for ftr_cur and ftr_new. Depending on the additional bits extracted in either case, we may erroneously detect that the value is mismatched, and we'll try to compute a new safe value. Dependent on these extra bits and feature type, arm64_ftr_safe_value() may pessimistically select the always-safe value, or may erroneously choose either the extracted cur or new value as the safe option. The extra bits will subsequently be masked out in arm64_ftr_set_value(), so we may choose a higher value, yet write back a lower one. Fix this by passing the width down explicitly in arm64_ftr_value(), so we always extract the correct amount. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
Diffstat (limited to 'fs/ecryptfs/ecryptfs_kernel.h')
0 files changed, 0 insertions, 0 deletions