Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759509AbcKCVMN (ORCPT ); Thu, 3 Nov 2016 17:12:13 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:34500 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758915AbcKCVML (ORCPT ); Thu, 3 Nov 2016 17:12:11 -0400 Date: Thu, 3 Nov 2016 14:12:07 -0700 From: Eric Biggers To: Andy Lutomirski Cc: linux-crypto@vger.kernel.org, Herbert Xu , "linux-kernel@vger.kernel.org" , Andrew Lutomirski Subject: Re: vmalloced stacks and scatterwalk_map_and_copy() Message-ID: <20161103211207.GB63852@google.com> References: <20161103181624.GA63852@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1526 Lines: 26 On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based interface to the crypto code? I bet it would be quite > a bit faster and it would make crypto on stack buffers work directly. I'd like to hear Herbert's opinion on this too, but as I understand it, if a symmetric cipher API operating on virtual addresses was added, similar to the existing "shash" API it would only allow software processing. Whereas with the current API you can request a transform and use it the same way regardless of whether the crypto framework has chosen a software or hardware implementation, or a combination thereof. If this wasn't a concern then I expect using virtual addresses would indeed simplify things a lot, at least for users not already working with physical memory (struct page). Either way, in the near term it looks like 4.9 will be released with the new behavior that encryption/decryption is not supported on stack buffers. Separately from the scatterwalk_map_and_copy() issue, today I've found two places in the filesystem-level encryption code that do encryption on stack buffers and therefore hit the 'BUG_ON(!virt_addr_valid(buf));' in sg_set_buf(). I will be sending patches to fix these, but I suspect there may be more crypto API users elsewhere that have this same problem. Eric