1 |
commit: 2ecd03ea8107b713b3340c42a51774c7e8559129 |
2 |
Author: Mike Pagano <mpagano <AT> gentoo <DOT> org> |
3 |
AuthorDate: Fri Apr 8 13:03:59 2022 +0000 |
4 |
Commit: Mike Pagano <mpagano <AT> gentoo <DOT> org> |
5 |
CommitDate: Fri Apr 8 13:03:59 2022 +0000 |
6 |
URL: https://gitweb.gentoo.org/proj/linux-patches.git/commit/?id=2ecd03ea |
7 |
|
8 |
Remove redundant patch |
9 |
|
10 |
Removed: |
11 |
2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch |
12 |
|
13 |
Signed-off-by: Mike Pagano <mpagano <AT> gentoo.org> |
14 |
|
15 |
0000_README | 4 - |
16 |
...rework-fix-info-leak-with-dma_from_device.patch | 187 --------------------- |
17 |
2 files changed, 191 deletions(-) |
18 |
|
19 |
diff --git a/0000_README b/0000_README |
20 |
index 2a86553a..2aa81fbc 100644 |
21 |
--- a/0000_README |
22 |
+++ b/0000_README |
23 |
@@ -135,10 +135,6 @@ Patch: 2400_mt76-mt7921e-fix-possible-probe-failure-after-reboot.patch |
24 |
From: https://patchwork.kernel.org/project/linux-wireless/patch/70e27cbc652cbdb78277b9c691a3a5ba02653afb.1641540175.git.objelf@×××××.com/ |
25 |
Desc: mt76: mt7921e: fix possible probe failure after reboot |
26 |
|
27 |
-Patch: 2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch |
28 |
-From: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git |
29 |
-Desc: Revert swiotlb: rework fix info leak with DMA_FROM_DEVICE |
30 |
- |
31 |
Patch: 2900_tmp513-Fix-build-issue-by-selecting-CONFIG_REG.patch |
32 |
From: https://bugs.gentoo.org/710790 |
33 |
Desc: tmp513 requies REGMAP_I2C to build. Select it by default in Kconfig. See bug #710790. Thanks to Phil Stracchino |
34 |
|
35 |
diff --git a/2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch b/2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch |
36 |
deleted file mode 100644 |
37 |
index 69476ab1..00000000 |
38 |
--- a/2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch |
39 |
+++ /dev/null |
40 |
@@ -1,187 +0,0 @@ |
41 |
-From bddac7c1e02ba47f0570e494c9289acea3062cc1 Mon Sep 17 00:00:00 2001 |
42 |
-From: Linus Torvalds <torvalds@××××××××××××××××.org> |
43 |
-Date: Sat, 26 Mar 2022 10:42:04 -0700 |
44 |
-Subject: Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" |
45 |
-MIME-Version: 1.0 |
46 |
-Content-Type: text/plain; charset=UTF-8 |
47 |
-Content-Transfer-Encoding: 8bit |
48 |
- |
49 |
-From: Linus Torvalds <torvalds@××××××××××××××××.org> |
50 |
- |
51 |
-commit bddac7c1e02ba47f0570e494c9289acea3062cc1 upstream. |
52 |
- |
53 |
-This reverts commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13. |
54 |
- |
55 |
-It turns out this breaks at least the ath9k wireless driver, and |
56 |
-possibly others. |
57 |
- |
58 |
-What the ath9k driver does on packet receive is to set up the DMA |
59 |
-transfer with: |
60 |
- |
61 |
- int ath_rx_init(..) |
62 |
- .. |
63 |
- bf->bf_buf_addr = dma_map_single(sc->dev, skb->data, |
64 |
- common->rx_bufsize, |
65 |
- DMA_FROM_DEVICE); |
66 |
- |
67 |
-and then the receive logic (through ath_rx_tasklet()) will fetch |
68 |
-incoming packets |
69 |
- |
70 |
- static bool ath_edma_get_buffers(..) |
71 |
- .. |
72 |
- dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr, |
73 |
- common->rx_bufsize, DMA_FROM_DEVICE); |
74 |
- |
75 |
- ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); |
76 |
- if (ret == -EINPROGRESS) { |
77 |
- /*let device gain the buffer again*/ |
78 |
- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, |
79 |
- common->rx_bufsize, DMA_FROM_DEVICE); |
80 |
- return false; |
81 |
- } |
82 |
- |
83 |
-and it's worth noting how that first DMA sync: |
84 |
- |
85 |
- dma_sync_single_for_cpu(..DMA_FROM_DEVICE); |
86 |
- |
87 |
-is there to make sure the CPU can read the DMA buffer (possibly by |
88 |
-copying it from the bounce buffer area, or by doing some cache flush). |
89 |
-The iommu correctly turns that into a "copy from bounce bufer" so that |
90 |
-the driver can look at the state of the packets. |
91 |
- |
92 |
-In the meantime, the device may continue to write to the DMA buffer, but |
93 |
-we at least have a snapshot of the state due to that first DMA sync. |
94 |
- |
95 |
-But that _second_ DMA sync: |
96 |
- |
97 |
- dma_sync_single_for_device(..DMA_FROM_DEVICE); |
98 |
- |
99 |
-is telling the DMA mapping that the CPU wasn't interested in the area |
100 |
-because the packet wasn't there. In the case of a DMA bounce buffer, |
101 |
-that is a no-op. |
102 |
- |
103 |
-Note how it's not a sync for the CPU (the "for_device()" part), and it's |
104 |
-not a sync for data written by the CPU (the "DMA_FROM_DEVICE" part). |
105 |
- |
106 |
-Or rather, it _should_ be a no-op. That's what commit aa6f8dcbab47 |
107 |
-broke: it made the code bounce the buffer unconditionally, and changed |
108 |
-the DMA_FROM_DEVICE to just unconditionally and illogically be |
109 |
-DMA_TO_DEVICE. |
110 |
- |
111 |
-[ Side note: purely within the confines of the swiotlb driver it wasn't |
112 |
- entirely illogical: The reason it did that odd DMA_FROM_DEVICE -> |
113 |
- DMA_TO_DEVICE conversion thing is because inside the swiotlb driver, |
114 |
- it uses just a swiotlb_bounce() helper that doesn't care about the |
115 |
- whole distinction of who the sync is for - only which direction to |
116 |
- bounce. |
117 |
- |
118 |
- So it took the "sync for device" to mean that the CPU must have been |
119 |
- the one writing, and thought it meant DMA_TO_DEVICE. ] |
120 |
- |
121 |
-Also note how the commentary in that commit was wrong, probably due to |
122 |
-that whole confusion, claiming that the commit makes the swiotlb code |
123 |
- |
124 |
- "bounce unconditionally (that is, also |
125 |
- when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale |
126 |
- data from the swiotlb buffer" |
127 |
- |
128 |
-which is nonsensical for two reasons: |
129 |
- |
130 |
- - that "also when dir == DMA_TO_DEVICE" is nonsensical, as that was |
131 |
- exactly when it always did - and should do - the bounce. |
132 |
- |
133 |
- - since this is a sync for the device (not for the CPU), we're clearly |
134 |
- fundamentally not coping back stale data from the bounce buffers at |
135 |
- all, because we'd be copying *to* the bounce buffers. |
136 |
- |
137 |
-So that commit was just very confused. It confused the direction of the |
138 |
-synchronization (to the device, not the cpu) with the direction of the |
139 |
-DMA (from the device). |
140 |
- |
141 |
-Reported-and-bisected-by: Oleksandr Natalenko <oleksandr@×××××××××.name> |
142 |
-Reported-by: Olha Cherevyk <olha.cherevyk@×××××.com> |
143 |
-Cc: Halil Pasic <pasic@×××××××××.com> |
144 |
-Cc: Christoph Hellwig <hch@×××.de> |
145 |
-Cc: Kalle Valo <kvalo@××××××.org> |
146 |
-Cc: Robin Murphy <robin.murphy@×××.com> |
147 |
-Cc: Toke Høiland-Jørgensen <toke@××××.dk> |
148 |
-Cc: Maxime Bizon <mbizon@×××××××.fr> |
149 |
-Cc: Johannes Berg <johannes@××××××××××××.net> |
150 |
-Signed-off-by: Linus Torvalds <torvalds@××××××××××××××××.org> |
151 |
-Signed-off-by: Greg Kroah-Hartman <gregkh@×××××××××××××××.org> |
152 |
---- |
153 |
- Documentation/core-api/dma-attributes.rst | 8 ++++++++ |
154 |
- include/linux/dma-mapping.h | 8 ++++++++ |
155 |
- kernel/dma/swiotlb.c | 23 ++++++++--------------- |
156 |
- 3 files changed, 24 insertions(+), 15 deletions(-) |
157 |
- |
158 |
---- a/Documentation/core-api/dma-attributes.rst |
159 |
-+++ b/Documentation/core-api/dma-attributes.rst |
160 |
-@@ -130,3 +130,11 @@ accesses to DMA buffers in both privileg |
161 |
- subsystem that the buffer is fully accessible at the elevated privilege |
162 |
- level (and ideally inaccessible or at least read-only at the |
163 |
- lesser-privileged levels). |
164 |
-+ |
165 |
-+DMA_ATTR_OVERWRITE |
166 |
-+------------------ |
167 |
-+ |
168 |
-+This is a hint to the DMA-mapping subsystem that the device is expected to |
169 |
-+overwrite the entire mapped size, thus the caller does not require any of the |
170 |
-+previous buffer contents to be preserved. This allows bounce-buffering |
171 |
-+implementations to optimise DMA_FROM_DEVICE transfers. |
172 |
---- a/include/linux/dma-mapping.h |
173 |
-+++ b/include/linux/dma-mapping.h |
174 |
-@@ -62,6 +62,14 @@ |
175 |
- #define DMA_ATTR_PRIVILEGED (1UL << 9) |
176 |
- |
177 |
- /* |
178 |
-+ * This is a hint to the DMA-mapping subsystem that the device is expected |
179 |
-+ * to overwrite the entire mapped size, thus the caller does not require any |
180 |
-+ * of the previous buffer contents to be preserved. This allows |
181 |
-+ * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers. |
182 |
-+ */ |
183 |
-+#define DMA_ATTR_OVERWRITE (1UL << 10) |
184 |
-+ |
185 |
-+/* |
186 |
- * A dma_addr_t can hold any valid DMA or bus address for the platform. It can |
187 |
- * be given to a device to use as a DMA source or target. It is specific to a |
188 |
- * given device and there may be a translation between the CPU physical address |
189 |
---- a/kernel/dma/swiotlb.c |
190 |
-+++ b/kernel/dma/swiotlb.c |
191 |
-@@ -627,14 +627,10 @@ phys_addr_t swiotlb_tbl_map_single(struc |
192 |
- for (i = 0; i < nr_slots(alloc_size + offset); i++) |
193 |
- mem->slots[index + i].orig_addr = slot_addr(orig_addr, i); |
194 |
- tlb_addr = slot_addr(mem->start, index) + offset; |
195 |
-- /* |
196 |
-- * When dir == DMA_FROM_DEVICE we could omit the copy from the orig |
197 |
-- * to the tlb buffer, if we knew for sure the device will |
198 |
-- * overwirte the entire current content. But we don't. Thus |
199 |
-- * unconditional bounce may prevent leaking swiotlb content (i.e. |
200 |
-- * kernel memory) to user-space. |
201 |
-- */ |
202 |
-- swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_TO_DEVICE); |
203 |
-+ if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && |
204 |
-+ (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE || |
205 |
-+ dir == DMA_BIDIRECTIONAL)) |
206 |
-+ swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_TO_DEVICE); |
207 |
- return tlb_addr; |
208 |
- } |
209 |
- |
210 |
-@@ -701,13 +697,10 @@ void swiotlb_tbl_unmap_single(struct dev |
211 |
- void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr, |
212 |
- size_t size, enum dma_data_direction dir) |
213 |
- { |
214 |
-- /* |
215 |
-- * Unconditional bounce is necessary to avoid corruption on |
216 |
-- * sync_*_for_cpu or dma_ummap_* when the device didn't overwrite |
217 |
-- * the whole lengt of the bounce buffer. |
218 |
-- */ |
219 |
-- swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE); |
220 |
-- BUG_ON(!valid_dma_direction(dir)); |
221 |
-+ if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL) |
222 |
-+ swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE); |
223 |
-+ else |
224 |
-+ BUG_ON(dir != DMA_FROM_DEVICE); |
225 |
- } |
226 |
- |
227 |
- void swiotlb_sync_single_for_cpu(struct device *dev, phys_addr_t tlb_addr, |