Messages in this thread | | | Subject | Re: [PATCH V2] arm64/mm: Intercept pfn changes in set_pte_at() | From | Muchun Song <> | Date | Fri, 10 Feb 2023 14:50:09 +0800 |
| |
> On Feb 9, 2023, at 01:27, Mark Rutland <mark.rutland@arm.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@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? >>> >>> 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.
| |