blob: daf8b1c07460925fc1c1634d98fb17fe88ec9929 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
|
\input{configpres}
\title{\lq Maintainance and Lifecycle Management\rq}
\maketitle
\subsection{QA / Selecting the correct versions}
\begin{frame}
\frametitle{Versioning of the Linux Kernel}
\begin{itemize}
\item 2.6.37
\item 2.6.38
\item 2.6.39
\item 3.0
\item ...
\item 3.19
\item 4.0
\item ...
\item 4.19
\item 5.0
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{The release cycle of the Linux Kernel}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/dev_cycle_kernel.jpg}
\end{figure}
\end{frame}
\begin{frame}
\frametitle{Stable releases of the Linux Kernel}
\begin{itemize}
\item Important bugfixes are being backported to older kernel versions
\item It's always recommended to use the latest stable release of your kernel version
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{QA in the Linux Kernel}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/linux_qa.png}
\end{figure}
\end{frame}
\begin{frame}
\frametitle{Longterm kernels}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/kernel_org.png}
\end{figure}
kernel.org
\end{frame}
\begin{frame}
\frametitle{Longterm kernels}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/longterm.png}
\end{figure}
https://www.kernel.org/category/releases.html
\end{frame}
\begin{frame}
\frametitle{Choosing a kernel version}
\begin{itemize}
\item Take the latest longterm release
\item When the release goes EOL update to the most recent longterm
\item Updating to the next longterm is less effort and less error
prone than backporting
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Grading the quality of Open-Source components}
\begin{itemize}
\item Is the project actively maintained?
\item How big is the community?
\item How diverge is the community?
\item Does it fullfil my technical requirements
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Quality assurance}
\begin{itemize}
\item QA from the projects is mostly based on Code Review
\item Be aware that you might need to test on your specific hardware
\item Since the variety of the use cases is so big, the community can't
cover testing for these cases
\item So, there's always a risk, that a specifig feature won't work
\item Calculate time for this risk in your projects!
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Other aspects of quality assurance}
\begin{itemize}
\item Is license compliance handled correctly?
\item For third-party deliveries: Are all needed documents
for license compliance delivered?
\item Does the supplier provide the results of a license scan?
\item Is the compliance process of the supplier certified in some way?
(e.g. OpenCHAIN)
\item You shoud run a license scan
\end{itemize}
\end{frame}
\subsection{Building your Linux system}
\begin{frame}
\frametitle{Different approaches of building your Linux distribution}
\begin{itemize}
\item Roll your own (have fun with that one... ;-))
\item Using a pre-existing free distribution
\item Vendor based Linux
\item Commercial Linux distribution
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Basic requirements for a build system}
Creating your custom distribution:
\begin{itemize}
\item Linux Kernel
\item GNU Tools
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Overview}
BUT: There are many addtional requirements:
\begin{itemize}
\item Systemboot concept
\item Update concept
\item Security concept
\item Application development
\item Continious integration
\item Release builds
\item Versioning
\item Lizence Management
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Most importantly: Security}
\begin{itemize}
\item Monitoring security advisories
\item Check if your product needs an update
\item Generating updates
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{What is YOCTO?}
\begin{itemize}
\item Ecosystem (not a single Open-Source project!)
\item Collection of Embedded Linux projects and tools
\item Framework for the industry to publish BSPs
\item NOT a Linux Distribution
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Just a few words on security}
...and why you SHOULD think about it!!
\end{frame}
\begin{frame}
\frametitle{Reasons people tell why they don't care about security}
\begin{itemize}
\item ''My device is running in a secure network''
\item ''There's no interest in attacking my device''
\item ''My software doesn't have any bugs''
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Reasons why they SHOULD care!}
\begin{itemize}
\item ''my device is running in a secure network''
\item answer: Just check the media for the successful attacks on ''secure'' networks which happened the past few weeks
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Reasons why they SHOULD care!}
\begin{itemize}
\item ''there's no interest in attacking my device''
\item answer: If it has a network interface there is always a reason. At least your device can send SPAM.
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Reasons why they SHOULD care!}
\begin{itemize}
\item ''my software doesn't have any bugs''
\item answer 1: Oh well....dream on...
\item answer 2: If your software doesn't, some library you are using might have critical issues
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{And if you are still not convinced}
\begin{itemize}
\item In future you might even be forced to care by law
\item If you don't follow ''state of the art'' security techniques, you might be responsible for the results caused by any attack
\end{itemize}
\end{frame}
\begin{frame}[fragile]
\frametitle{OK, so back to Yocto...}
\begin{verbatim}
Since the Yocto Project is intended to be flexible
and meet the needs of many applications,
we leave policy-making decisions around security
to our end users.
\end{verbatim}
Source: https://wiki.yoctoproject.org/wiki/Security
\pause
\begin{verbatim}
Debian takes security very seriously.
We handle all security problems brought to our attention [...]
Many advisories [...] are published the same day
a vulnerability is made public
\end{verbatim}
Source: https://www.debian.org/security/index.en.html
\end{frame}
\begin{frame}[fragile]
\frametitle{Security}
YOCTO does:
\begin{itemize}
\item Keep software versions up-to-date
\item Fix critical software issues
\end{itemize}
\end{frame}
\begin{frame}
\includegraphics[width=\textwidth]{images/nvd.jpg}
\end{frame}
\begin{frame}
\includegraphics[width=\textwidth]{images/debian-cve.jpg}
\end{frame}
\begin{frame}
\includegraphics[width=\textwidth]{images/yocto-cve.jpg}
\\
This implies: Security tracking must be done by the Yocto user!
\end{frame}
\begin{frame}
\frametitle{Debian: Using an existing distribution}
\end{frame}
\begin{frame}
\frametitle{What is Debian?}
\begin{itemize}
\item A Linux Distribution (existing for more than 20 years)
\item Available for many CPU architectures: x86, ARM, PowerPC, MIPS
\item Debian is based on pre-compiled binary packages
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Debian package management}
\begin{itemize}
\item Simple licence management
\item Can be used for updates
\item Easy to be extended
\item Simple generation of custom packages
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Advantages of debian}
\begin{itemize}
\item Longevity
\item Packages (thousands of software packages are available and supported!)
\item No cross compilation
\item Security and Bugfixes!
\item Buildsystems for customization available (e.g. ELBE http://elbe-rfs.org/)
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Debian based Buildsystems}
\begin{itemize}
\item ELBE: http://elbe-rfs.org
\item ISAR: https://github.com/ilbers/isar
\item meta-debian: Meta-layer for Poky to build Debian sources
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Conclusion}
\begin{itemize}
\item Yocto helped to standardize the distribution of Linux BSPS
\item Yocto is NOT an Embedded Linux Distribution
\item Yocto / Poky is usually combined with a manufacturer layer and additional components
\item Debian is a pre-built disribution which can be used on embedded devices
\item Debian is very powerful when it comes to bug and security tracking
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Lifecycle Management}
\begin{itemize}
\item Don't underestimate the efforts for security tracking
\item Re-use community efforts as much as possible
\item Only use well maintained components
\item Only maintain custom changes if it's really possible
\end{itemize}
\end{frame}
\subsection{Interesting projects}
\begin{frame}
\frametitle{Debian longterm stable}
\begin{itemize}
\item At least 5 years of maintenance
\item Handled by a group of volunteers and companies
\item https://wiki.debian.org/LTS
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Civil infrastructure platform}
\begin{itemize}
\item https://www.cip-project.org/
\end{itemize}
\end{frame}
\input{tailpres}
|