On 5/4/26 01:57, Milan Broz wrote: > Hi, > > On 5/1/26 9:24 PM, Demi Marie Obenour wrote: >> Cryptsetup needs CAP_SYS_ADMIN, but iwd definitely does not, and >> presumably BlueZ should not use have it either. > > In cryptsetup, AF_ALG is used exactly in places where it does > NOT need CAP_SYS_ADMIN. > > While I agree that AF_ALG is misdesigned (specifically, indirect > loading of kernel modules just on non-privileged user request), > it is used in real scenarios. > > I can write a long story why it is used in cryptsetup, but long > story short: > > - It is used for benchmarking, where we actually need kernel crypto. > > As it will be used in real dm-crypt mapping later, benchmarking > userspace lib just does not make sense. > (Requiring CAP_SYS_ADMIN here is not such a big issue, and it is > a very rough test - but useful for relative comparison, not for the > real numbers.)
Would an API to ask the kernel to benchmark its own algorithms work for this? That would be a more accurate benchmark as it removes syscall overhead. > - It is used in TrueCrypt/VeraCrypt compatibility (at least). > > This format needs to decrypt the header (first sector) with > the same algorithms as it is later mapped through dm-crypt. > Not everything is available in userspace (we support all historic > versions) and using AF_ALG was very convenient here. > > By removing AF_ALG, you will completely break this format support. > including some distros (I think Tails uses that :). > > We are using userspace libraries, but removing AF_ALG would be a pain. > It can be done, but it requires time. What is the source of the difficulty here? Just curious. >> Cryptsetup is a special case because there are times when it may not >> be safe to allocate memory: if I/O to the swap partition is suspended, >> and the kernel tries to page data out to it, the system may deadlock. >> So calling into arbitrary third-party libraries might not be the best >> idea. Thankfully, Nettle should meet all of cryptsetup's requirements. > > The cause with the swap is not such a big deal in reality. > > Nettle is NO WAY for cryptsetup (we have support for it as an alternative > backend, but it cannot be the default). You do not see the whole picture. I definitely don't see the whole picture. It came to mind because it has a nice, easy-to-use API. I'm also curious what keeps it from being the default. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
