PadLock XSHA

PadLock XSHA

[Herbert Xu]

Hi Michal:

Can you remind me the reason why our PadLock SHA implementation
copies things into a page before hashing it?

According to the programming manual, it would seem that the state
should be recorded in EDI after each 64-byte block so we should
be able to use the init/update/final model, no?

Or has the chip changed since we implemented it?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: PadLock XSHA

[Michal Ludvig]

Hi Herbert,

> Can you remind me the reason why our PadLock SHA implementation
> copies things into a page before hashing it?
> 
> According to the programming manual, it would seem that the state
> should be recorded in EDI after each 64-byte block so we should
> be able to use the init/update/final model, no?
> 
> Or has the chip changed since we implemented it?

IIRC The first versions of VIA PadLock required the input data to be
aligned on 16-bytes boundaries and more importantly they always
finalised the hash. Therefore we had to collect all data before hashing
them.

The only way to allow for multiple updates before final() was through a
page fault, i.e. have a writable page followed by a non-accessible page,
put all the data that go into update() towards the end of the r/w page
and with some PadLock trickery run or resume hashing and tell it to hash
more than a page of input. As soon as it stepped to the non-accessible
space it would save the current state to memory and raise the page
fault. This has been implemented in OpenSSL padlock engine but am not
sure if we did it in the kernel as well. I doubt it.

AFAIK Recent versions of PadLock don't insist on finalising the hash and
 don't insist on input data alignment either and this workaround isn't
needed anymore. I don't know if VIA still sells their motherboard models
with the older CPUs or not.

HTH,

Michal

Re: PadLock XSHA

[Herbert Xu]

On Sat, Aug 30, 2008 at 09:55:00PM +1200, Michal Ludvig wrote:
> 
> IIRC The first versions of VIA PadLock required the input data to be
> aligned on 16-bytes boundaries and more importantly they always
> finalised the hash. Therefore we had to collect all data before hashing
> them.

Ah yes, the finalisation is the killer.

I'm working on a new sync hash interface that moves the state
out of the tfm and was just thinking of how padlock-sha would
work within that.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: PadLock XSHA

[Herbert Xu]

On Sat, Aug 30, 2008 at 09:55:00PM +1200, Michal Ludvig wrote:
> 
> IIRC The first versions of VIA PadLock required the input data to be
> aligned on 16-bytes boundaries and more importantly they always
> finalised the hash. Therefore we had to collect all data before hashing
> them.

Hmm, the current manual states that it does a bswap on the input
and therefore alignment isn't required.  There is no mention about
older processors requiring 16-byte alignment.

Do you know if the old alignment requirement is documented anywhere?
Or even better do you have a processor that enforces this?

Not requiring the alignment would allow IPsec at least to avoid
having to copy the data.

> AFAIK Recent versions of PadLock don't insist on finalising the hash and
>  don't insist on input data alignment either and this workaround isn't
> needed anymore. I don't know if VIA still sells their motherboard models
> with the older CPUs or not.

Interesting.  I couldn't find anything in the manual about not
requireing finalisation.  Do you know where I can find out more
about this?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: PadLock XSHA

[Michal Ludvig]

Herbert Xu wrote:
> On Sat, Aug 30, 2008 at 09:55:00PM +1200, Michal Ludvig wrote:
>> IIRC The first versions of VIA PadLock required the input data to be
>> aligned on 16-bytes boundaries and more importantly they always
>> finalised the hash. Therefore we had to collect all data before hashing
>> them.
> 
> Hmm, the current manual states that it does a bswap on the input
> and therefore alignment isn't required.  There is no mention about
> older processors requiring 16-byte alignment.

That's right, I confused SHA with AES in PadLock, sorry. With AES the 
first versions required 16-byte alignment on input and output data as 
well as on the control word and there's a flag in newer PadLocks that 
allow doing AES on unaligned data.

>> AFAIK Recent versions of PadLock don't insist on finalising the hash and
>>  don't insist on input data alignment either and this workaround isn't
>> needed anymore. I don't know if VIA still sells their motherboard models
>> with the older CPUs or not.
> 
> Interesting.  I couldn't find anything in the manual about not
> requireing finalisation.  Do you know where I can find out more
> about this?

I can't find any PadLock guide newer than 2005-05-03 (probably the same 
one that you have). I'll check with VIA what the status of this is.

Michal

Re: PadLock XSHA

[Herbert Xu]

On Mon, Sep 01, 2008 at 01:32:48PM +1200, Michal Ludvig wrote:
>
> That's right, I confused SHA with AES in PadLock, sorry. With AES the 
> first versions required 16-byte alignment on input and output data as 
> well as on the control word and there's a flag in newer PadLocks that 
> allow doing AES on unaligned data.

Excellent.  We can use this to avoid copying for IPsec then.
 
> I can't find any PadLock guide newer than 2005-05-03 (probably the same 
> one that you have). I'll check with VIA what the status of this is.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: PadLock XSHA

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Hi again,

On Mon, Sep 01, 2008 at 01:44:13PM +1000, Herbert Xu wrote:
> On Mon, Sep 01, 2008 at 01:32:48PM +1200, Michal Ludvig wrote:
> >
> > That's right, I confused SHA with AES in PadLock, sorry. With AES the 
> > first versions required 16-byte alignment on input and output data as 
> > well as on the control word and there's a flag in newer PadLocks that 
> > allow doing AES on unaligned data.
> 
> Excellent.  We can use this to avoid copying for IPsec then.

I agree.

> > I can't find any PadLock guide newer than 2005-05-03 (probably the same 
> > one that you have). I'll check with VIA what the status of this is.

The last published version is 1.66 from 4th August 2005. There really is
no update since there was no later silicon changes or padlock related errata
for padlock in any of the C7 ever since.

I expect there will be a new release for padlock in the CN/Nano at some
not too distant point.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: PadLock XSHA

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

Sorry for the late response, and putting on my VIA hat for a second:

On Sat, Aug 30, 2008 at 09:55:00PM +1200, Michal Ludvig wrote:
 
> > Can you remind me the reason why our PadLock SHA implementation
> > copies things into a page before hashing it?
> > 
> > According to the programming manual, it would seem that the state
> > should be recorded in EDI after each 64-byte block so we should
> > be able to use the init/update/final model, no?
> > 
> > Or has the chip changed since we implemented it?
> 
> IIRC The first versions of VIA PadLock required the input data to be
> aligned on 16-bytes boundaries and more importantly they always
> finalised the hash. Therefore we had to collect all data before hashing
> them.
>
> AFAIK Recent versions of PadLock don't insist on finalising the hash and
> don't insist on input data alignment either and this workaround isn't
> needed anymore. I don't know if VIA still sells their motherboard models
> with the older CPUs or not.

as far as I know, all VIA padlock enabled processors that you can buy today
always finalize the hash.  I have heard rumors that with the CN / Nano this is
changing.  VIA will update the padlock programming manual about that.

Since AFAIK Nano is still only sampling and thre's no end-user product with
that CPU in the market yet, there's no hurry right now.

I'll make sure to ping you guys once three is news about this.
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]