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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 27 Feb 2020 13:33:35 -0800
From:   "Darrick J. Wong" <>
Subject: [PATCH RFC 0/3] fs: online filesystem uuid operations

Hi all,

This patch series creates a couple of new ioctls to query and set the
filesystem uuid of mounted filesystems.  This is apparently desirous for
some cloud providers who wish to be able to deploy pre-baked rootfs
images to a machine, boot it, and have the client machine be able to
change the label and uuid to reflect that it's now derivative of the
original image.

For ext4 this is pretty easy to do as all the pieces are already in
place.  For XFS this is a little more difficult because we need to get
our house in order w.r.t. dependencies between the log uuid and
filesystem superblock uuid, which means that this is really new ext4
functionality that I'd like to share with the other filesystems.

I'm particularly curious to hear what people think about the
FORCE_INCOMPAT flag.  There are some circumstances (namely when the
entire fs metadata is keyed to a certain uuid) where we can only change
the uuid by turning on an incompat feature flag.  The currently running
kernel should be able to handle that just fine, but older kernels won't
be able to mount the fs after that.  We (XFS) normally don't do things
like that, which is why I require positive affirmation from userspace
that doing so is ok.

This is an extraordinary way to destroy everything.  Enjoy!
Comments and questions are, as always, welcome.


Powered by blists - more mailing lists