xfs: include the XFS magic number in magic.h
PATCH 1/1 xfs: include the XFS magic number in magic.h
Move the XFS_SB_MAGIC definition to magic.h.
--- fs/xfs/libxfs/xfs_format.h | 3 ++- include/uapi/linux/magic.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)
fs/xfs/libxfs/xfs_format.h +2 -1
@@ -18,6 +18,8 @@#ifndef __XFS_FORMAT_H__#define __XFS_FORMAT_H__ +#include <linux/magic.h> +/* * XFS On Disk Format Definitions *
@@ -38,7 +40,6 @@ struct xfs_ifork;* Fits into a sector-sized buffer at address 0 of each allocation group. * Only the first of these is ever updated except during growfs. */ -#define XFS_SB_MAGIC 0x58465342/* 'XFSB' */ #define XFS_SB_VERSION_1 1/* 5.3, 6.0.1, 6.1 */ #define XFS_SB_VERSION_2 2/* 6.2 - attributes */ #define XFS_SB_VERSION_3 3/* 6.2 - new inode version */
include/uapi/linux/magic.h +1 -0
@@ -67,6 +67,7 @@#define TRACEFS_MAGIC 0x74726163#define V9FS_MAGIC 0x01021997 +#define XFS_SB_MAGIC 0x58465342#define BDEVFS_MAGIC 0x62646576#define DAXFS_MAGIC 0x64646178
Signature · 1 line
2.7.4
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.
NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in magic.h. Please reconsider...
Mimi
Quoted 9 lines · Mimi Zohar
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in
magic.h. Please reconsider...
That is completely bogus, and it should not be supported in any way. File systems magic numbers are internal implementation details.
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Mimi Zohar
Quoted 3 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in
magic.h. Please reconsider...That is completely bogus, and it should not be supported in any way. File systems magic numbers are internal implementation details.
Perhaps policies in general shouldn't differentiate between file systems, but it definitely simplifies testing.
For example, currently IMA-appraisal only supports storing file signatures as xattrs, but support for appended signatures is being added. Per file system rules could require different types of file signatures.
Mimi
Quoted 9 lines · Mimi Zohar
Quoted 8 lines · Christoph Hellwig
Quoted 7 lines · Mimi Zohar
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in
magic.h. Please reconsider...That is completely bogus, and it should not be supported in any way. File systems magic numbers are internal implementation details.
Perhaps policies in general shouldn't differentiate between file systems, but it definitely simplifies testing.
How does specifying a filesystem type in a generic layer's policy implementation help testing?
Quoted 4 lines
For example, currently IMA-appraisal only supports storing file signatures as xattrs, but support for appended signatures is being added. Per file system rules could require different types of file signatures.
What's an "appended signature", and why is the filesystem independent xattr interface insufficient for storing this information?
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 13 lines · Dave Chinner
Quoted 12 lines · Mimi Zohar
Quoted 11 lines · Christoph Hellwig
Quoted 9 lines · Mimi Zohar
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in
magic.h. Please reconsider...
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
That is completely bogus, and it should not be supported in any way. File systems magic numbers are internal implementation details.
Perhaps policies in general shouldn't differentiate between file systems, but it definitely simplifies testing.
How does specifying a filesystem type in a generic layer's policy implementation help testing?
Based on file system, I could differentiate which files need to be signed. For example, the root file system might require files signatures only on executables, while for other file systems all files could require signatures.
Quoted 8 lines
Quoted 4 lines
For example, currently IMA-appraisal only supports storing file signatures as xattrs, but support for appended signatures is being added. Per file system rules could require different types of file signatures.
What's an "appended signature", and why is the filesystem independent xattr interface insufficient for storing this information?
Unfortunately, not all filesystems support xattrs (eg. cpio/initramfs). In some cases, like kexec kernel image and initramfs, having an attached signatures simplifies network boot. scripts/sign-file is used to append a file signature to kernel modules. This same script could be used for signing other files, like the kexec kernel image and initramfs.
Mimi
Quoted 20 lines · Mimi Zohar
Quoted 19 lines · Dave Chinner
Quoted 17 lines · Mimi Zohar
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Mimi Zohar
Quoted 3 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in
magic.h. Please reconsider...That is completely bogus, and it should not be supported in any way. File systems magic numbers are internal implementation details.
Perhaps policies in general shouldn't differentiate between file systems, but it definitely simplifies testing.
Quoted 7 lines
Quoted 2 lines
How does specifying a filesystem type in a generic layer's policy implementation help testing?
Based on file system, I could differentiate which files need to be signed. For example, the root file system might require files signatures only on executables, while for other file systems all files could require signatures.
What's the filesystem magic number got to do with where the filesystem is mounted or what it contains?
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
For example, currently IMA-appraisal only supports storing file signatures as xattrs, but support for appended signatures is being added. Per file system rules could require different types of file signatures.
What's an "appended signature", and why is the filesystem independent xattr interface insufficient for storing this information?
Unfortunately, not all filesystems support xattrs (eg. cpio/initramfs).
So add support to them....
Quoted 2 lines
In some cases, like kexec kernel image and
initramfs, having an attached signatures simplifies network boot.
... or support fetching detached signatures for these very specific use cases.
Quoted 3 lines
scripts/sign-fileis used to append a file signature to kernel modules. This same script could be used for signing other files, like the kexec kernel image and initramfs.
This doesn't require knowing about what type of filesystem the file is read from. It's just data appended to the file, and you can already read filesystem without knowing what the underlying filesystem implementation is....
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 37 lines · Dave Chinner
Quoted 20 lines · Mimi Zohar
Quoted 19 lines · Dave Chinner
Quoted 17 lines · Mimi Zohar
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Mimi Zohar
Quoted 3 lines · Christoph Hellwig
Quoted 1 line · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
NACK. We want to keep the XFS code self-contained and no other part of the kernel has any business knowing it anyway.
IMA policy rules can be defined in terms of magic numbers, but they need to be defined in
magic.h. Please reconsider...That is completely bogus, and it should not be supported in any way. File systems magic numbers are internal implementation details.
Perhaps policies in general shouldn't differentiate between file systems, but it definitely simplifies testing.
Quoted 7 lines
Quoted 2 lines
How does specifying a filesystem type in a generic layer's policy implementation help testing?
Based on file system, I could differentiate which files need to be signed. For example, the root file system might require files signatures only on executables, while for other file systems all files could require signatures.
What's the filesystem magic number got to do with where the filesystem is mounted or what it contains?
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
For example, currently IMA-appraisal only supports storing file signatures as xattrs, but support for appended signatures is being added. Per file system rules could require different types of file signatures.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
What's an "appended signature", and why is the filesystem independent xattr interface insufficient for storing this information?
Unfortunately, not all filesystems support xattrs (eg. cpio/initramfs).
So add support to them....
Definitely, that would be the best solution! Anyone have time and is interested in adding xattr support to CPIO?
Quoted 5 lines
Quoted 2 lines
In some cases, like kexec kernel image and
initramfs, having an attached signatures simplifies network boot.... or support fetching detached signatures for these very specific use cases.
That would require changes to the protocol (eg. PXE).
Quoted 8 lines
Quoted 3 lines
scripts/sign-fileis used to append a file signature to kernel modules. This same script could be used for signing other files, like the kexec kernel image and initramfs.This doesn't require knowing about what type of filesystem the file is read from. It's just data appended to the file, and you can already read filesystem without knowing what the underlying filesystem implementation is....
Agreed, this is in response to your question "What's an appended signature". The context was defining policy rules for testing, which either require different types of files signatures or require signatures for different file types, on a per file system basis.
Sigh, this patch was not suppose to be controversial. Most, if not all, of the other file systems are included in magic.h.
Mimi
Quoted 9 lines · Mimi Zohar
Quoted 8 lines · Dave Chinner
Quoted 4 lines · Mimi Zohar
Based on file system, I could differentiate which files need to be signed. For example, the root file system might require files signatures only on executables, while for other file systems all files could require signatures.
What's the filesystem magic number got to do with where the filesystem is mounted or what it contains?
<silence>
[....]
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Unfortunately, not all filesystems support xattrs (eg. cpio/initramfs).
So add support to them....
Definitely, that would be the best solution! Anyone have time and is interested in adding xattr support to CPIO?
One who needs the functionality finds the resources....
Quoted 11 lines
Quoted 8 lines
Quoted 3 lines
scripts/sign-fileis used to append a file signature to kernel modules. This same script could be used for signing other files, like the kexec kernel image and initramfs.This doesn't require knowing about what type of filesystem the file is read from. It's just data appended to the file, and you can already read filesystem without knowing what the underlying filesystem implementation is....
Agreed, this is in response to your question "What's an appended signature".
Sure, but ...
Quoted 3 lines
The context was defining policy rules for testing, which either require different types of files signatures or require signatures for different file types, on a per file system basis.
... you still haven't explained why you need the filesystem magic number for this or even why you need to have different methods/policies for different filesystem types.
Quoted 1 line
Sigh, this patch was not suppose to be controversial.
It's not controversial, it's just wrong. :)
There are around 40 defined magic numbers in the XFS on-disk format. They all get defined in the XFS on-disk format headers and should not be used outside the XFS code.
Quoted 2 lines
Most, if not
all, of the other file systems are included inmagic.h.
And your point is? Seriously, using filesystem magic numbers in the kernel for detecting filesystems is misguided because:
a) they don't uniquely identify a filesystem, and
b) superblocks already have a struct file_system_type (sb->s_type) attached to them that is used explicity for identifying the filesystem type *by name*.
IOWs, if you need to identify a filesystem *type*, using internal magic numbers is not the way to do it. selinux, for example, checks sb->s_type->name quite a lot....
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 3 lines · Dave Chinner
IOWs, if you need to identify a filesystem *type*, using internal magic numbers is not the way to do it. selinux, for example, checks
sb->s_type->namequite a lot....
And that is bad enough to start with. It should check for specific features, and not the file system driver name.
Quoted 3 lines · Dave Chinner
IOWs, if you need to identify a filesystem *type*, using internal magic numbers is not the way to do it. selinux, for example, checks
sb->s_type->namequite a lot....
Thanks, this works fine. Is there a defined max name length?
Mimi
Dave Chinner
NAKQuoted 22 lines · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.Signed-off-by Mimi Zohar <[email protected]>--- fs/xfs/libxfs/xfs_format.h | 3 ++- include/uapi/linux/magic.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)fs/xfs/libxfs/xfs_format.h +2
-0@@ -18,6 +18,8 @@#ifndef __XFS_FORMAT_H__#define __XFS_FORMAT_H__ +#include <linux/magic.h> +/* * XFS On Disk Format Definitions *
fs/xfs/libxfs/xfs_format.h struct xfs_ifork; · line 45
Quoted 7 lines
fs/xfs/libxfs/xfs_format.h +0
-1@@ -38,7 +40,6 @@ struct xfs_ifork;* Fits into a sector-sized buffer at address 0 of each allocation group. * Only the first of these is ever updated except during growfs. */ -#define XFS_SB_MAGIC 0x58465342/* 'XFSB' */ #define XFS_SB_VERSION_1 1/* 5.3, 6.0.1, 6.1 */ #define XFS_SB_VERSION_2 2/* 6.2 - attributes */ #define XFS_SB_VERSION_3 3/* 6.2 - new inode version */
NAK.
The XFS superblock magic number is part of the on-disk format definition of XFS. It belongs with all the other on-disk format definitions in this file.
Besides, there is almost never a good reason to be doing stuff based on filesystem magic numbers. What, exactly, do you need to know filesystem magic numbers for in the kernel?
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Hi Dave,
Quoted 33 lines · Dave Chinner
Quoted 22 lines · Mimi Zohar
Move the
XFS_SB_MAGICdefinition tomagic.h.Signed-off-by Mimi Zohar <[email protected]>--- fs/xfs/libxfs/xfs_format.h | 3 ++- include/uapi/linux/magic.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)fs/xfs/libxfs/xfs_format.h +2
-0@@ -18,6 +18,8 @@#ifndef __XFS_FORMAT_H__#define __XFS_FORMAT_H__ +#include <linux/magic.h> +/* * XFS On Disk Format Definitions * fs/xfs/libxfs/xfs_format.h struct xfs_ifork; · line 45
Quoted 7 lines
fs/xfs/libxfs/xfs_format.h +0
-1@@ -38,7 +40,6 @@ struct xfs_ifork;* Fits into a sector-sized buffer at address 0 of each allocation group. * Only the first of these is ever updated except during growfs. */ -#define XFS_SB_MAGIC 0x58465342/* 'XFSB' */ #define XFS_SB_VERSION_1 1/* 5.3, 6.0.1, 6.1 */ #define XFS_SB_VERSION_2 2/* 6.2 - attributes */ #define XFS_SB_VERSION_3 3/* 6.2 - new inode version */ NAK.
Quoted 7 lines
The XFS superblock magic number is part of the on-disk format definition of XFS. It belongs with all the other on-disk format definitions in this file.
Besides, there is almost never a good reason to be doing stuff based on filesystem magic numbers. What, exactly, do you need to know filesystem magic numbers for in the kernel?
IMA measures, appraises, and audits files based on policy. The builtin in measurement and appraisal policies can be defined on the boot command line (eg. ima_policy=tcb|appraise_tcb|secure_boot). These initial builtin policies are course grain.
After the LSMs are enabled, the IMA policy can be defined in terms of the LSM labels and other file metadata (eg. UUID, uid, euid, fsmagic, ...). Normally the builtin policies are subsequently replaced with a custom policy in the initramfs.
Mimi