Request: Add XFS bigtime suport

[rmonk-redhat]

Describe the problem:

I'm using the docker hub "official" plaso container, but this symptom originally happened with a self-installed version as well. The official container is probably easier to replicate the issue.

Modern XFS filesystems look to have problems with getting correct timelines. Additionally, some new flags set ( rmapbt=1 or nrext64=0 ) that look like they are causing issues with reading files at all.

To Reproduce:

Prep XFS filesystems and copy in some random data from the filesystem

This makes 2x30GB files, so be warned.

mkdir data
dd if=/dev/zero of=data/test.xfs bs=1M count=30k
dd if=/dev/zero of=data/test2.xfs bs=1M count=30k

(In Fedora):
mkfs.xfs data/test.xfs

(In, for example, Alma Linux 9):
mkfs.xfs data/test2.xfs

(In either, does not matter)

rsync -avrP /usr /mnt/test
umount /mnt/test

rsync -avrP /usr/mnt/test
umount /mnt/test

Run log2timeline and psort:

The data that will have strange timelines:

podman run -v ./data:/data:rw,z -it --rm log2timeline/plaso log2timeline --storage-file /data/evidence.plaso /data/test.xfs
podman run -v ./data:/data:rw,z -it --rm log2timeline/plaso psort -w /data/timeline.log /data/evidence.plaso

The data that will be correct:

podman run -v ./data:/data:rw,z -it --rm log2timeline/plaso log2timeline --storage-file /data/evidence2.plaso /data/test2.xfs
podman run -v ./data:/data:rw,z -it --rm log2timeline/plaso psort -w /data/timeline2.log /data/evidence2.plaso

Results:

You'll see that the FILE timelines will have OBVIOUSLY bad timelines, 1997/1998 seems to show up a lot in my testing.

• test.xfs (bad timestamps, no file extraction)
• test2.xfs (bad timestamps for FILE items, but file extraction works)

If you look at the xfs info:

meta-data=data/test.xfs          isize=512    agcount=4, agsize=1966080 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=0  
data     =                       bsize=4096   blocks=7864320, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

meta-data=data/test-ubi9.xfs     isize=512    agcount=4, agsize=1966080 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
         =                       exchange=0  
data     =                       bsize=4096   blocks=7864320, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

The version of Plaso you used:
plaso - log2timeline version 20240826

The operating system you are running Plaso on (Not the operating system of the image/files you're trying to analyze):

Fedora 42 x86_64 (via log2timeline/plaso container)

Expected behavior:

The timestamps should match what you can see on the filesystem, and not show up as 1997/1998. For newer XFS filesystems, it should be able to extract data as well.

[joachimmetz]

This is likely due to missing bigtime format support libyal/libfsxfs#12