Add cryptsetup + dm-crypt

[jonathan-conder]

Description

This probably isn't ready to merge yet - it works for me on ipq806x-1.3 but cryptsetup open causes a kernel panic on SRM 1.2, and possibly other architectures. I've also chosen which kernel modules to build based on synoconfigs/ipq806x - these choices might be different for other kernels (in particular dm-mod only depends on md-mod due to Synology-specific patches).

But I thought I would make a PR anyway in case others are interested. As a safety measure I've commented out the first insmod from dsm-control.sh, so the package doesn't auto-load after restarting the system (you have to manually insmod dm-builtin.ko first). It's also unsafe to auto-unload dm-builtin.ko due to a potential race condition (see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/md/dm-builtin.c for details).

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[jonathan-conder]

Oh also for x86_64 (with SSE) it probably makes sense to build argon2 and pass --enable-libargon2 to cross/cryptsetup

[hgy59]

@th0ma7 this branch fails in github build action while downloading prerequisites (i.e. kernel sources)

===>  Downloading toolchain
===>  Downloading files for syno-x86
===>    wget --secure-protocol=TLSv1_2 --timeout=30 --waitretry=0 --tries=5 -nv https://sourceforge.net/projects/dsgpl/files/Tool%20Chain/DSM%206.2.4%20Tool%20Chains/Intel%20x86%20linux%203.10.105%20%28Pineview%29/x64-gcc493_glibc220_linaro_x86_64-GPL.txz
2023-03-19 15:09:15 URL:https://master.dl.sourceforge.net/project/dsgpl/Tool%20Chain/DSM%206.2.4%20Tool%20Chains/Intel%20x86%20linux%203.10.105%20%28Pineview%29/x64-gcc493_glibc220_linaro_x86_64-GPL.txz?viasf=1 [58585904/58585904] -> "x64-gcc493_glibc220_linaro_x86_64-GPL.txz.part" [1]
/home/runner/work/spksrc/spksrc/kernel/syno-x86-6.2.4/work/tc_vars.mk:1: *** empty variable name.  Stop.
make: Leaving directory '/home/runner/work/spksrc/spksrc/kernel/syno-x86-6.2.4'

We should adjust the github build to limit the build for REQUIRE_KERNEL = 1 to just a few arch/tcversion combinations. As the cache will be overwhelmed it is not a good idea to build such packages for all combinaltions.
And it looks like there is an error in the syno-x86-6.2.4 toolchain.
Why does it build x86 instead of evansport ?

[th0ma7]

It's a section of the code that isn't that easy to handle right. Normally it should create a, let's say, x64 package containing pre-compiled modules for all x64 archs for a limited amout of kernels. This is set in spksrc.common.mk using SUPPORTED_KERNEL_VERSIONS = 6.1 6.2.4 7.0.

Still, the side effect of this is the total size which is just to much to handle. An option would be to generate arch-specific packages and never cache kernel files... But this would require a lot of changes to the code to handle.

to just a few arch/tcversion combinations

Which ones is the question? From a kernel versioning 6.1 & 6.2.4 & 7.0 makes sense (in lack of 7.1 kernel files). But should we also limit arch?

Still, there's clearly a bug somewhere, I'll investigate. But I'm away for work most of the week and I'll be looking at closing my other pernding PR's first.

[th0ma7]

And @jonathan-conder I really should have added, I'm glad someone else is using the kernel build portion of the framework. Your PR demonstrate the interesting possibilities that comes with it, nice work!

[hgy59]

Which ones is the question? From a kernel versioning 6.1 & 6.2.4 & 7.0 makes sense (in lack of 7.1 kernel files). But should we also limit arch?

For DSM 6, we can ommit all the 6.1 builds and build only for 6.2.4
Synology is about to drop all support for DSM < 6.2.4 (see https://www.synology.com/en-global/products/status/EOL-announcement-for-legacy-dsm)

[jonathan-conder]

And @jonathan-conder I really should have added, I'm glad someone else is using the kernel build portion of the framework. Your PR demonstrate the interesting possibilities that comes with it, nice work!

Thanks, I've actually been using it (and spksrc in general) for quite a while so I'm grateful for the work you and others have put into it

[th0ma7]

Suggesting to remove and document why it's being kept

[jonathan-conder]

I've added this back in for x86 where the external argon2 is recommended (due to SSE/AVX)

[th0ma7]

Are the binary needed or only the libraries are?

[jonathan-conder]

I don't see these being referenced anywhere so I've removed them

[th0ma7]

Instead you can simply use lib:lib/modules/** in the PLIST as there won't be any other modules directory.

[jonathan-conder]

ah ok, I had another patch which changed the PLIST behaviour, but accidentally broke that behaviour. Fixed now

[th0ma7]

This won't work on DSM7 as it isn't allowed.

[th0ma7]

This is well done. Although that won't work on DSM7 due to restricted permissions.

To alleviate this I had built a kernel module helper script part of synocli-kernel which can be called manually using a configuration file to load requested modules. It follows the load & unload order to avoid collisions on used modules.

What I would suggest is :

1. that you create a dependency towards the synocli-kernel package and provide a configuration file to be used.
2. Add documentation to the spksrc github wiki on how to use this package which could lead into (for instance) manually adding a command in the local.rc file to call the kernel module helper script using your configuration file.

On my end what I'll look into doing is relocating synocli-kernelmodule.sh to facilitate development without impacting spksrc repository so it can be easy for all to test prior to repackaging.

[jonathan-conder]

I've removed the dsm-control script and just made a standalone script. There are a few tricky things e.g. dm-builtin and dm-crypt vs. dm-crypt-armada so it was easier to make a script specific to this rather than extending the generic one. As a bonus this means fewer dependencies

[th0ma7]

Also, to limit impact I suggest you change spksrc.common.mk so it only get built for DSM 6.2.4 and 7.0
spksrc.common.mk:SUPPORTED_KERNEL_VERSIONS = 6.2.4 7.0

This will reduce the pre-download time significantly + reducing total cache disk space usage. Anyway, I intend to only provide theses two in future package (until 7.1 kernel sources gets released).

[th0ma7]

Also, FYI, I've now cleaned-up my personal synology repository and imported my latest snapshot of synocli-kernelmodule.sh here https://github.com/th0ma7/synology/tree/master/kernel

I'll be looking into fixing some of the issues raised earlier and add any missing features you may require (feel free to provide patches you see fit).

[jonathan-conder]

I've fixed most of those issues and added support for most of the 6.2.4 architectures. Although it just builds there, not sure if it actually works. Also added AES acceleration where supported (in theory some more of the ARMv7 architectures should support it too but it will require some more kernel patches). Not sure I'll be able to get around to 7.x support since it's pretty time consuming going through all the kernel configs. Maybe when 7.2 comes out.

[jonathan-conder]

I should explain why I'm reverting this. This is still useful when working on a package for a specific architecture. But when building dm-crypt for multiple architectures (e.g. for the aarch64 package), some of them are expected to fail because their kernel just doesn't support it. But the overall build should still succeed.