linux-kernel - Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO

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: <859c2adc-d3cb-64e8-faba-06e1ac5eddaf@gmail.com>
Date:   Wed, 29 Jun 2022 12:01:24 +1200
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Bart Van Assche <bvanassche@....org>,
        Arnd Bergmann <arnd@...nel.org>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        scsi <linux-scsi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Jakub Kicinski <kuba@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>,
        Linux IOMMU <iommu@...ts.linux-foundation.org>,
        Khalid Aziz <khalid@...ehiking.org>,
        "Maciej W . Rozycki" <macro@...am.me.uk>,
        Matt Wang <wwentao@...are.com>,
        Miquel van Smoorenburg <mikevs@...all.net>,
        Mark Salyzyn <salyzyn@...roid.com>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        alpha <linux-alpha@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        Denis Efremov <efremov@...ux.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Subject: Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

Hi Bart,

On 29/06/22 11:50, Bart Van Assche wrote:
> On 6/28/22 16:09, Michael Schmitz wrote:
>> On 29/06/22 09:50, Arnd Bergmann wrote:
>>> On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz 
>>> <schmitzmic@...il.com> wrote:
>>>> On 28/06/22 19:03, Geert Uytterhoeven wrote:
>>>>>> The driver allocates bounce buffers using kmalloc if it hits an
>>>>>> unaligned data buffer - can such buffers still even happen these 
>>>>>> days?
>>>>> No idea.
>>>> Hmmm - I think I'll stick a WARN_ONCE() in there so we know whether 
>>>> this
>>>> code path is still being used.
>>> kmalloc() guarantees alignment to the next power-of-two size or
>>> KMALLOC_MIN_ALIGN, whichever is bigger. On m68k this means it
>>> is cacheline aligned.
>>
>> And all SCSI buffers are allocated using kmalloc? No way at all for 
>> user space to pass unaligned data?
>>
>> (SCSI is a weird beast - I have used a SCSI DAT tape driver many many 
>> years ago, which broke all sorts of assumptions about transfer block 
>> sizes ... but that might actually have been in the v0.99 days, many 
>> rewrites of SCSI midlevel ago).
>>
>> Just being cautious, as getting any of this tested will be a stretch.
>
> An example of a user space application that passes an SG I/O data 
> buffer to the kernel that is aligned to a four byte boundary but not 
> to an eight byte boundary if the -s (scattered) command line option is 
> used: 
> https://github.com/osandov/blktests/blob/master/src/discontiguous-io.cpp

Thanks - four byte alignment actually wouldn't be an issue for me. It's 
two byte or smaller that would trip up the SCSI DMA.

While I'm sure such an even more pathological test case could be 
written, I was rather worried about st.c and sr.c input ...

Cheers,

     Michael

>
> Bart.