linux-hardening - Re: [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption

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: <CAOZ5it1v3zxiavxctm-d32bT9aO701Os1-EnEeG0KCUhBPLMnw@mail.gmail.com>
Date: Wed, 20 Nov 2024 14:58:54 -0700
From: Brian Johannesmeyer <bjohannesmeyer@...il.com>
To: Keith Busch <kbusch@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, 
	Raphael Isemann <teemperor@...il.com>, Cristiano Giuffrida <giuffrida@...vu.nl>, Herbert Bos <h.j.bos@...nl>, 
	Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption

> You should probably Cc Keith as the person who most recently did major
> work on the dmpool code and might still remember how it works.

Thank you for adding him, and apologies for not including him initially.

> The intrusive list was overlayed in the freed blocks for spatial
> optimizations. If you're moving these field outside of it (I'll have to
> review the patch on lore), you can probably relax the minimum dma block
> size too since we don't need to hold the data structure information in
> it.

I see. AFAICT, relaxing the minimum DMA block size would just mean
removing these lines from `dma_pool_create()`:
```
    if (size < sizeof(struct dma_block))
        size = sizeof(struct dma_block);
```

> Could you rerun your tests without DMAPOOL_DEBUG enabled? That's the
> more interesting kernel setup for performance comparisions.

Sure, that makes sense. Here are the results with DMAPOOL_DEBUG disabled:

**Without the patches applied:**
```
dmapool test: size:16   align:16   blocks:8192 time:11860
dmapool test: size:64   align:64   blocks:8192 time:11951
dmapool test: size:256  align:256  blocks:8192 time:12287
dmapool test: size:1024 align:1024 blocks:2048 time:3134
dmapool test: size:4096 align:4096 blocks:1024 time:1686
dmapool test: size:68   align:32   blocks:8192 time:12050
```

**With the patches applied:**
```
dmapool test: size:16   align:16   blocks:8192 time:34432
dmapool test: size:64   align:64   blocks:8192 time:62262
dmapool test: size:256  align:256  blocks:8192 time:238137
dmapool test: size:1024 align:1024 blocks:2048 time:61386
dmapool test: size:4096 align:4096 blocks:1024 time:75342
dmapool test: size:68   align:32   blocks:8192 time:88243
```

These results are consistent across multiple runs. It seems that with
DMAPOOL_DEBUG disabled, the patches introduce a significant
performance hit. Let me know if you have any suggestions or further
tests you'd like me to run.

Thanks,

Brian Johannesmeyer