[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9d289b97-570d-49af-aa6e-acc98df41015@linux.intel.com>
Date: Tue, 15 Jul 2025 09:19:07 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Mike Rapoport <rppt@...nel.org>, Uladzislau Rezki <urezki@...il.com>
Cc: David Laight <david.laight.linux@...il.com>,
Dave Hansen <dave.hansen@...el.com>, jacob.pan@...ux.microsoft.com,
Jason Gunthorpe <jgg@...dia.com>, Joerg Roedel <joro@...tes.org>,
Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Kevin Tian <kevin.tian@...el.com>, Jann Horn <jannh@...gle.com>,
Vasant Hegde <vasant.hegde@....com>, Alistair Popple <apopple@...dia.com>,
Peter Zijlstra <peterz@...radead.org>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
Andy Lutomirski <luto@...nel.org>, iommu@...ts.linux.dev,
security@...nel.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush
On 7/14/25 22:50, Mike Rapoport wrote:
> On Mon, Jul 14, 2025 at 03:19:17PM +0200, Uladzislau Rezki wrote:
>> On Mon, Jul 14, 2025 at 01:39:20PM +0100, David Laight wrote:
>>> On Wed, 9 Jul 2025 11:22:34 -0700
>>> Dave Hansen<dave.hansen@...el.com> wrote:
>>>
>>>> On 7/9/25 11:15, Jacob Pan wrote:
>>>>>>> Is there a use case where a SVA user can access kernel memory in the
>>>>>>> first place?
>>>>>> No. It should be fully blocked.
>>>>>>
>>>>> Then I don't understand what is the "vulnerability condition" being
>>>>> addressed here. We are talking about KVA range here.
>>>> SVA users can't access kernel memory, but they can compel walks of
>>>> kernel page tables, which the IOMMU caches. The trouble starts if the
>>>> kernel happens to free that page table page and the IOMMU is using the
>>>> cache after the page is freed.
>>>>
>>>> That was covered in the changelog, but I guess it could be made a bit
>>>> more succinct.
> But does this really mean that every flush_tlb_kernel_range() should flush
> the IOMMU page tables as well? AFAIU, set_memory flushes TLB even when bits
> in pte change and it seems like an overkill...
As far as I can see, only the next-level page table pointer in the
middle-level entry matters. SVA is not allowed to access kernel
addresses, which has been ensured by the U/S bit in the leaf PTEs, so
other bit changes don't matter here.
Thanks,
baolu
Powered by blists - more mailing lists