linux-kernel - Re: [PATCH 2/5] arm64: cpufeature: Track unsigned fields

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

Message-ID: <564D9E61.8010802@arm.com>
Date:	Thu, 19 Nov 2015 10:03:13 +0000
From:	"Suzuki K. Poulose" <Suzuki.Poulose@....com>
To:	AKASHI Takahiro <takahiro.akashi@...aro.org>,
	linux-arm-kernel@...ts.infradead.org
Cc:	catalin.marinas@....com, will.deacon@....com, mark.rutland@....com,
	ard.biesheuvel@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] arm64: cpufeature: Track unsigned fields

On 19/11/15 04:57, AKASHI Takahiro wrote:
> Hi
>
>  From my curiosity,
> can you please clarify your criteria regarding which fields of a register should be signed or unsigned?
> I guessed that the fields marked with FTR_LOWER_SAFE or FTR_HIGHER_SAFE could be unsigned,
> but it seems to be not always true looking at your patch.
> Anyhow, for example,

...

>> -    ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0),
>> +    U_ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0),
>>       ARM64_FTR_END,
>>   };
>
> BigEnd, bits[11:8], is 0b0000 for "No mixed-endian support", and 0b0001 for
> "Mixed-endian support". But can any other value be possible? If not, why signed?
> If there are some hidden (or undocumented) specifications, as Ard mentioned, that's fine.
> Please ignore my comments.

There are no hidden specifications, but just that they are undocumented. To be precise,
the criteria I selected was based on the meaning of their values.

1) If value represents something which cannot be negative and hence should be treated as
    unsigned.
    e.g, number of break points ID_AA64DFR0:BRPs.

    
2) If the individual values are mapped to some other values which cannot be negative, but have
    LOWER_SAFE/HIGHER_SAFE relation.
     e.g,  CTR_EL0:WRG - Log2 of the write granule size.
	  ID_AA64MMFR0:PARANGE - Supported PA Size


Thanks
Suzuki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/