Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.\" Copyright (c) 2020, Chelsio Inc
|
|
|
|
.\"
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
.\" modification, are permitted provided that the following conditions are met:
|
|
|
|
.\"
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright notice,
|
|
|
|
.\" this list of conditions and the following disclaimer.
|
|
|
|
.\"
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
.\"
|
|
|
|
.\" 3. Neither the name of the Chelsio Inc nor the names of its
|
|
|
|
.\" contributors may be used to endorse or promote products derived from
|
|
|
|
.\" this software without specific prior written permission.
|
|
|
|
.\"
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
|
|
.\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
|
|
|
|
.\" LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
.\" POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
.\"
|
|
|
|
.\" * Other names and brands may be claimed as the property of others.
|
|
|
|
.\"
|
|
|
|
.\" $FreeBSD$
|
|
|
|
.\"
|
2020-09-24 16:50:14 +00:00
|
|
|
.Dd September 24, 2020
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.Dt CRYPTO_BUFFER 9
|
|
|
|
.Os
|
|
|
|
.Sh NAME
|
|
|
|
.Nm crypto_buffer
|
|
|
|
.Nd symmetric cryptographic request buffers
|
|
|
|
.Sh SYNOPSIS
|
|
|
|
.In opencrypto/cryptodev.h
|
|
|
|
.Ft int
|
|
|
|
.Fo crypto_apply
|
|
|
|
.Fa "struct cryptop *crp"
|
|
|
|
.Fa "int off"
|
|
|
|
.Fa "int len"
|
|
|
|
.Fa "int (*f)(void *, void *, u_int)"
|
|
|
|
.Fa "void *arg"
|
|
|
|
.Fc
|
|
|
|
.Ft int
|
|
|
|
.Fo crypto_apply_buf
|
|
|
|
.Fa "struct crypto_buffer *cb"
|
|
|
|
.Fa "int off"
|
|
|
|
.Fa "int len"
|
|
|
|
.Fa "int (*f)(void *, void *, u_int)"
|
|
|
|
.Fa "void *arg"
|
|
|
|
.Fc
|
|
|
|
.Ft void *
|
|
|
|
.Fo crypto_buffer_contiguous_subsegment
|
|
|
|
.Fa "struct crypto_buffer *cb"
|
|
|
|
.Fa "size_t skip"
|
|
|
|
.Fa "size_t len"
|
|
|
|
.Fc
|
|
|
|
.Ft size_t
|
|
|
|
.Fn crypto_buffer_len "struct crypto_buffer *cb"
|
|
|
|
.Ft void *
|
|
|
|
.Fo crypto_contiguous_subsegment
|
|
|
|
.Fa "struct cryptop *crp"
|
|
|
|
.Fa "size_t skip"
|
|
|
|
.Fa "size_t len"
|
|
|
|
.Fc
|
|
|
|
.Ft void
|
|
|
|
.Fo crypto_cursor_init
|
|
|
|
.Fa "struct crypto_buffer_cursor *cc"
|
|
|
|
.Fa "const struct crypto_buffer *cb"
|
|
|
|
.Fc
|
|
|
|
.Ft void
|
|
|
|
.Fn crypto_cursor_advance "struct crypto_buffer_cursor *cc" "size_t amount"
|
|
|
|
.Ft void
|
|
|
|
.Fo crypto_cursor_copyback
|
|
|
|
.Fa "struct crypto_buffer_cursor *cc"
|
|
|
|
.Fa "int size"
|
|
|
|
.Fa "const void *src"
|
|
|
|
.Fc
|
|
|
|
.Ft void
|
|
|
|
.Fo crypto_cursor_copydata
|
|
|
|
.Fa "struct crypto_buffer_cursor *cc"
|
|
|
|
.Fa "int size"
|
|
|
|
.Fa "void *dst"
|
|
|
|
.Fc
|
|
|
|
.Ft void
|
|
|
|
.Fo crypto_cursor_copydata_noadv
|
|
|
|
.Fa "struct crypto_buffer_cursor *cc"
|
|
|
|
.Fa "int size"
|
|
|
|
.Fa "void *dst"
|
|
|
|
.Fc
|
|
|
|
.Ft void *
|
|
|
|
.Fn crypto_cursor_segbase "struct crypto_buffer_cursor *cc"
|
|
|
|
.Ft size_t
|
|
|
|
.Fn crypto_cursor_seglen "struct crypto_buffer_cursor *cc"
|
|
|
|
.Ft bool
|
|
|
|
.Fn CRYPTO_HAS_OUTPUT_BUFFER "struct cryptop *crp"
|
|
|
|
.Sh DESCRIPTION
|
|
|
|
Symmetric cryptographic requests use data buffers to describe the data to
|
|
|
|
be modified.
|
|
|
|
Requests can either specify a single data buffer whose contents are modified
|
|
|
|
in place,
|
|
|
|
or requests may specify separate data buffers for input and output.
|
|
|
|
.Vt struct crypto_buffer
|
|
|
|
provides an abstraction that permits cryptographic requests to operate on
|
|
|
|
different types of buffers.
|
|
|
|
.Vt struct crypto_cursor
|
|
|
|
allows cryptographic drivers to iterate over a data buffer.
|
|
|
|
.Pp
|
|
|
|
.Fn CRYPTO_HAS_OUTPUT_BUFFER
|
|
|
|
returns true if
|
|
|
|
.Fa crp
|
|
|
|
uses separate buffers for input and output and false if
|
|
|
|
.Fa crp
|
|
|
|
uses a single buffer.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_buffer_len
|
|
|
|
returns the length of data buffer
|
|
|
|
.Fa cb
|
|
|
|
in bytes.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_apply_buf
|
|
|
|
invokes a caller-supplied function
|
|
|
|
to a region of the data buffer
|
|
|
|
.Fa cb .
|
|
|
|
The function
|
|
|
|
.Fa f
|
|
|
|
is called one or more times.
|
|
|
|
For each invocation,
|
|
|
|
the first argument to
|
|
|
|
.Fa f
|
|
|
|
is the value of
|
|
|
|
.Fa arg
|
|
|
|
passed to
|
|
|
|
.Fn crypto_apply_buf .
|
|
|
|
The second and third arguments to
|
|
|
|
.Fa f
|
|
|
|
are a pointer and length to a segment of the buffer mapped into the kernel.
|
|
|
|
The function is called enough times to cover the
|
|
|
|
.Fa len
|
|
|
|
bytes of the data buffer which starts at an offset
|
|
|
|
.Fa off .
|
|
|
|
If any invocation of
|
|
|
|
.Fa f
|
|
|
|
returns a non-zero value,
|
|
|
|
.Fn crypto_apply_buf
|
|
|
|
immediately returns that value without invoking
|
|
|
|
.Fa f
|
|
|
|
on any remaining segments of the region,
|
|
|
|
otherwise
|
|
|
|
.Fn crypto_apply_buf
|
|
|
|
returns the value from the final call to
|
|
|
|
.Fa f .
|
|
|
|
.Fn crypto_apply
|
|
|
|
invokes the callback
|
|
|
|
.Fa f
|
|
|
|
on a region of the input data buffer for
|
|
|
|
.Fa crp .
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_buffer_contiguous_subsegment
|
|
|
|
attempts to locate a single, virtually-contiguous segment of the data buffer
|
|
|
|
.Fa cb .
|
|
|
|
The segment must be
|
|
|
|
.Fa len
|
|
|
|
bytes long and start at an offset of
|
|
|
|
.Fa skip
|
|
|
|
bytes.
|
|
|
|
If a segment is found,
|
|
|
|
a pointer to the start of the segment is returned.
|
|
|
|
Otherwise,
|
|
|
|
.Dv NULL
|
|
|
|
is returned.
|
|
|
|
.Fn crypto_contiguous_subsegment
|
|
|
|
attempts to locate a single, virtually-contiguous segment in the input data
|
|
|
|
buffer for
|
|
|
|
.Fa crp .
|
|
|
|
.Ss Data Buffers
|
|
|
|
Data buffers are described by an instance of
|
|
|
|
.Vt struct crypto buffer .
|
|
|
|
The
|
|
|
|
.Fa cb_type
|
|
|
|
member contains the type of the data buffer.
|
|
|
|
The following types are supported:
|
|
|
|
.Bl -tag -width " CRYPTO_BUF_CONTIG"
|
|
|
|
.It Dv CRYPTO_BUF_NONE
|
|
|
|
An invalid buffer.
|
|
|
|
Used to mark the output buffer when a crypto request uses a single data buffer.
|
|
|
|
.It Dv CRYPTO_BUF_CONTIG
|
|
|
|
An array of bytes mapped into the kernel's address space.
|
|
|
|
.It Dv CRYPTO_BUF_UIO
|
|
|
|
A scatter/gather list of kernel buffers as described in
|
|
|
|
.Xr uio 9 .
|
|
|
|
.It Dv CRYPTO_BUF_MBUF
|
|
|
|
A network memory buffer as described in
|
|
|
|
.Xr mbuf 9 .
|
2020-08-26 02:37:42 +00:00
|
|
|
.It Dv CRYPTO_BUF_VMPAGE
|
2020-09-17 20:50:02 +00:00
|
|
|
A scatter/gather list of
|
2020-08-26 02:37:42 +00:00
|
|
|
.Vt vm_page_t
|
|
|
|
structures describing pages in the kernel's address space.
|
|
|
|
This buffer type is only available if
|
|
|
|
.Dv CRYPTO_HAS_VMPAGE
|
|
|
|
is true.
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.El
|
|
|
|
.Pp
|
|
|
|
The structure also contains the following type-specific fields:
|
2020-08-26 02:37:42 +00:00
|
|
|
.Bl -tag -width " cb_vm_page_offset"
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.It Fa cb_buf
|
|
|
|
A pointer to the start of a
|
|
|
|
.Dv CRYPTO_BUF_CONTIG
|
|
|
|
data buffer.
|
|
|
|
.It Fa cb_buf_len
|
|
|
|
The length of a
|
|
|
|
.Dv CRYPTO_BUF_CONTIG
|
|
|
|
data buffer
|
|
|
|
.It Fa cb_mbuf
|
|
|
|
A pointer to a
|
|
|
|
.Vt struct mbuf
|
|
|
|
for
|
|
|
|
.Dv CRYPTO_BUF_MBUF .
|
|
|
|
.It Fa cb_uio
|
|
|
|
A pointer to a
|
|
|
|
.Vt struct uio
|
|
|
|
for
|
|
|
|
.Dv CRYPTO_BUF_UIO .
|
2020-08-26 02:37:42 +00:00
|
|
|
.It Fa cb_vm_page
|
|
|
|
A pointer to an array of
|
|
|
|
.Vt struct vm_page
|
|
|
|
for
|
|
|
|
.Dv CRYPTO_BUF_VMPAGE .
|
|
|
|
.It Fa cb_vm_page_len
|
|
|
|
The total amount of data included in the
|
|
|
|
.Fa cb_vm_page
|
|
|
|
array, in bytes.
|
|
|
|
.It Fa cb_vm_page_offset
|
|
|
|
Offset in bytes in the first page of
|
|
|
|
.Fa cb_vm_page
|
|
|
|
where valid data begins.
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.El
|
|
|
|
.Ss Cursors
|
|
|
|
Cursors provide a mechanism for iterating over a data buffer.
|
|
|
|
They are primarily intended for use in software drivers which access data
|
|
|
|
buffers via virtual addresses.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_init
|
|
|
|
initializes the cursor
|
|
|
|
.Fa cc
|
|
|
|
to reference the start of the data buffer
|
|
|
|
.Fa cb .
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_advance
|
|
|
|
advances the cursor
|
|
|
|
.Fa amount
|
|
|
|
bytes forward in the data buffer.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_copyback
|
|
|
|
copies
|
|
|
|
.Fa size
|
|
|
|
bytes from the local buffer pointed to by
|
|
|
|
.Fa src
|
|
|
|
into the data buffer associated with
|
|
|
|
.Fa cc .
|
|
|
|
The bytes are written to the current position of
|
|
|
|
.Fa cc ,
|
|
|
|
and the cursor is then advanced by
|
|
|
|
.Fa size
|
|
|
|
bytes.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_copydata
|
|
|
|
copies
|
|
|
|
.Fa size
|
|
|
|
bytes out of the data buffer associated with
|
|
|
|
.Fa cc
|
|
|
|
into a local buffer pointed to by
|
|
|
|
.Fa dst .
|
|
|
|
The bytes are read from the current position of
|
|
|
|
.Fa cc ,
|
|
|
|
and the cursor is then advanced by
|
|
|
|
.Fa size
|
|
|
|
bytes.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_copydata_noadv
|
|
|
|
is similar to
|
|
|
|
.Fn crypto_cursor_copydata
|
|
|
|
except that it does not change the current position of
|
|
|
|
.Fa cc .
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_segbase
|
|
|
|
and
|
|
|
|
.Fn crypto_cursor_seglen
|
|
|
|
return the start and length, respectively,
|
|
|
|
of the virtually-contiguous segment at the current position of
|
|
|
|
.Fa cc .
|
|
|
|
.Sh RETURN VALUES
|
|
|
|
.Fn crypto_apply
|
|
|
|
and
|
|
|
|
.Fn crypto_apply_buf
|
|
|
|
return the return value from the caller-supplied callback function.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_buffer_contiguous_subsegment ,
|
|
|
|
.Fn crypto_contiguous_subsegment ,
|
|
|
|
and
|
|
|
|
.Fn crypto_cursor_segbase ,
|
|
|
|
return a pointer to a contiguous segment or
|
|
|
|
.Dv NULL .
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_buffer_len
|
|
|
|
returns the length of a buffer in bytes.
|
|
|
|
.Pp
|
|
|
|
.Fn crypto_cursor_seglen
|
|
|
|
returns the length in bytes of a contiguous segment.
|
|
|
|
.Pp
|
|
|
|
.Fn CRYPTO_HAS_OUTPUT_BUFFER
|
|
|
|
returns true if the request uses a separate output buffer.
|
|
|
|
.Sh SEE ALSO
|
|
|
|
.Xr ipsec 4 ,
|
|
|
|
.Xr crypto 7 ,
|
2020-09-18 11:04:16 +00:00
|
|
|
.Xr bus_dma 9 ,
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.Xr crypto 9 ,
|
|
|
|
.Xr crypto_driver 9 ,
|
2020-09-17 20:50:02 +00:00
|
|
|
.Xr crypto_request 9 ,
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.Xr crypto_session 9 ,
|
2020-09-17 20:50:02 +00:00
|
|
|
.Xr mbuf 9 ,
|
Add support for optional separate output buffers to in-kernel crypto.
Some crypto consumers such as GELI and KTLS for file-backed sendfile
need to store their output in a separate buffer from the input.
Currently these consumers copy the contents of the input buffer into
the output buffer and queue an in-place crypto operation on the output
buffer. Using a separate output buffer avoids this copy.
- Create a new 'struct crypto_buffer' describing a crypto buffer
containing a type and type-specific fields. crp_ilen is gone,
instead buffers that use a flat kernel buffer have a cb_buf_len
field for their length. The length of other buffer types is
inferred from the backing store (e.g. uio_resid for a uio).
Requests now have two such structures: crp_buf for the input buffer,
and crp_obuf for the output buffer.
- Consumers now use helper functions (crypto_use_*,
e.g. crypto_use_mbuf()) to configure the input buffer. If an output
buffer is not configured, the request still modifies the input
buffer in-place. A consumer uses a second set of helper functions
(crypto_use_output_*) to configure an output buffer.
- Consumers must request support for separate output buffers when
creating a crypto session via the CSP_F_SEPARATE_OUTPUT flag and are
only permitted to queue a request with a separate output buffer on
sessions with this flag set. Existing drivers already reject
sessions with unknown flags, so this permits drivers to be modified
to support this extension without requiring all drivers to change.
- Several data-related functions now have matching versions that
operate on an explicit buffer (e.g. crypto_apply_buf,
crypto_contiguous_subsegment_buf, bus_dma_load_crp_buf).
- Most of the existing data-related functions operate on the input
buffer. However crypto_copyback always writes to the output buffer
if a request uses a separate output buffer.
- For the regions in input/output buffers, the following conventions
are followed:
- AAD and IV are always present in input only and their
fields are offsets into the input buffer.
- payload is always present in both buffers. If a request uses a
separate output buffer, it must set a new crp_payload_start_output
field to the offset of the payload in the output buffer.
- digest is in the input buffer for verify operations, and in the
output buffer for compute operations. crp_digest_start is relative
to the appropriate buffer.
- Add a crypto buffer cursor abstraction. This is a more general form
of some bits in the cryptosoft driver that tried to always use uio's.
However, compared to the original code, this avoids rewalking the uio
iovec array for requests with multiple vectors. It also avoids
allocate an iovec array for mbufs and populating it by instead walking
the mbuf chain directly.
- Update the cryptosoft(4) driver to support separate output buffers
making use of the cursor abstraction.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24545
2020-05-25 22:12:04 +00:00
|
|
|
.Xr uio 9
|
2020-09-24 16:50:14 +00:00
|
|
|
.Sh HISTORY
|
|
|
|
The
|
|
|
|
.Nm
|
|
|
|
functions first appeared in
|
|
|
|
.Fx 13 .
|
|
|
|
.Sh AUTHORS
|
|
|
|
The
|
|
|
|
.Nm
|
|
|
|
functions and this manual page were written by
|
|
|
|
.An John Baldwin Aq Mt jhb@FreeBSD.org .
|