linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: syzbot <syzbot+94a8c779c6b238870393@syzkaller.appspotmail.com>,
	adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	David Howells <dhowells@redhat.com>
Subject: Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer
Date: Fri, 30 Jun 2023 13:13:42 -0400	[thread overview]
Message-ID: <20230630171342.GC591635@mit.edu> (raw)
In-Reply-To: <20230630074614.GC36542@sol.localdomain>

On Fri, Jun 30, 2023 at 12:46:14AM -0700, Eric Biggers wrote:
> > AF_ALG has existed since 2010.  My understanding that its original purpose was
> > to expose hardware crypto accelerators to userspace.  Unfortunately, support for
> > exposing *any* crypto algorithm was included as well, which IMO was a mistake.

+1000....

> > There are quite a few different userspace programs that use AF_ALG purely to get
> > at the CPU-based algorithm implementations, without any sort of intention to use
> > hardware crypto accelerator.  Probably because it seemed "easy".  Or "better"
> > because everything in the kernel is better, right?

Do we know if any to standard crypto libraries are using AF_ALG?  All
aside from whether it's a good idea for userspace programs to be using
kernel code because "everything is better in the kernel", I'm
wondering how solicitous we should be for programs who are very likely
rolling their own crypto, as opposed to using crypto library that has
been written and vetted and tested for vulnerability by experts...

> > It's controlled by the CONFIG_CRYPTO_USER_API_* options, with the hash support
> > in particular controlled by CONFIG_CRYPTO_USER_API_HASH.  Though good luck
> > disabling it on most systems, as systemd depends on it...
> > 
> 
> Actually it turns out systemd has finally seen the light:
> https://github.com/systemd/systemd/commit/2c3794f4228162c9bfd9e10886590d9f5b1920d7

Aside from those PCI-attached crypto accelerators where you have to go
through the kernel (although my experience has been that most of the
time, the overhead for key scheduling, etc., is such that unless
you're doing bulk crypto on large chunks of data, using external
crypto hardware acclerators no longer makes sense 99.99% of the time
in the 21st century), I wonder if we should consider having the kernel
print a warning, "WARNING: [comm] is using AF_ALG; please consider
using a real crypto library instead of rolling your own crypto".

(Only half kidding.)

					- Ted

      reply	other threads:[~2023-06-30 17:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-25  2:21 [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer syzbot
2023-06-29  3:57 ` Theodore Ts'o
2023-06-30  7:41   ` Eric Biggers
2023-06-30  7:46     ` Eric Biggers
2023-06-30 17:13       ` Theodore Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230630171342.GC591635@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+94a8c779c6b238870393@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).