linux-kernel - Re: [PATCH v1 4/4] swiotlb: panic if nslabs is too small

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]

Date:   Mon, 22 Aug 2022 04:26:47 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Yu Zhao <yuzhao@...gle.com>, dongli.zhang@...cle.com,
        ak@...ux.intel.com, akpm@...ux-foundation.org,
        alexander.sverdlin@...ia.com, andi.kleen@...el.com, bp@...en8.de,
        bp@...e.de, cminyard@...sta.com, corbet@....net,
        damien.lemoal@...nsource.wdc.com, dave.hansen@...ux.intel.com,
        hch@...radead.org, iommu@...ts.linux-foundation.org,
        joe.jin@...cle.com, joe@...ches.com, keescook@...omium.org,
        kirill.shutemov@...el.com, kys@...rosoft.com,
        linux-doc@...r.kernel.org, linux-hyperv@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
        ltykernel@...il.com, michael.h.kelley@...rosoft.com,
        mingo@...hat.com, m.szyprowski@...sung.com, parri.andrea@...il.com,
        paulmck@...nel.org, pmladek@...e.com, rdunlap@...radead.org,
        tglx@...utronix.de, thomas.lendacky@....com,
        Tianyu.Lan@...rosoft.com, tsbogend@...ha.franken.de,
        vkuznets@...hat.com, wei.liu@...nel.org, x86@...nel.org
Subject: Re: [PATCH v1 4/4] swiotlb: panic if nslabs is too small

On Mon, Aug 22, 2022 at 10:49:09AM +0100, Robin Murphy wrote:
> Hmm, it's possible this might be quietly fixed by 20347fca71a3, but either
> way I'm not sure why we would need to panic *before* we've even tried to
> allocate anything, when we could simply return with no harm done? If we've
> ended up calculating (or being told) a buffer size which is too small to be
> usable, that should be no different to disabling SWIOTLB entirely.

Hmm.  I think this might be a philosophical question, but I think
failing the boot with a clear error report for a configuration that is
supposed to work but can't is way better than just panicing later on.

> Historically, passing "swiotlb=1" on the command line has been used to save
> memory when the user knows SWIOTLB isn't needed. That should definitely not
> be allowed to start panicking.

I've never seen swiotlb=1 advertized as a way to disable swiotlb.
That's always been swiotlb=noforce, which cleanly disables it.