linux-kernel - Re: [RFC PATCH 0/7] Allow race-free block device handling

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:   Thu, 2 Feb 2023 11:50:37 -0500
From:   Mike Snitzer <snitzer@...nel.org>
To:     Demi Marie Obenour <demi@...isiblethingslab.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Roger Pau Monné <roger.pau@...rix.com>,
        Alasdair Kergon <agk@...hat.com>,
        Marek Marczykowski-Górecki 
        <marmarek@...isiblethingslab.com>, Juergen Gross <jgross@...e.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org, dm-devel@...hat.com
Subject: Re: [RFC PATCH 0/7] Allow race-free block device handling

On Wed, Jan 25 2023 at 10:33P -0500,
Demi Marie Obenour <demi@...isiblethingslab.com> wrote:

> This work aims to allow userspace to create and destroy block devices
> in a race-free and leak-free way,

"race-free and leak-free way" implies there both races and leaks in
existing code. You're making claims that are likely very specific to
your Xen use-case.  Please explain more carefully.

> and to allow them to be exposed to
> other Xen VMs via blkback without leaks or races.  It’s marked as RFC
> for a few reasons:
> 
> - The code has been only lightly tested.  It might be unstable or
>   insecure.
> 
> - The DM_DEV_CREATE ioctl gains a new flag.  Unknown flags were
>   previously ignored, so this could theoretically break buggy userspace
>   tools.

Not seeing a reason that type of DM change is needed. If you feel
strongly about it send a separate patch and we can discuss it.

> - I have no idea if I got the block device reference counting and
>   locking correct.

Your headers and justifcation for this line of work are really way too
terse. Please take the time to clearly make the case for your changes
in both the patch headers and code.

Mike