[PATCH v2] docs: security: ipe: fix typos and grammar

[Randy Dunlap]

On 3/8/26 11:07 AM, Evan Ducas wrote:
> Fix several spelling and grammar mistakes in the IPE
> documentation.
> 
> No functional change.
> 
> Signed-off-by: Evan Ducas <evan.j.ducas at gmail.com>

Acked-by: Randy Dunlap <rdunlap at infradead.org>
Thanks.

> ---
>  Documentation/security/ipe.rst | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/security/ipe.rst b/Documentation/security/ipe.rst
> index 4a7d953abcdc..5eb3e6265fbd 100644
> --- a/Documentation/security/ipe.rst
> +++ b/Documentation/security/ipe.rst
> @@ -18,7 +18,7 @@ strong integrity guarantees over both the executable code, and specific
>  *data files* on the system, that were critical to its function. These
>  specific data files would not be readable unless they passed integrity
>  policy. A mandatory access control system would be present, and
> -as a result, xattrs would have to be protected. This lead to a selection
> +as a result, xattrs would have to be protected. This led to a selection
>  of what would provide the integrity claims. At the time, there were two
>  main mechanisms considered that could guarantee integrity for the system
>  with these requirements:
> @@ -195,7 +195,7 @@ of the policy to apply the minute usermode starts. Generally, that storage
>  can be handled in one of three ways:
>  
>    1. The policy file(s) live on disk and the kernel loads the policy prior
> -     to an code path that would result in an enforcement decision.
> +     to a code path that would result in an enforcement decision.
>    2. The policy file(s) are passed by the bootloader to the kernel, who
>       parses the policy.
>    3. There is a policy file that is compiled into the kernel that is
> @@ -235,8 +235,8 @@ Updatable, Rebootless Policy
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
>  As requirements change over time (vulnerabilities are found in previously
> -trusted applications, keys roll, etcetera). Updating a kernel to change the
> -meet those security goals is not always a suitable option, as updates are not
> +trusted applications, keys roll, etcetera), updating a kernel to meet
> +those security goals is not always a suitable option, as updates are not
>  always risk-free, and blocking a security update leaves systems vulnerable.
>  This means IPE requires a policy that can be completely updated (allowing
>  revocations of existing policy) from a source external to the kernel (allowing
> @@ -370,7 +370,7 @@ Simplified Policy:
>  Finally, IPE's policy is designed for sysadmins, not kernel developers. Instead
>  of covering individual LSM hooks (or syscalls), IPE covers operations. This means
>  instead of sysadmins needing to know that the syscalls ``mmap``, ``mprotect``,
> -``execve``, and ``uselib`` must have rules protecting them, they must simple know
> +``execve``, and ``uselib`` must have rules protecting them, they must simply know
>  that they want to restrict code execution. This limits the amount of bypasses that
>  could occur due to a lack of knowledge of the underlying system; whereas the
>  maintainers of IPE, being kernel developers can make the correct choice to determine

-- 
~Randy