Update Contributions/CheckList_for_Safety_Claims_on_a_Generic_Linux_S…

…ystem.md

Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>

Contributions/CheckList_for_Safety_Claims_on_a_Generic_Linux_System.md

@@ -114,7 +114,7 @@ From a very high level perspective, these modes bring two capability:
 The way these additional contexts are specified and implemented also grants them almost unfettered access to the kernel memory. The kernel might not even be aware of running on top of an hypervisor, or that a secure mode is mediating its access to certain memory.
 Needless to say, these privileges also provide an unbounded ability to interfere.
 
-**Can the kernel do anything to protect itself against this interference?** Possibly, but it would ome very close to sprinkling checksums and redundancy all over. This would mean diverging significantly from a vanilla kernel *and* also introducing a noticeable overhead.
+**Can the kernel do anything to protect itself against this interference?** Possibly, but it would come very close to sprinkling checksums and redundancy all over. This would mean diverging significantly from a vanilla kernel *and* also introducing a noticeable overhead.
 
 **What else can be done?** It depends. One might attempt to rely on significant redundancy and then deploy some form of safe monitor, responsible of comparing the behavior of the paired systems. Alternatively, one could qualify these additional contexts which have the ability to interfere. Considering that usually these contexts are already subject to very rigorous process, because they can do so much damage, if buggy, it might be easier to qualify them, than it would be to qualify the Linux kernel. Furthermore, they tend to be more specialised pieces of software, implementing less functionality, with less code, than a full blown operating system.
 The choice lies with the system designer and integrator, however these listed here are probably the most common options available.