On Fri, Dec 04, 2020 at 10:46:26AM -0500, Bruce Fields wrote:
> On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> > Hi Chuck, Bruce,
> >
> > Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> > gss_krb5_aes_encrypt() c
On Fri, Dec 04, 2020 at 04:01:53PM +, David Howells wrote:
> Bruce Fields wrote:
>
> > > Reading up on CTS, I'm guessing the reason it's like this is that CTS is
> > > the
> > > same as the non-CTS, except for the last two blocks, but the
On Fri, Dec 04, 2020 at 02:59:35PM +, David Howells wrote:
> Hi Chuck, Bruce,
>
> Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
> gss_krb5_aes_encrypt() code looks like the attached.
>
> >From what I can tell, in AES mode, the difference between the main cipher and
>
On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
> Chuck Lever wrote:
>
> > Really? My understanding of the Linux kernel SUNRPC implementation is
> > that it uses asynchronous, even for small data items. Maybe I'm using
> > the terminology incorrectly.
>
> Seems to be synchronous,
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added
On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote:
> Hi Herbert, Dave, Trond,
>
> I've written basic gssapi-derived security support for AF_RXRPC:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk
>
> I've borrowed some bits from net
Acked-by: J. Bruce Fields
On Thu, Jul 02, 2020 at 12:19:43PM +0200, Ard Biesheuvel wrote:
> The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
> was specifically issued for interoperability with Windows 2000, but was
> never intended to receive the same level of sup
is for us.
>
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Eric Biggers
Acked-by: J. Bruce Fields
if you need it.
--b.
> ---
> fs/nfsd/nfs4recover.c | 26 ++
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/fs/n
On Fri, May 01, 2020 at 03:04:00PM -0400, Chuck Lever wrote:
> Over the past year or so I've observed that using sec=krb5i or
> sec=krb5p with NFS/RDMA while testing my Linux NFS client and server
> results in frequent connection loss. I've been able to pin this down
> a bit.
>
> The problem is th
Applying, thanks!--b.
On Wed, Mar 28, 2018 at 10:57:22AM -0700, Eric Biggers wrote:
> make_checksum_hmac_md5() is allocating an HMAC transform and doing
> crypto API calls in the following order:
>
> crypto_ahash_init()
> crypto_ahash_setkey()
> crypto_ahash_digest()
>
> This is wron
From: "J. Bruce Fields"
As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
among other callers, passes it memory on the stack.
We only need a scatterlist to pass this to the cr
On Mon, Apr 04, 2016 at 09:22:02AM +0800, Herbert Xu wrote:
> On Sun, Apr 03, 2016 at 06:15:43PM -0400, J. Bruce Fields wrote:
> > For some reason, the original didn't appear to get cc'd to the linux-nfs
> > list. Or did it, and I missed it? I do get lazy sometimes, but
On Sun, Apr 03, 2016 at 12:37:15PM +0800, Herbert Xu wrote:
> On Sat, Apr 02, 2016 at 11:59:00PM -0400, J. Bruce Fields wrote:
> >
> > Thanks. It's getting further now, but appears to be freezing later.
> > Possibly unrelated. I'm travelling, and it'll be Mon
On Sun, Apr 03, 2016 at 09:09:52AM +0800, Herbert Xu wrote:
> On Sat, Apr 02, 2016 at 08:13:19PM -0400, J. Bruce Fields wrote:
> > As of 3b5cf20c "sunrpc: Use skcipher and ahash/shash", I get a NULL
> > dereference in krb5_encrypt on an NFS server when a client attempts to
As of 3b5cf20c "sunrpc: Use skcipher and ahash/shash", I get a NULL
dereference in krb5_encrypt on an NFS server when a client attempts to
mount using krb5. I haven't tried to figure out what's going on beyond
that
--b.
[ 97.781559] IP: [] krb5_encrypt+0x138/0x1f0
[rpcsec_gss_krb5]
[ 9
On Wed, Mar 21, 2007 at 07:54:21AM +1100, Herbert Xu wrote:
> On Tue, Mar 20, 2007 at 10:16:14AM -0400, J. Bruce Fields wrote:
> >
> > Are the elements of the scatterlists assumed to always be full pages? I
>
> Definitely not.
>
> > need to encrypt thin
On Tue, Mar 20, 2007 at 10:16:14AM -0400, J. Bruce Fields wrote:
> On Tue, Mar 20, 2007 at 04:16:56PM +1100, Herbert Xu wrote:
> > Thanks for the patch. However I still have a question as to why
> > this is happening.
> >
> > As far as I can see scatterwalk_copyc
On Tue, Mar 20, 2007 at 04:16:56PM +1100, Herbert Xu wrote:
> Thanks for the patch. However I still have a question as to why
> this is happening.
>
> As far as I can see scatterwalk_copychunks is only called in two
> places. In both spots it only processes one block of data. Since
> we set the
ile.
A git-bisect shows the bug was originally introduced by
5c64097aa0f6dc4f27718ef47ca9a12538d62860, first in 2.6.19-rc1.
Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
---
crypto/scatterwalk.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cry
On Tue, Aug 30, 2005 at 10:45:54PM +0200, Jesper Juhl wrote:
> Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
> there's no longer any need for callers of that function to check for NULL.
...
> Feedback, ACK, NACK, etc welcome.
I've no problem with the auth_gss or nfsv4
20 matches
Mail list logo
