On 12.11.2010, 08:34 Huang Ying wrote:
On Fri, 2010-11-12 at 15:30 +0800, Mathias Krause wrote:
>> On 12.11.2010, 01:33 Huang Ying wrote:
>>> Hi, Mathias,
>>>
>>> On Fri, 2010-11-12 at 06:18 +0800, Mathias Krause wrote:
All test were run five times in a row using a 256 bit key and doing i/o
>
On Fri, 2010-11-12 at 15:30 +0800, Mathias Krause wrote:
> On 12.11.2010, 01:33 Huang Ying wrote:
> > Hi, Mathias,
> >
> > On Fri, 2010-11-12 at 06:18 +0800, Mathias Krause wrote:
> >> All test were run five times in a row using a 256 bit key and doing i/o
> >> to the block device in chunks of 1MB
On 12.11.2010, 01:33 Huang Ying wrote:
> Hi, Mathias,
>
> On Fri, 2010-11-12 at 06:18 +0800, Mathias Krause wrote:
>> All test were run five times in a row using a 256 bit key and doing i/o
>> to the block device in chunks of 1MB. The numbers are MB/s.
>>
>> x86 (i586 variant):
>>1. run
Hi, Mathias,
On Fri, 2010-11-12 at 06:18 +0800, Mathias Krause wrote:
> All test were run five times in a row using a 256 bit key and doing i/o
> to the block device in chunks of 1MB. The numbers are MB/s.
>
> x86 (i586 variant):
> 1. run 2. run 3. run 4. run 5. runmean
> ECB:
On Thu, Nov 11, 2010 at 08:11:21PM +0200, Dmitry Kasatkin wrote:
> Hi,
>
> Yes. Our HW is capable of producing unfinalised hashes.
> Everything is fine.
OK then you should be fine even if the user never makes the "final"
call, right?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.
On Thu, 2010-11-11 at 19:48 +, David Howells wrote:
> Mimi Zohar wrote:
>
> > Reviewd-by: Mimi Zohar
>
> You've missed an 'e'.
thanks, will fix
> > +int tpm_send(u32 chip_num, char *cmd, int buflen)
> > +{
> > ...
> > + rc = transmit_cmd(chip, (struct tpm_cmd_t *)cmd, buflen,
> > +
On Thu, 2010-11-11 at 19:48 +, David Howells wrote:
> Mimi Zohar wrote:
>
> > +void hex2bin(unsigned char *mem, char *buf, int count)
>
> I think this needs a little adjustment. I would recommend something like the
> following declaration:
>
> void hex2bin(u8 *buf, const char *data,
The AES-NI instructions are also available in legacy mode so the 32-bit
architecture may profit from those, too.
To illustrate the performance gain here's a short summary of a dm-crypt
speed test on a Core i7 M620 running at 2.67GHz comparing both assembler
implementations:
x86:
Hello Huang Ying,
On 03.11.2010, 23:27 Huang Ying wrote:
> On Wed, 2010-11-03 at 14:14 -0700, Mathias Krause wrote:
>> The AES-NI instructions are also available in legacy mode so the 32-bit
>> architecture may profit from those, too.
>>
>> To illustrate the performance gain here's a short summar
Mimi Zohar wrote:
> Defines a new kernel key-type called 'trusted'. Trusted keys are
> random number symmetric keys, generated and RSA-sealed by the TPM.
> The TPM only unseals the keys, if the boot PCRs and other criteria
> match. Userspace can only ever see encrypted blobs.
I'd recommend sayi
Mimi Zohar wrote:
> +void hex2bin(unsigned char *mem, char *buf, int count)
I think this needs a little adjustment. I would recommend something like the
following declaration:
void hex2bin(u8 *buf, const char *data, size_t count)
since the output data is binary (so use u8*), you're on
Mimi Zohar wrote:
> Reviewd-by: Mimi Zohar
You've missed an 'e'.
> +int tpm_send(u32 chip_num, char *cmd, int buflen)
> +{
> ...
> + rc = transmit_cmd(chip, (struct tpm_cmd_t *)cmd, buflen,
> + "attempting tpm_cmd");
Make cmd 'void *' to obviate the cast. Preferably
Hi,
Yes. Our HW is capable of producing unfinalised hashes.
Everything is fine.
No. It is not broken.. It cleans up if error...
- Dmitry
On 11/11/10 18:17, ext Herbert Xu wrote:
> On Wed, Nov 10, 2010 at 04:54:51PM +0200, Dmitry Kasatkin wrote:
>
>> This is not good.
>>
>> Driver might allo
On Wed, Nov 10, 2010 at 04:54:51PM +0200, Dmitry Kasatkin wrote:
> This is not good.
>
> Driver might allocate some resources, which needs to be released.
> crypto_ahash_final() should do some kind of "cleanup" task.
Then your driver is broken. The whole hash API is designed around
the fact that
14 matches
Mail list logo
