2016-10-18 21:37:56

by J. Bruce Fields

[permalink] [raw]
Subject: sg_set_buf

The NFS code is using sg_set_buf to turn a bit of stack menory into a
scatterlist it can pass to the crypto code. That started BUG()ing as of
ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping".

Is that BUG() being overly strict, or is this something we should never
have been doing in the first place?

--b.


2016-10-20 10:22:02

by Christoph Hellwig

[permalink] [raw]
Subject: Re: sg_set_buf

On Tue, Oct 18, 2016 at 05:37:55PM -0400, J. Bruce Fields wrote:
> The NFS code is using sg_set_buf to turn a bit of stack menory into a
> scatterlist it can pass to the crypto code. That started BUG()ing as of
> ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> mapping".
>
> Is that BUG() being overly strict, or is this something we should never
> have been doing in the first place?

In general we use scatterlists to pass dma addresses to hardware, so
yes, they should not point to the stack.

2016-10-20 13:20:31

by J. Bruce Fields

[permalink] [raw]
Subject: Re: sg_set_buf

On Thu, Oct 20, 2016 at 03:22:00AM -0700, Christoph Hellwig wrote:
> On Tue, Oct 18, 2016 at 05:37:55PM -0400, J. Bruce Fields wrote:
> > The NFS code is using sg_set_buf to turn a bit of stack menory into a
> > scatterlist it can pass to the crypto code. That started BUG()ing as of
> > ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> > mapping".
> >
> > Is that BUG() being overly strict, or is this something we should never
> > have been doing in the first place?
>
> In general we use scatterlists to pass dma addresses to hardware, so
> yes, they should not point to the stack.

The crypto code isn't actually doing that though, is it?

(Or is there a chance it could be passing the data to separate crypto
hardware? Do people do that these days?)

--b.

2016-10-20 13:31:09

by Christoph Hellwig

[permalink] [raw]
Subject: Re: sg_set_buf

On Thu, Oct 20, 2016 at 09:20:30AM -0400, J. Bruce Fields wrote:
> The crypto code isn't actually doing that though, is it?
>
> (Or is there a chance it could be passing the data to separate crypto
> hardware? Do people do that these days?)

Yes, there are tons of crypto accelarators, and they are built around
using struct scatterlist.

2016-10-20 21:42:21

by J. Bruce Fields

[permalink] [raw]
Subject: Re: sg_set_buf

On Thu, Oct 20, 2016 at 06:31:07AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 20, 2016 at 09:20:30AM -0400, J. Bruce Fields wrote:
> > The crypto code isn't actually doing that though, is it?
> >
> > (Or is there a chance it could be passing the data to separate crypto
> > hardware? Do people do that these days?)
>
> Yes, there are tons of crypto accelarators, and they are built around
> using struct scatterlist.

OK, thanks.

Turns out there are several places in the kerberos code where it just
needs to encrypt one small checksum or sequence number, and it's been
doing that on the stack.

For now I'll just sprinkle kmalloc()'s all over. Eventually we'll need
to find something better.

--b.

2016-10-21 12:26:17

by Christoph Hellwig

[permalink] [raw]
Subject: Re: sg_set_buf

On Thu, Oct 20, 2016 at 05:42:19PM -0400, J. Bruce Fields wrote:
> Turns out there are several places in the kerberos code where it just
> needs to encrypt one small checksum or sequence number, and it's been
> doing that on the stack.
>
> For now I'll just sprinkle kmalloc()'s all over. Eventually we'll need
> to find something better.

I agree that it would be nice to be able to hash small objects on the
stack. But unless I've missed something there is no way to do that
without using struct scatterlist. I've added linux-crypto to the cc
list to confirm that I really didn't miss anything.