Hi Tyler, Michael
Did you have a chance to look at my latest reply below?
If we split the patch into smaller pieces and provide testing module with
prints that registers for events, as was suggested previously, can we
submit it for review ?
Regards, Andrey
>> On Wed, Nov 11, 2015 at 12:03:35PM
Hi Tyler, Michael
Did you have a chance to look at my latest reply below?
If we split the patch into smaller pieces and provide testing module with
prints that registers for events, as was suggested previously, can we
submit it for review ?
Regards, Andrey
>> On Wed, Nov 11, 2015 at 12:03:35PM
Hi Tyler, Michael
Did you have a chance to look at my latest reply below?
If we split the patch into smaller pieces and provide testing module with
prints that registers for events, as was suggested previously, can we
submit it for review ?
Regards, Andrey
>> On Wed, Nov 11, 2015 at 12:03:35PM
Hi Tyler, Michael
Did you have a chance to look at my latest reply below?
If we split the patch into smaller pieces and provide testing module with
prints that registers for events, as was suggested previously, can we
submit it for review ?
Regards, Andrey
>> On Wed, Nov 11, 2015 at 12:03:35PM
> On Wed, Nov 11, 2015 at 12:03:35PM -, andr...@codeaurora.org wrote:
>> > On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
>> >> This is a hardware inline accelerator, meaning that it operates on
>> much
>> >> lower layer, block layer and device driver layer. The HW encrypts
>> plain
>>
> On Wed, Nov 11, 2015 at 12:03:35PM -, andr...@codeaurora.org wrote:
>> > On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
>> >> This is a hardware inline accelerator, meaning that it operates on
>> much
>> >> lower layer, block layer and device driver layer. The HW encrypts
>> plain
>>
On Wed, Nov 11, 2015 at 12:03:35PM -, andr...@codeaurora.org wrote:
> > On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
> >> This is a hardware inline accelerator, meaning that it operates on much
> >> lower layer, block layer and device driver layer. The HW encrypts plain
> >> requests
> On Sun, Nov 08, 2015 at 10:10:00AM +0200, Andrey Markovytch wrote:
>> +++ b/fs/ecryptfs/caches_utils.c
>> @@ -0,0 +1,78 @@
>> +/*
>> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
>
> Really? This looks like copy and paste from core code that defintively
> was not written by
> On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
>> This is a hardware inline accelerator, meaning that it operates on much
>> lower layer, block layer and device driver layer. The HW encrypts plain
>> requests sent from block layer directly, thus doing it much more
>> efficiently rather
> On Sun, Nov 08, 2015 at 10:10:00AM +0200, Andrey Markovytch wrote:
>> +++ b/fs/ecryptfs/caches_utils.c
>> @@ -0,0 +1,78 @@
>> +/*
>> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
>
> Really? This looks like copy and paste from core code that defintively
> was not written by
> On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
>> This is a hardware inline accelerator, meaning that it operates on much
>> lower layer, block layer and device driver layer. The HW encrypts plain
>> requests sent from block layer directly, thus doing it much more
>> efficiently rather
On Wed, Nov 11, 2015 at 12:03:35PM -, andr...@codeaurora.org wrote:
> > On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
> >> This is a hardware inline accelerator, meaning that it operates on much
> >> lower layer, block layer and device driver layer. The HW encrypts plain
> >> requests
On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
> This is a hardware inline accelerator, meaning that it operates on much
> lower layer, block layer and device driver layer. The HW encrypts plain
> requests sent from block layer directly, thus doing it much more
> efficiently rather than
This is a hardware inline accelerator, meaning that it operates on much
lower layer, block layer and device driver layer. The HW encrypts plain
requests sent from block layer directly, thus doing it much more
efficiently rather than using crypto API.
In order to use such HW efficiently with
Hi Michael,
First of all, the original mechanism is still there and is used by
default, unless someone registers for external module and then indeed the
encryption is replaced for ciphers that this module decides to support.
Currently the only suggestion is to extend the framework that will allow
Hi Michael,
First of all, the original mechanism is still there and is used by
default, unless someone registers for external module and then indeed the
encryption is replaced for ciphers that this module decides to support.
Currently the only suggestion is to extend the framework that will allow
This is a hardware inline accelerator, meaning that it operates on much
lower layer, block layer and device driver layer. The HW encrypts plain
requests sent from block layer directly, thus doing it much more
efficiently rather than using crypto API.
In order to use such HW efficiently with
On 2015-11-10 15:20:59, andr...@codeaurora.org wrote:
> This is a hardware inline accelerator, meaning that it operates on much
> lower layer, block layer and device driver layer. The HW encrypts plain
> requests sent from block layer directly, thus doing it much more
> efficiently rather than
On Mon, Nov 09, 2015 at 08:56:02PM -, andr...@codeaurora.org wrote:
> Hello, Tyler
>
> I'll try to provide more detailed explanation, should it be satisfactory
> enough I will update the patch description.
>
> The problem with current eCryptfs is that it has total control on how and
> when
On 2015-11-09 20:56:02, andr...@codeaurora.org wrote:
> Hello, Tyler
>
> I'll try to provide more detailed explanation, should it be satisfactory
> enough I will update the patch description.
>
> The problem with current eCryptfs is that it has total control on how and
> when the encryption is
Hello, Tyler
I'll try to provide more detailed explanation, should it be satisfactory
enough I will update the patch description.
The problem with current eCryptfs is that it has total control on how and
when the encryption is performed and this control can't be altered. One
example when this
Hello Andrey!
On 2015-11-08 10:10:00, Andrey Markovytch wrote:
> From: Andrey Markovytch
>
> Currently eCryptfs is responsible for page encryption/decryption.
> This approach will not work when there is HW inline encryption.
> The proposed change allows external module to register with eCryptfs
On 2015-11-09 20:56:02, andr...@codeaurora.org wrote:
> Hello, Tyler
>
> I'll try to provide more detailed explanation, should it be satisfactory
> enough I will update the patch description.
>
> The problem with current eCryptfs is that it has total control on how and
> when the encryption is
On Mon, Nov 09, 2015 at 08:56:02PM -, andr...@codeaurora.org wrote:
> Hello, Tyler
>
> I'll try to provide more detailed explanation, should it be satisfactory
> enough I will update the patch description.
>
> The problem with current eCryptfs is that it has total control on how and
> when
Hello Andrey!
On 2015-11-08 10:10:00, Andrey Markovytch wrote:
> From: Andrey Markovytch
>
> Currently eCryptfs is responsible for page encryption/decryption.
> This approach will not work when there is HW inline encryption.
> The proposed change allows external module
Hello, Tyler
I'll try to provide more detailed explanation, should it be satisfactory
enough I will update the patch description.
The problem with current eCryptfs is that it has total control on how and
when the encryption is performed and this control can't be altered. One
example when this
Hi Andrey,
[auto build test ERROR on: v4.3-rc7]
[also build test ERROR on: next-20151106]
url:
https://github.com/0day-ci/linux/commits/Andrey-Markovytch/eCryptfs-enhancing-eCryptfs-to-be-used-with-external-crypto-engine/20151108-161722
config: i386-allmodconfig (attached as .config)
Hi Andrey,
[auto build test ERROR on: v4.3-rc7]
[also build test ERROR on: next-20151106]
url:
https://github.com/0day-ci/linux/commits/Andrey-Markovytch/eCryptfs-enhancing-eCryptfs-to-be-used-with-external-crypto-engine/20151108-161722
config: x86_64-randconfig-s0-11081650 (attached as
On Sun, Nov 08, 2015 at 10:10:00AM +0200, Andrey Markovytch wrote:
> +++ b/fs/ecryptfs/caches_utils.c
> @@ -0,0 +1,78 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
Really? This looks like copy and paste from core code that defintively
was not written by the Linux
Hi Andrey,
[auto build test ERROR on: v4.3-rc7]
[also build test ERROR on: next-20151106]
url:
https://github.com/0day-ci/linux/commits/Andrey-Markovytch/eCryptfs-enhancing-eCryptfs-to-be-used-with-external-crypto-engine/20151108-161722
config: x86_64-randconfig-s0-11081650 (attached as
On Sun, Nov 08, 2015 at 10:10:00AM +0200, Andrey Markovytch wrote:
> +++ b/fs/ecryptfs/caches_utils.c
> @@ -0,0 +1,78 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
Really? This looks like copy and paste from core code that defintively
was not written by the Linux
Hi Andrey,
[auto build test ERROR on: v4.3-rc7]
[also build test ERROR on: next-20151106]
url:
https://github.com/0day-ci/linux/commits/Andrey-Markovytch/eCryptfs-enhancing-eCryptfs-to-be-used-with-external-crypto-engine/20151108-161722
config: i386-allmodconfig (attached as .config)
32 matches
Mail list logo