Re: Byte Addressability And Beyond

Scott Lurndal wrote:

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

Scott Lurndal wrote:
>

  The ARM neoverse cores, for example, require very little area.

>
Agreed.  I was assuming that the cost of the logic was about the same
whether it was done as CPU instructions or a chunk of accelerator logic
in the I/O stream.  If that is true, then the cost of having multiples
of them in the I/O stream is small.

Although the accelerator requires addition logic to interface
to the CPUs (either by presenting as a memory mapped device,
integrated into the processor register scheme, or some other
proprietary mechanism).  Which means non-standard software is
required to manage and use the accelerator.

First consider that it is possible for an I/O device to DMA directly
to another I/O device in the PCIe routing tree/DAG.
Then, consider that with this infrastructure, you could DMA from
memory through the Cryptor and back to memory (or anywhere you wanted it).

>
>
>

 

From the operating software standpoint, it becomes most
convenient, then, to model the offload as a device which
requires OS support (and intervention for e.g. interrupt
handling).

  I look at it differently (and perhaps incorrectly).  I view
encryption as one of several "transformations" that data goes
through in its path to/from some external device.

 That's certainly a valid view, if perhaps not complete.   There are
use cases for in-place encryption.

>
Good.  Can you give some examples, and perhaps an estimate of what
percentage of the total encryption operations are in place?  Note that
it may be possible to add a feature to the "in-stream" hardware to
allow in-place encryption - i.e. both sides go to/come from memory.

Different users want their files encrypted using different keys than any other user--where file could be memory resident (or not).

Consider file access.   From the perspective of the disk, all blocks
are identical - it doesn't know which partition, filesystem, or file
that any individual block is part of, if any.

Whole-disk encryption can happen at the drive.    Per-file (or
per-filesystem) happens in the filesystem driver(s), perhaps
with a hardware assist, but it wouldn't be on the path from
the disk to memory.

You may be correct in how it is now--but if the device has encryption
services why can they not be applied sector by sector ??

There are cases where only a portion of a file is encrypted, and
cases where the encryption is combined with compression (pkzip,
rar, etc).

>
>
>

Adding encryption (which of the dozen standard symmetric and
asymmetric cipher algoritnms?) to a hardware device does increase
complexity, and thus cost at the expense of extensibility (new
algorithms come along periodically).

>
Agreed.  But this is also true for new CPU instructions.

An hardware accelerator could, for example, be microcoded
rather than using hard logic to future-proof it.

>
>

 The cost of verifying crypto is
a bit higher as it is very important to get correct when baking into
gates.

Verifying encryption is not harder than verifying IEEE 754
instructions.

>
>
Sure,  And I expect it is also higher because of the extra security
precautions against side attacks, etc.

Timing attacks, in particular.

All the more reason to run encryption through a device where you cannot
measure time accurately. I/O fits this bill very well. It seems to me
that
as long as the system can maintain the cryption throughput all should
be
well.