linux-kernel - Re: [PATCH 1/1] swiotlb: Fix swiotlb_bounce() to do partial sync's correctly

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: <Zgd_JaCHzOOLqWUM@atmark-techno.com>
Date: Sat, 30 Mar 2024 11:55:33 +0900
From: Dominique Martinet <dominique.martinet@...ark-techno.com>
To: Michael Kelley <mhklinux@...look.com>
Cc: "hch@....de" <hch@....de>,
	"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
	"robin.murphy@....com" <robin.murphy@....com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"bumyong.lee@...sung.com" <bumyong.lee@...sung.com>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"will@...nel.org" <will@...nel.org>,
	"petr@...arici.cz" <petr@...arici.cz>,
	"roberto.sassu@...weicloud.com" <roberto.sassu@...weicloud.com>,
	"lukas@...mn.com" <lukas@...mn.com>
Subject: Re: [PATCH 1/1] swiotlb: Fix swiotlb_bounce() to do partial sync's
 correctly

Michael Kelley wrote on Fri, Mar 29, 2024 at 03:18:16PM +0000:
> * tlb_offset = 1 - 3 = -2, as you describe above
> * orig_addr = 39 + -2 = 37.  The computation uses 39 from
> slot[1], not the 7 from slot[0].  This computed 37 is the
> correct orig_addr to use for the memcpy().

There are two things I don't understand here:
1/ Why orig_addr would come from slot[1] ?

We have index = (tlb_addr - mem->start) >> IO_TLB_SHIFT,
so index = (33 - 7) >> 5 = 26 >> 5 = 0

As such, orig_addr = mem->slots[0].orig_addr and we'd need the offset to
be 30, not -2 ?
Well, either work - if we fix index to point to the next slot in the
negative case that's also acceptable if we're sure it's valid, but I'm
worried it might not be in cases there was only one slot e.g. mapping
[7; 34] and calling with 33 size 2 would try to access slot 1 with a
negative offset in your example, but slot[0] is the last valid slot.

2/ Why is orig_addr 37 the correct address to use for memcpy, and not
33? I'd think it's off by a "minimum alignment page", for me this
computation only works if the dma_get_min_align size is bigger than io
tlb size.

> * size is still 4.  There's no computation in swiotlb_bounce()
> that changes "size".
> * alloc_size is pulled from slot[1], and is adjusted by tlb_offset.
> This adjusted alloc_size isn't used for anything except as a sanity
> check against "size".

Right, sorry - so size is ok (assuming slot[1] is used, I conflated the
two sizes.

I'm probably still missing something here, thanks for bearing with me.
-- 
Dominique