Content-Type: text/plain;
        charset=us-ascii
MIME-Version: 1.0
Subject: Re: [PATCH V2] arm64/mm: Intercept pfn changes in set_pte_at()
From:   Muchun Song <muchun.song@linux.dev>
In-Reply-To: <Y+PbfGow2q0Oud3M@FVFF77S0Q05N.cambridge.arm.com>
Date:   Fri, 10 Feb 2023 14:50:09 +0800
Cc:     Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Robin Murphy <robin.murphy@arm.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        linux-arm-kernel@lists.infradead.org,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B3E64D8-81AD-4DD2-87D8-B8B2AFA97B5A@linux.dev>
References: <d454c9a2-5300-b600-a2ae-21d82d338470@arm.com>
 <20230131154950.GB2646@willie-the-truck> <Y9pZALdn3pKiJUeQ@arm.com>
 <A8DF7D56-C145-4B49-A034-022917B87C89@linux.dev> <Y9uUO9AadE+8ik/0@arm.com>
 <F10F1618-7153-41C7-A475-522D833C41D4@linux.dev>
 <20230203101023.GA5597@willie-the-truck>
 <93461768-791A-45BE-BEF2-344CC5228C92@linux.dev>
 <20230207143131.GA12475@willie-the-truck>
 <FB3AE2F1-2EF8-4960-884E-DABA7E64CE59@linux.dev>
 <Y+PbfGow2q0Oud3M@FVFF77S0Q05N.cambridge.arm.com>
To:     Mark Rutland <mark.rutland@arm.com>
Precedence: bulk


> On Feb 9, 2023, at 01:27, Mark Rutland <mark.rutland@arm.com> wrote:
>=20
> On Wed, Feb 08, 2023 at 11:13:46AM +0800, Muchun Song wrote:
>>> On Feb 7, 2023, at 22:31, Will Deacon <will@kernel.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?
>>>=20
>>> 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.
>>=20
>> You mean the output address of amalgamated TLB entry is neither the =
old
>> address (before updated) nor the new address (after updated)?
>=20
> Yes, that is one possible result.
>=20
>> So it is a bogus physical address?
>=20
> Yes, that is one possible result.
>=20
>> Is there any specifications to describe the rules of how to create a
>> amalgamated TLB entry? Thanks.
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> It's not clear to me whether that could also affect hits for unrelated =
VAs.
>=20
> 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.

>=20
> Thanks,
> Mark.