linux-kernel - Re: [PATCH] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR

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] [day] [month] [year] [list]

Date:	Mon, 13 Jun 2016 14:25:17 +0100
From:	Suzuki K Poulose <Suzuki.Poulose@....com>
To:	Will Deacon <will.deacon@....com>
Cc:	catalin.marinas@....com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, steve.capper@...aro.org,
	Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] arm64: cpuinfo: Expose MIDR_EL1 and REVIDR_EL1 to sysfs

On 13/06/16 13:37, Will Deacon wrote:
> On Mon, Jun 13, 2016 at 01:02:36PM +0100, Suzuki K Poulose wrote:
>> On 10/06/16 18:02, Will Deacon wrote:
>>> On Fri, Jun 10, 2016 at 04:19:44PM +0100, Suzuki K Poulose wrote:
>>>> From: Steve Capper <steve.capper@...aro.org>
>>>>
>>>> It can be useful for JIT software to be aware of MIDR_EL1 and
>>>> REVIDR_EL1 to ascertain the presence of any core errata that could
>>>> affect codegen.
>>>>
>>>> This patch exposes these registers through sysfs:
>>>>
>>>> /sys/devices/system/cpu/cpu$ID/identification/midr
>>>> /sys/devices/system/cpu/cpu$ID/identification/revidr
>>
>>
>>>> +
>>>> +#define CPUINFO_ATTR_RO(_name)							\
>>>> +	static ssize_t show_##_name (struct device *dev,			\
>>>> +			struct device_attribute *attr, char *buf)		\
>>>> +	{									\
>>>> +		struct cpuinfo_arm64 *info = &per_cpu(cpu_data, dev->id);	\
>>>> +		if (!cpu_present(dev->id))					\
>>>> +			return -ENODEV;						\
>>>> +										\
>>>> +		if (info->reg_midr)						\
>>>> +			return sprintf(buf, "0x%016x\n", info->reg_##_name);	\
>>>
>>> Should this be 0x%08x, as these are 32-bit registers?
>>
>> Yes. Will change it. As per Mark's comments, I can change them to 64bit in
>> a separate patch
>
> No -- this is a sysfs ABI and I think we should be consistent from the
> beginning. I'm fine with having them 64-bit, since Mark's comments make
> sense, but a comment justifying that would be a good idea.

OK. Will add a comment then.

Thanks
Suzuki