linux-kernel - Re: [PATCH v4 2/5] block: keyslot-manager: Introduce functions for device mapper support

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: <YCQ6OBExblohlnfO@gmail.com>
Date:   Wed, 10 Feb 2021 11:55:36 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Satya Tangirala <satyat@...gle.com>
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        dm-devel@...hat.com, Jens Axboe <axboe@...nel.dk>,
        Mike Snitzer <snitzer@...hat.com>,
        Alasdair Kergon <agk@...hat.com>
Subject: Re: [PATCH v4 2/5] block: keyslot-manager: Introduce functions for
 device mapper support

On Mon, Feb 01, 2021 at 05:10:16AM +0000, Satya Tangirala wrote:
> Introduce blk_ksm_update_capabilities() to update the capabilities of
> a keyslot manager (ksm) in-place. The pointer to a ksm in a device's
> request queue may not be easily replaced, because upper layers like
> the filesystem might access it (e.g. for programming keys/checking
> capabilities) at the same time the device wants to replace that
> request queue's ksm (and free the old ksm's memory). This function
> allows the device to update the capabilities of the ksm in its request
> queue directly. Devices can safely update the ksm this way without any
> synchronization with upper layers *only* if the updated (new) ksm
> continues to support all the crypto capabilities that the old ksm did
> (see description below for blk_ksm_is_superset() for why this is so).
> 
> Also introduce blk_ksm_is_superset() which checks whether one ksm's
> capabilities are a (not necessarily strict) superset of another ksm's.
> The blk-crypto framework requires that crypto capabilities that were
> advertised when a bio was created continue to be supported by the
> device until that bio is ended - in practice this probably means that
> a device's advertised crypto capabilities can *never* "shrink" (since
> there's no synchronization between bio creation and when a device may
> want to change its advertised capabilities) - so a previously
> advertised crypto capability must always continue to be supported.
> This function can be used to check that a new ksm is a valid
> replacement for an old ksm.
> 
> Signed-off-by: Satya Tangirala <satyat@...gle.com>

Looks good, you can add:

Reviewed-by: Eric Biggers <ebiggers@...gle.com>