linux-kernel - Re: [PATCH] x86, AMD: Correct F15h IC aliasing issue

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: <4E2F1889.8030708@amd.com>
Date:	Tue, 26 Jul 2011 21:42:01 +0200
From:	Andre Przywara <andre.przywara@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Borislav Petkov <bp@...64.org>, Avi Kivity <avi@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Pohlack, Martin" <Martin.Pohlack@....com>
Subject: Re: [PATCH] x86, AMD: Correct F15h IC aliasing issue

On 07/26/2011 08:38 PM, H. Peter Anvin wrote:
> On 07/26/2011 11:37 AM, Borislav Petkov wrote:
>>>
>>> I think the question was the width (and position) for the mask... i.e.
>>> your [14:12] above which *is* magic.
>>
>> Oh, that's easy: family 15h means bits [14:12] - those bits are used for
>> I$ index generation.
>>
>
> In other words, it's completely ad hoc.

There is no need to determine it by calculating, because it caused by 
the special design of the BD L1 cache and thus fixed.
And a calculation would be even more confusing:

The L1I is virtually indexed, but physically tagged.
64KB L1I cache, 64 Bytes per Cacheline = 1024 cache lines
1024 lines / 2 way associative = 512 indexes
64 Bytes per Cacheline (6 bits) + 512 indexes (9 bits) = bits [14:0]
virtual and physical addresses are the same for bits [11:0], which 
leaves the remaining 14:12 susceptible for aliasing.

So bit 12 comes from PAGESIZE and yes, the 14 could be derived from the 
CPUID cache info, but I don't see much value in breaking this down this way.
But I agree that there should be some comment in the patch which at 
least notes that bits [14:12] are due to the L1I design, maybe we can 
copy a nicer version of the above math in the commit message for reference.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--
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/