From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6ZW3X9G-nIw for ; Tue, 22 Jan 2013 17:01:41 +0100 (CET) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 22 Jan 2013 17:01:41 +0100 (CET) Received: by mail-wi0-f178.google.com with SMTP id hn3so6049744wib.17 for ; Tue, 22 Jan 2013 08:01:40 -0800 (PST) Message-ID: <50FEB647.8060005@gmail.com> Date: Tue, 22 Jan 2013 16:54:47 +0100 From: Milan Broz MIME-Version: 1.0 References: <20130122054223.GA25850@tansi.org> <50FE3EAF.3070206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Encrypting with larger packet size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dinesh Garg Cc: dm-crypt@saout.de On 01/22/2013 09:00 AM, Dinesh Garg wrote: > I think HW accelerator is an issue with smaller packet size because: > 1. It takes time to switch the context from software to hardware ( i.e. interrupt handling) > 2. HW accelerators dont allow multiple crypto operations at the same time due to security reasons I think all these problems are technically solvable but that's not discussion for dmcrypt list... > What do you mean by DM operates at 512B level? Is it that DM always > calls dmcrypt with 512B data even if file system is 4K block size? Everything in block layer is calculated in sectors of 512 bytes size, just for bigger sector size proper alignment is required. (So if we support, say 8k block, we must _force_ all layers to use only 8k block. Otherwise you will get data corruption.) > I tried aggregating scatter gather list at the crypto driver layer > but it did not work because DM supposedly operates at 512B. Sending > multiple encryptions commands to HW CE does not help due to CE setup > time etc. As I said above, you have force DM/block layer to accept only properly sized requests. Otherwise I do not see problem in crypto layer. (This should be simulated with kernel cryptd() driver even without proper crypto hw, just it need some hacking.) > dm-crypt is excellent block driver encryption solution. If anyone can > guide me, I would like to contribute as this is problem faced by HW > accelerator( I read several mails in the archive). Please can you be more specific? Which HW accelerator you are using, where is the source of it and when it will be part of upstream kernel? (if not already). But as I said, the patch for dmcrypt is not complicated, it is incompatibility later which this can cause. So I would really like to see strong reason before we implement direct support for larger sectors. > As per my understanding, AES-NI is not supported on arm based > chipset. Sure, that was just an example. But I am sure that even on ARM you can do hw acceleration which works with 512 bytes sectors. Even if we provide option to use bigger block size, it will not be compatible with LUKS devices and other encryption schemes (like TrueCrypt) which use 512 block always. Milan