linux-kernel - Re: [PATCH V2] arm64/mm: Intercept pfn changes in set_pte

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]

Message-Id: <2B3E64D8-81AD-4DD2-87D8-B8B2AFA97B5A@linux.dev>
Date:   Fri, 10 Feb 2023 14:50:09 +0800
From:   Muchun Song <muchun.song@...ux.dev>
To:     Mark Rutland <mark.rutland@....com>
Cc:     Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Robin Murphy <robin.murphy@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH V2] arm64/mm: Intercept pfn changes in set_pte_at()



> On Feb 9, 2023, at 01:27, Mark Rutland <mark.rutland@....com> wrote:
> 
> On Wed, Feb 08, 2023 at 11:13:46AM +0800, Muchun Song wrote:
>>> On Feb 7, 2023, at 22:31, Will Deacon <will@...nel.org> wrote:
>>> On Mon, Feb 06, 2023 at 11:28:12AM +0800, Muchun Song wrote:
>>>> I am not familiar with ARM64, what's the user-visible effect if this
>>>> "amalgamation" occurs?
>>> 
>>> The user-visible effects would probably be data corruption and instability,
>>> since the amalgamated TLB entry could result in a bogus physical address and
>>> bogus permissions.
>> 
>> You mean the output address of amalgamated TLB entry is neither the old
>> address (before updated) nor the new address (after updated)?
> 
> Yes, that is one possible result.
> 
>> So it is a bogus physical address?
> 
> Yes, that is one possible result.
> 
>> Is there any specifications to describe the rules of how to create a
>> amalgamated TLB entry? Thanks.
> 
> Unfortunately, this is not clearly specified in the ARM ARM, and we have to
> take a pessimistic reading here. We assume that amalgamation is some arbitrary
> function of the TLB entries which are hit (e.g. they might be OR'd together).
> This is something that I'd like to have clarified further by Arm's architects.
> 
> The important thing to note is that amalgamation applies to *TLB entries*, not
> the translation table entries that they were derived from. Since the TLB format
> is micro-architecture dependent, and since the manner in which they might be
> combined is arbitrary, the results of combining could be arbitrary (and
> consequently, this is difficult to specify).
> 
> The architecture *does* provide a few restrictions (e.g. Stage-1 entries within
> a VM can't escape Stage-2, NS entries can't create a secure physical address),
> but beyond that we cannot make any assumptions.
> 
> So e.g. if you have 2 read-only entries for addresses A and B, amalgamation
> could result in read-write-execute for a distinct address C.
> 
> It's not clear to me whether that could also affect hits for unrelated VAs.
> 
> So the short answer is that we have to treat this as CONSTRAINED UNPREDICTABLE,
> and must avoid potential amalgamation by using Break-Before-Make.

Thanks for your clear description. It's really helpful.

> 
> Thanks,
> Mark.