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 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
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
> 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
>>
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
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 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
> 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 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
>>
16 matches
Mail list logo
