linux-kernel - Re: [PATCH net] Documentation: tls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z0Qs7AyIxkZ75xPu@archie.me>
Date: Mon, 25 Nov 2024 14:53:16 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Leo Stone <leocstone@...il.com>, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	horms@...nel.org, corbet@....net
Cc: netdev@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] Documentation: tls_offload: fix typos and grammar

On Sun, Nov 24, 2024 at 03:00:02PM -0800, Leo Stone wrote:
> diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
> index 5f0dea3d571e..7354d48cdf92 100644
> --- a/Documentation/networking/tls-offload.rst
> +++ b/Documentation/networking/tls-offload.rst
> @@ -51,7 +51,7 @@ and send them to the device for encryption and transmission.
>  RX
>  --
>  
> -On the receive side if the device handled decryption and authentication
> +On the receive side, if the device handled decryption and authentication
>  successfully, the driver will set the decrypted bit in the associated
>  :c:type:`struct sk_buff <sk_buff>`. The packets reach the TCP stack and
>  are handled normally. ``ktls`` is informed when data is queued to the socket
> @@ -120,8 +120,9 @@ before installing the connection state in the kernel.
>  RX
>  --
>  
> -In RX direction local networking stack has little control over the segmentation,
> -so the initial records' TCP sequence number may be anywhere inside the segment.
> +In the RX direction, the local networking stack has little control over
> +segmentation, so the initial records' TCP sequence number may be anywhere
> +inside the segment.
>  
>  Normal operation
>  ================
> @@ -138,8 +139,8 @@ There are no guarantees on record length or record segmentation. In particular
>  segments may start at any point of a record and contain any number of records.
>  Assuming segments are received in order, the device should be able to perform
>  crypto operations and authentication regardless of segmentation. For this
> -to be possible device has to keep small amount of segment-to-segment state.
> -This includes at least:
> +to be possible, the device has to keep a small amount of segment-to-segment
> +state. This includes at least:
>  
>   * partial headers (if a segment carried only a part of the TLS header)
>   * partial data block
> @@ -175,12 +176,12 @@ and packet transformation functions) the device validates the Layer 4
>  checksum and performs a 5-tuple lookup to find any TLS connection the packet
>  may belong to (technically a 4-tuple
>  lookup is sufficient - IP addresses and TCP port numbers, as the protocol
> -is always TCP). If connection is matched device confirms if the TCP sequence
> -number is the expected one and proceeds to TLS handling (record delineation,
> -decryption, authentication for each record in the packet). The device leaves
> -the record framing unmodified, the stack takes care of record decapsulation.
> -Device indicates successful handling of TLS offload in the per-packet context
> -(descriptor) passed to the host.
> +is always TCP). If the packet is matched to a connection, the device confirms
> +if the TCP sequence number is the expected one and proceeds to TLS handling
> +(record delineation, decryption, authentication for each record in the packet).
> +The device leaves the record framing unmodified, the stack takes care of record
> +decapsulation. Device indicates successful handling of TLS offload in the
> +per-packet context (descriptor) passed to the host.
>  
>  Upon reception of a TLS offloaded packet, the driver sets
>  the :c:member:`decrypted` mark in :c:type:`struct sk_buff <sk_buff>`
> @@ -439,7 +440,7 @@ by the driver:
>   * ``rx_tls_resync_req_end`` - number of times the TLS async resync request
>      properly ended with providing the HW tracked tcp-seq.
>   * ``rx_tls_resync_req_skip`` - number of times the TLS async resync request
> -    procedure was started by not properly ended.
> +    procedure was started but not properly ended.
>   * ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to
>      the driver was successfully handled.
>   * ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to
> @@ -507,8 +508,8 @@ in packets as seen on the wire.
>  Transport layer transparency
>  ----------------------------
>  
> -The device should not modify any packet headers for the purpose
> -of the simplifying TLS offload.
> +For the purpose of simplifying TLS offload, the device should not modify any
> +packet headers.
>  
>  The device should not depend on any packet headers beyond what is strictly
>  necessary for TLS offload.

Looks good, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@...il.com>

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)