[LUAU] on-topic, finally!

[Jim Thompson]

On Sep 19, 2005, at 3:12 PM, Hawaii Linux Institute wrote:

> Brian Chee wrote:
>
>
>> The PODS project . . . now going to a Mini-ITX motherboard to  
>> create embedded
>> systems with no moving parts.
>>
>>
> Interesting info.  The mini-itx always fascinates me.
>
> Recently, VIA has begun selling its C7- and C7-M series CPUs, each  
> of which comprises an x86 processor and an encryption-coprocessor.   
> This new family of CPUs may greatly tip the balance b/t FreeNX and  
> LTSP, more in favor of the former (in that the coprocessor relieves  
> the main CPU from doing the encryption chores required by FreeNX).   
> With VMWare, the main Linux box can actually double as a Windows  
> server. (Or ???)  Wayne

The VIA encryption instructions (its really not a co-processor, per- 
se), which VIA has named "Padlock ACE", have been available for quite  
a while now.

Padlock ACE contains several sub-systems, not all of which are  
available on every processor (or stepping of a given processor.)

VIA introduced the Nehemiah processor core in January 2003.  This CPU  
included a hardware random number generator (RNG).  The subsystem was  
simply
known as "Padlock" (no ACE).

VIA processors featuring cores from the C5P Nehemiah core onwards  
integrate VIA's Advanced Cryptography Engine (this is the ACE part)  
that can encrypt or decrypt data at a sustained rate of 12.8 gigabits  
per second (Gb/s). The downside is that only AES (The FIPS-standard  
"Advanced Encryption Standard", which replaces DES) is supported an  
only at three key lengths (128-bits, 196-bits, and 256-bits).

This is faster than any known commercial AES hardware implementation,  
and several times faster than software implementations running on P4  
or Athlon/Opteron CPUs.

One popular C5P based part is the Eden N.

VIA processors based on the ‘Esther' core include a Montgomery  
Multiplier, supporting key sizes up to 32K in length, used to  
accelerate the computational throughput of public key cryptography,  
such as RSA algorithms.   The Esther core can also accelerate SHA-1  
and SHA-256 "secure hash" algorithms.

As far as I'm aware, the only additional security function found in  
the C7 and C7-M processors is VIA's "NX Execute Protection", a  
hardware memory protection scheme used to prevent some "buffer  
overflow" attacks.

Back to the "its not a co-processor" bit.  These enhancements are  
provided by new, VIA-specific instructions, with the exception of the  
h/w RNG which provides a set of on-die 'buffers' into which the CPU  
constantly stuffs new random bits.  Software can come along and  
'harvest' a bunch of bits as it needs, with zero impact to the  
executing program, by running the 'xstore' instruction.

For a more technical bent (and support my assertions above) quoting  
http://www.logix.cz/michal/doc/article.xp/padlock-en
> If the model is 9, your CPU has a Nehemiah core; if the model is  
> 10, it has an Esther core. The stepping denotes a revision of each  
> model. You can find your processor's version in /proc/cpuinfo.
>
> Nehemiah stepping 3 and higher offers an electrical noise-based  
> random number generator (RNG) that produces good random numbers for  
> different purposes. The instruction for accessing the RNG is called  
> xstore. As in Intel and AMD processors, the random number generator  
> in VIA processors is supported by the hw_random device driver.
>
> Nehemiah stepping 8 and higher contains two independent RNGs and  
> the Advanced Cryptography Engine (ACE). The ACE can encrypt and  
> decrypt data using the Advanced Encryption Standard (AES) algorithm  
> with three standard key lengths-128, 192 and 256 bytes-in four  
> different modes of operation: electronic codebook (ECB), cipher  
> block chaining (CBC), cipher feedback (CFB) and output feedback  
> (OFB) modes (see the on-line Resources). The appropriate  
> instructions are called xcryptecb, xcryptcbc and so on. Later in  
> this article, I predominately use their common group name, xcrypt,  
> instead of the mode-specific instruction names.
>
> Esther stepping 0 and higher inherited two RNG units from Nehemiah.  
> ACE was extended with counter (CTR) mode support and MAC (Message  
> Authentication Code) computation. And there are two new acronyms,  
> PHE and PMM. PadLock Hash Engine (PHE) is used for computing a  
> cryptographic hash, also known as a digest, of a given input block,  
> using the SHA1 or SHA256 algorithm. The proposed instruction name  
> is xsha.
>
> The PadLock Montgomery Multiplier (PMM) is responsible for speeding  
> up one of the most time-consuming computations used in asymmetric,  
> or public-key, cryptography: AB mod M, where A, B and M are huge  
> numbers, usually 1,024 or 2,048 bits. This instruction is called  
> montmul..

The 2.6.11 kernel provides support for most of Padlock/ACE out of the  
box.    I think most modern OpenSSL libraries also have support for  
Padlock/ACE.   Most modern ssh implementations will support a Padlock/ 
ACE engine, if present, and I can't think of any reason why LTSP  
couldn't run over an SSH tunnel, providing most, if not all of the  
benefits of FreeNX's SSL-based encryption.

But all of this is moot until the DOE decides to start putting VIA  
powered boxes in front of students, instead of the Intel-powered,  
Windows laden crapfest now "approved", possibly because the days of  
the power-hungry desktop are numbered and few.   The cost of non- 
renewable energy isn't going down anytime soon, and conservation is  
almost always less expensive than any viable 'alternative energy'  
plan.   (Solar cells, wind power, and wave energy all require energy  
'inputs' to build and maintain the generation and distribution  
facilities.)

The Land Cruiser (which will eventually be a hybrid) has a mini-itx  
computer mounted in it.  Its the box on the right in this (warning:  
quite large) photo
http://www.smallworks.com/~jim/LandCruiser/P8280034.JPG

Jim