linux-kernel - Re: [PATCH 16/16] fs: switch ->s_uuid to uuid

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:   Wed, 10 May 2017 22:08:25 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Christoph Hellwig <hch@....de>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Shaohua Li <shli@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        David Howells <dhowells@...hat.com>,
        Steven Whitehouse <swhiteho@...hat.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        linux-raid@...r.kernel.org, linux-nvdimm@...ts.01.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 16/16] fs: switch ->s_uuid to uuid_t

On Wed, May 10, 2017 at 9:02 PM, Christoph Hellwig <hch@....de> wrote:
> For some file systems we still memcpy into it, but in various places this
> already allows us to use the proper uuid helpers.  More to come..
> Signed-off-by: Christoph Hellwig <hch@....de>
> ---

Series looks good!

My main concern is that filesystems with char uuid[16] are here to stay,
or maybe, will be converted slowly.

Considering this, perhaps we should have a helper/macro to copy from
char[16] to *uuid_t and maybe  BUILD_BUG_ON the size comparison?
#define bytes_to_uuid(dst, src) ...


> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index 682b336a7a6a..93a420160964 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -75,7 +75,7 @@ xfs_uuid_mount(
>
>         /* Publish UUID in struct super_block */
>         BUILD_BUG_ON(sizeof(mp->m_super->s_uuid) != sizeof(uuid_t));

This BUILD_BUG is no longer needed.

> -       memcpy(&mp->m_super->s_uuid, uuid, sizeof(uuid_t));
> +       uuid_copy(&mp->m_super->s_uuid, uuid);
>
>         if (mp->m_flags & XFS_MOUNT_NOUUID)
>                 return 0;
[...]

> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index d7f282d75cc1..1d32cd20009a 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -164,7 +164,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
>         hmac_misc.mode = inode->i_mode;
>         crypto_shash_update(desc, (const u8 *)&hmac_misc, sizeof(hmac_misc));
>         if (evm_hmac_attrs & EVM_ATTR_FSUUID)
> -               crypto_shash_update(desc, inode->i_sb->s_uuid,
> +               crypto_shash_update(desc, &inode->i_sb->s_uuid.b[0],

I wonder if 'inode->i_sb->s_uuid.b' would have been better here

Cheers,
Amir.