Re: Byte Addressability And Beyond

MitchAlsup1 wrote:

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).

Memory resident files I agree with you about.  But in my conception of
how this would all work, there would be a key specified for each I/O
operation, thus, I/O to different files could trivially have different
keys.

 

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).

If the "boundary" of where the encrypted portion starts or ends
corresponds to where an I/O boundary is, then no problem.  If not, then
the interface requires requires the ability to start/stop encryption at
an arbitrary spot within the I/O.  I envision this to work sort of like
a scatter gather, but instead of different memory addresses, each
"chunk" is encrypted or not.  This is probably needed anyway for things
like netword I/O where you want to encrypt the data but not the header.
As for combining it with compression, clearly the encryption must come
after the compression, and decryption must come before decompression.
If you are doing the compression in the hardware interface that
shouldn't be a problem, and if you are doing it in the software, then
it definitly isn't a problem.

>

--
 - Stephen Fuld
(e-mail address disguised to prevent spam)