1 files changed, 0 insertions, 70 deletions
diff --git a/doc/book-enea-nfv-access-dev-hardening-guide/doc/appendix_a.xml b/doc/book-enea-nfv-access-dev-hardening-guide/doc/appendix_a.xml
deleted file mode 100644
index c5d9aaa..0000000
--- a/doc/book-enea-nfv-access-dev-hardening-guide/doc/appendix_a.xml
+++ /dev/null
@@ -1,70 +0,0 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<appendix id="appendix_a">
-  <title>Useful Memory Terms</title>
-  <remark>Change the title to something better</remark>
-  <section id="buffer_overflow">
-    <title>Buffer overflow</title>
-    <para>A buffer overflow occurs when a program or process attempts to write
-    more data to a fixed length block of memory, or buffer, than the buffer is
-    allocated to hold.</para>
-    <para>Since buffers are created to contain a defined amount of data, the
-    extra data can overwrite data values in memory addresses adjacent to the
-    destination buffer, unless the program includes sufficient bounds checking
-    to flag or discard data when too much is sent to a memory buffer.
-    Languages such Ada, C#, Haskell, Java, JavaScript, Lisp, PHP, Python,
-    Ruby, and Visual Basic enforce run-time checking. </para>
-    <para>C and C++ are prone to buffer overflow attacks as they have no
-    built-in protection against accessing or overwriting data in any part of
-    their memory, and do not automatically check that data written to an array
-    (the built-in buffer type) is within the boundaries of that array.</para>
-  </section>
-  <section id="security_exploit">
-    <title>Security Exploit</title>
-    <para>On many systems, the memory layout of a program, or the system as a
-    whole, is well defined. Exploiting the behavior of a buffer overflow is a
-    well-known security exploit. By sending in data designed to cause a buffer
-    overflow, it is possible to write into areas known to hold an executable,
-    and replace it with malicious code.</para>
-    <para>Bounds checking can prevent buffer overflows, but requires
-    additional code and processing time. Modern operating systems use a
-    variety of techniques to combat malicious buffer overflows by randomizing
-    the layout of memory, or deliberately leaving space between buffers and
-    looking for actions that write into those areas "canaries". For further
-    reading about security exploits refer to the <ulink
-    url="https://www.exploit-db.com/">Exploit database</ulink>.</para>
-  </section>
-  <section id="hd_bounds_ck">
-    <title>Hardware Bounds Checking</title>
-    <para>The safety added by bounds checking costs CPU time if checking is
-    performed in software however, if the checks are performed by hardware
-    then safety can be provided "for free" with no runtime cost. </para>
-    <para>Research was started at least as early as 2005 regarding methods to
-    use x86's built-in virtual memory management unit to ensure safety of
-    array and buffer accesses. In 2015 Intel provided their Intel MPX
-    extensions in their Skylake processor architecture which stores bounds in
-    a CPU register and table in memory. As of early 2017 GCC among others,
-    supports MPX extensions.</para>
-  </section>
-  <section id="rootkit">
-    <title>Rootkit</title>
-    <para>A rootkit is a collection of malicious software designed to enable
-    access to another software that would not otherwise be allowed, e.g: to an
-    unauthorized user, and often masks its existence or the existence of other
-    software. The term rootkit is a concatenation of "root" and
-    the word "kit", which refers to the software components that implement the
-    tool, and is associated with malware.</para>
-  </section>
-</appendix>
-\ No newline at end of file

diff --git a/doc/book-enea-nfv-access-dev-hardening-guide/doc/appendix_a.xml b/doc/book-enea-nfv-access-dev-hardening-guide/doc/appendix_a.xml deleted file mode 100644 index c5d9aaa..0000000 --- a/doc/book-enea-nfv-access-dev-hardening-guide/doc/appendix_a.xml +++ /dev/null
@@ -1,70 +0,0 @@
1	<?xml version="1.0" encoding="ISO-8859-1"?>
2	<appendix id="appendix_a">
3	<title>Useful Memory Terms</title>
4
5	<remark>Change the title to something better</remark>
6
7	<section id="buffer_overflow">
8	<title>Buffer overflow</title>
9
10	<para>A buffer overflow occurs when a program or process attempts to write
11	more data to a fixed length block of memory, or buffer, than the buffer is
12	allocated to hold.</para>
13
14	<para>Since buffers are created to contain a defined amount of data, the
15	extra data can overwrite data values in memory addresses adjacent to the
16	destination buffer, unless the program includes sufficient bounds checking
17	to flag or discard data when too much is sent to a memory buffer.
18	Languages such Ada, C#, Haskell, Java, JavaScript, Lisp, PHP, Python,
19	Ruby, and Visual Basic enforce run-time checking. </para>
20
21	<para>C and C++ are prone to buffer overflow attacks as they have no
22	built-in protection against accessing or overwriting data in any part of
23	their memory, and do not automatically check that data written to an array
24	(the built-in buffer type) is within the boundaries of that array.</para>
25	</section>
26
27	<section id="security_exploit">
28	<title>Security Exploit</title>
29
30	<para>On many systems, the memory layout of a program, or the system as a
31	whole, is well defined. Exploiting the behavior of a buffer overflow is a
32	well-known security exploit. By sending in data designed to cause a buffer
33	overflow, it is possible to write into areas known to hold an executable,
34	and replace it with malicious code.</para>
35
36	<para>Bounds checking can prevent buffer overflows, but requires
37	additional code and processing time. Modern operating systems use a
38	variety of techniques to combat malicious buffer overflows by randomizing
39	the layout of memory, or deliberately leaving space between buffers and
40	looking for actions that write into those areas "canaries". For further
41	reading about security exploits refer to the <ulink
42	url="https://www.exploit-db.com/">Exploit database</ulink>.</para>
43	</section>
44
45	<section id="hd_bounds_ck">
46	<title>Hardware Bounds Checking</title>
47
48	<para>The safety added by bounds checking costs CPU time if checking is
49	performed in software however, if the checks are performed by hardware
50	then safety can be provided "for free" with no runtime cost. </para>
51
52	<para>Research was started at least as early as 2005 regarding methods to
53	use x86's built-in virtual memory management unit to ensure safety of
54	array and buffer accesses. In 2015 Intel provided their Intel MPX
55	extensions in their Skylake processor architecture which stores bounds in
56	a CPU register and table in memory. As of early 2017 GCC among others,
57	supports MPX extensions.</para>
58	</section>
59
60	<section id="rootkit">
61	<title>Rootkit</title>
62
63	<para>A rootkit is a collection of malicious software designed to enable
64	access to another software that would not otherwise be allowed, e.g: to an
65	unauthorized user, and often masks its existence or the existence of other
66	software. The term rootkit is a concatenation of "root" and
67	the word "kit", which refers to the software components that implement the
68	tool, and is associated with malware.</para>
69	</section>
70	</appendix> \ No newline at end of file