-
Notifications
You must be signed in to change notification settings - Fork 7
/
index2.html
781 lines (726 loc) · 71.7 KB
/
index2.html
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
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<title>Store Halfword Byte-Reverse Indexed</title>
<meta name="author" content="OzLabs">
<link href="https://sthbrx.github.io/rss.xml" type="application/rss+xml" rel="alternate"
title="Store Halfword Byte-Reverse Indexed RSS Feed" />
<!-- http://t.co/dKP3o1e -->
<meta name="HandheldFriendly" content="True">
<meta name="MobileOptimized" content="320">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link href="https://sthbrx.github.io/favicon.png" rel="icon">
<link href="https://sthbrx.github.io/theme/css/main.css" media="screen, projection"
rel="stylesheet" type="text/css">
<link href="//fonts.googleapis.com/css?family=PT+Serif:regular,italic,bold,bolditalic"
rel="stylesheet" type="text/css">
<link href="//fonts.googleapis.com/css?family=PT+Sans:regular,italic,bold,bolditalic"
rel="stylesheet" type="text/css">
<script type="text/javascript">
document.addEventListener('DOMContentLoaded', function() {
var ts = document.createElement('span')
ts.className = 'toggle-sidebar'
ts = document.getElementById('content').appendChild(ts);
ts.addEventListener('click', function(e) {
e.preventDefault();
body = document.getElementsByTagName('body')[0];
bodyClasses = body.classList.toggle('collapse-sidebar');
});
var sections = document.querySelectorAll('aside.sidebar > section');
if (sections.length > 1) {
for (index = 0; index < sections.length; index++) {
section = sections[index];
if ((sections.length >= 3) && index % 3 === 0) {
section.classList.add("first");
}
var count = ((index +1) % 2) ? "odd" : "even";
section.classList.add(count);
}
}
if (sections.length >= 3) {
document.querySelector('aside.sidebar').classList.add('thirds');
}
});
</script>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-91189608-1', 'auto');
ga('send', 'pageview');
</script>
</head>
<body>
<header role="banner"><hgroup>
<h1><a href="https://sthbrx.github.io/">Store Halfword Byte-Reverse Indexed</a></h1>
<h2>A Power Technical Blog</h2>
</hgroup></header>
<nav role="navigation"><ul class="subscription" data-subscription="rss">
<li><a href="https://sthbrx.github.io/rss.xml" rel="subscribe-rss">RSS</a></li>
</ul>
<ul class="main-navigation">
<li >
<a href="https://sthbrx.github.io/category/cryptography.html">Cryptography</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/development.html">Development</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/education.html">Education</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/openpower.html">OpenPOWER</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/performance.html">Performance</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/petitboot.html">Petitboot</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/snowpatch.html">snowpatch</a>
</li>
<li >
<a href="https://sthbrx.github.io/category/virtualisation-and-emulation.html">Virtualisation and Emulation</a>
</li>
</ul></nav>
<div id="main">
<div id="content">
<div class="blog-index">
<article>
<header>
<h1 class="entry-title">
<a href="https://sthbrx.github.io/blog/2022/11/16/what-distro-options-are-there-for-power8-in-2022/">What distro options are there for POWER8 in 2022?</a>
</h1>
<p class="meta">
<time datetime="2022-11-16T17:30:00+11:00" pubdate>Wed 16 November 2022</time> </p>
</header>
<div class="byline_index">
<span class="byline author vcard">
Posted by <span class="fn">
<a href="https://sthbrx.github.io/author/russell-currey.html">Russell Currey</a>
</span>
</span>
<time datetime="2022-11-16T17:30:00+11:00" pubdate>Wed 16 November 2022</time></div>
<div class="entry-content"><p>If you have POWER8 systems that you want to keep alive, what are your options in 2022? You can keep using the legacy distribution you're still using as long as it's still supported, but if you want some modernisation, that might not be the best option for you. Here's the current landscape of POWER8 support in major distributions, and hopefully it helps you out!</p>
<p>Please note that I am entirely focused on what runs and keeps getting new packages, not what companies will officially support. <a href="https://www.ibm.com/docs/en/linux-on-systems?topic=lpo-supported-linux-distributions-virtualization-options-power8-power9-linux-power-systems">IBM provides documentation for that.</a> I'm also mostly focused on OpenPOWER and not what's supported under IBM PowerVM.</p>
<p><strong>RHEL-compatible</strong></p>
<p>Things aren't too great on the RHEL-compatible side. RHEL 9 is compiled with P9 instructions, removing support for P8. This includes compatible distributions, like CentOS Stream and Rocky Linux.</p>
<p>You can continue to use RHEL 8 for a long time. Unfortunately, Rocky Linux only has a Power release for EL9 and not EL8, and CentOS Stream 8 hits EOL May 31st, 2024 - a bit too soon for my liking. If you're a RHEL customer though, you're set.</p>
<p><strong>Fedora</strong></p>
<p>Fedora seems like a great option - the latest versions still support P8 and there's no immediate signs of that changing. The issue is that Fedora could change this with relatively little warning (and their big brother RHEL already has), Fedora doesn't provide LTS versions that will stay supported if this happens, and any options you could migrate to would be very different from what you're using.</p>
<p>For that reason, I don't recommend using Fedora on POWER8 if you intend to keep it around for a while. If you want something modern for a short-term project, go right ahead! Otherwise, I'd avoid it. If you're still keeping POWER8 systems alive, you probably want something more set-and-forget than Fedora anyway.</p>
<p><strong>Ubuntu</strong></p>
<p>Ubuntu is a mixed bag. The good news is that Ubuntu 20.04 LTS is supported until mid-2025, and if you give Canonical money, that support can extend through 2030. Ubuntu 20.04 LTS is my personal pick for the best distro to install on POWER8 systems that you want to have somewhat modern software but without the risks of future issues.</p>
<p>The bad news is that POWER8 support went away in Ubuntu 22.04, which is extremely unfortunate. Missing an LTS cycle is one thing, but <em>not having a pathway from 21.10 is another</em>. If you were on 20.10/21.04/21.10, you are completely boned, because they're all out of support and 22.04 and later don't support POWER8. You're going to have to reinstall 20.04.</p>
<p>If I sound salty, it's because I had to do this for a few machines. Hopefully you're not in that situation. 20.04 is going to be around for a good while longer, with a lot of modern creature comforts you'd miss on an EL8-compatible distro, so it's my pick for now.</p>
<p><strong>OpenSUSE</strong></p>
<p>I'm pretty ignorant when it comes to chameleon-flavoured distros, so take this with a grain of salt as most of it is from some quick searching. OpenSUSE Leap follows SLES, but without extended support lifetimes for older major versions. From what I can tell, the latest release (15.4) still includes POWER8 support (and adds Power10 support!), but similar to Fedora, that looks rather prone to a new version dropping P8 support to me.</p>
<p>If the 15.x series stayed alive after 16 came out, you might be good, but it doesn't seem like there's a history of that happening.</p>
<p><strong>Debian</strong></p>
<p>Debian 11 "bullseye" came out in 2021, supports POWER8, and is likely to be supported until around 2026. I can't really chime in on more than that because I am a certified Debian hater (even newer releases feel outdated to me), but that looks like a pretty good deal.</p>
<p><strong>Other options</strong></p>
<p>Those are just some major distros, there's plenty of others, including some Power-specific ones from the community.</p>
<p><strong>Conclusion</strong></p>
<p>POWER8's getting old, but is still plenty capable. Make sure your distro still remembers to send your POWER8 a birthday card each year and you'll have plenty more good times to come.</p></div>
</article>
<article>
<header>
<h1 class="entry-title">
<a href="https://sthbrx.github.io/blog/2022/10/26/power-kernel-hardening-features-in-linux-61/">Power kernel hardening features in Linux 6.1</a>
</h1>
<p class="meta">
<time datetime="2022-10-26T16:30:00+11:00" pubdate>Wed 26 October 2022</time> </p>
</header>
<div class="byline_index">
<span class="byline author vcard">
Posted by <span class="fn">
<a href="https://sthbrx.github.io/author/russell-currey.html">Russell Currey</a>
</span>
</span>
<time datetime="2022-10-26T16:30:00+11:00" pubdate>Wed 26 October 2022</time></div>
<div class="entry-content"><p>Linux 6.1-rc1 was tagged on October 16th, 2022 and includes a bunch of nice things from my team that I want to highlight. Our goal is to make the Linux kernel running on IBM's Power CPUs more secure, and landed a few goodies upstream in 6.1 to that end.</p>
<p>Specifically, Linux 6.1 on Power will include <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e92e01b724526b98cbc7f03dd4afa0295780d56">a complete system call infrastructure rework with security <em>and</em> performance benefits</a>, <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5edf9815dd739fce660b4c8658f61b7d2517042">support for KFENCE (a low-overhead memory safety error detector)</a>, and <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=395cac7752b905318ae454a8b859d4c190485510">execute-only memory (XOM) support on the Radix MMU</a>.</p>
<p>The syscall work from Rohan McLure and Andrew Donnellan replaces arch/powerpc's legacy infrastructure with the syscall wrapper shared between architectures. This was a significant overhaul of a lot of legacy code impacting all of powerpc's many platforms, including multiple different ABIs and 32/64bit compatibility infrastructure. Rohan's series started at <a href="http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=302791&state=*">v1 with 6 patches</a> and ended at <a href="http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=319348&state=*">v6 with 25 patches</a>, and he's done an incredible job at adopting community feedback and handling new problems.</p>
<p>Big thanks to Christophe Leroy, Arnd Bergmann, Nick Piggin, Michael Ellerman and others for their reviews, and of course Andrew for providing a lot of review and feedback (and prototyping the syscall wrapper in the first place). Our syscalls have entered the modern era, we can zeroise registers to improve security (but don't yet due to some ongoing discussion around compatibility and making it optional, look out for Linux 6.2), and gain a nice little performance boost by avoiding the allocation of a kernel stack frame. For more detail, see <a href="http://patchwork.ozlabs.org/project/linuxppc-dev/cover/20220921065605.1051927-1-rmclure@linux.ibm.com/">Rohan's cover letter</a>.</p>
<p>Next, we have Nicholas Miehlbradt's implementation of <a href="https://www.kernel.org/doc/html/latest/dev-tools/kfence.html">Kernel Electric Fence (KFENCE)</a> (and <code>DEBUG_PAGEALLOC</code>) for 64-bit Power, including the Hash and Radix MMUs. Christophe Leroy has already implemented KFENCE for 32-bit powerpc upstream and a series adding support for 64-bit was posted by Jordan Niethe last year, but couldn't proceed due to locking issues. Those issues have since been resolved, and after fixing a previously unknown and very obscure MM issue, Nick's KFENCE patches have been merged.</p>
<p>KFENCE is a low-overhead alternative to memory detectors like KASAN (<a href="https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=41b7a347bf1491e7300563bb224432608b41f62a">which we implemented for Radix earlier this year, thanks to Daniel Axtens and Paul Mackerras</a>), which you probably wouldn't want to run in production. If you're chasing a memory corruption bug that doesn't like to present itself, KFENCE can help you do that for out-of-bounds accesses, use-after-frees, double frees etc without significantly impacting performance.</p>
<p>Finally, I wired up execute-only memory (XOM) for the Radix MMU. XOM is a niche feature that lets users map pages with <code>PROT_EXEC</code> only, creating a page that can't be read or written to, but still executed. This is primarily useful for defending against code reuse attacks like ROP, but has other uses such as JIT/sandbox environments. Power8 and later CPUs running the Hash MMU already had this capability through protection keys (pkeys), my implementation for Radix uses the native execute permission bit of the Radix MMU instead.</p>
<p>This basically took me an afternoon to wire up after I had the idea and I roped in Nicholas Miehlbradt to contribute a <a href="https://github.com/torvalds/linux/blob/master/tools/testing/selftests/powerpc/mm/exec_prot.c">selftest</a>, which ended up being a more significant engineering effort than the feature implementation itself. We now have a comprehensive test for XOM that runs on both Hash and Radix for all possible combinations of R/W/X upstream.</p>
<p>Anyway, that's all I have - this is my first time writing a post like this, so let me know what you think! A lot of our work doesn't result in upstream patches so we're not always going to have kernel releases as eventful as this, but we can post summaries every once in a while if there's interest. Thanks for reading!</p></div>
</article>
<article>
<header>
<h1 class="entry-title">
<a href="https://sthbrx.github.io/blog/2021/06/14/fuzzing-grub-part-2-going-faster/">Fuzzing grub, part 2: going faster</a>
</h1>
<p class="meta">
<time datetime="2021-06-14T17:10:00+10:00" pubdate>Mon 14 June 2021</time> </p>
</header>
<div class="byline_index">
<span class="byline author vcard">
Posted by <span class="fn">
<a href="https://sthbrx.github.io/author/daniel-axtens.html">Daniel Axtens</a>
</span>
</span>
<time datetime="2021-06-14T17:10:00+10:00" pubdate>Mon 14 June 2021</time></div>
<div class="entry-content"><p>Recently a set of 8 vulnerabilities were disclosed for the <a href="https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021">grub bootloader</a>. I
found 2 of them (CVE-2021-20225 and CVE-2021-20233), and contributed a number of
other fixes for crashing bugs which we don't believe are exploitable. I found
them by applying fuzz testing to grub. Here's how.</p>
<p>This is a multi-part series: I think it will end up being 4 posts. I'm hoping to
cover:</p>
<ul>
<li><a href="/blog/2021/03/04/fuzzing-grub-part-1">Part 1: getting started with fuzzing grub</a></li>
<li>Part 2 (this post): going faster by doing lots more work</li>
<li>Part 3: fuzzing filesystems and more</li>
<li>Part 4: potential next steps and avenues for further work</li>
</ul>
<p>We've been looking at fuzzing <code>grub-emu</code>, which is basically most parts of grub
built into a standard userspace program. This includes all the script parsing
logic, fonts, graphics, partition tables, filesystems and so on - just not
platform specific driver code or the ability to actually load and boot a kernel.</p>
<p>Previously, we talked about some issues building grub with AFL++'s
instrumentation:</p>
<div class="highlight"><pre><span></span><code>:::<span class="nv">text</span>
.<span class="o">/</span><span class="nv">configure</span><span class="w"> </span><span class="o">--</span><span class="nv">with</span><span class="o">-</span><span class="nv">platform</span><span class="o">=</span><span class="nv">emu</span><span class="w"> </span><span class="o">--</span><span class="nv">disable</span><span class="o">-</span><span class="nv">grub</span><span class="o">-</span><span class="nv">emu</span><span class="o">-</span><span class="nv">sdl</span><span class="w"> </span><span class="nv">CC</span><span class="o">=</span><span class="mh">$AF</span><span class="nv">L_PATH</span><span class="o">/</span><span class="nv">afl</span><span class="o">-</span><span class="nv">cc</span>
...
<span class="nv">checking</span><span class="w"> </span><span class="nv">whether</span><span class="w"> </span><span class="nv">target</span><span class="w"> </span><span class="nv">compiler</span><span class="w"> </span><span class="nv">is</span><span class="w"> </span><span class="nv">working</span>...<span class="w"> </span><span class="nv">no</span>
<span class="nv">configure</span>:<span class="w"> </span><span class="nv">error</span>:<span class="w"> </span><span class="nv">cannot</span><span class="w"> </span><span class="nv">compile</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="nv">the</span><span class="w"> </span><span class="nv">target</span>
</code></pre></div>
<p>It also doesn't work with <code>afl-gcc</code>.</p>
<p>We tried to trick configure:</p>
<div class="highlight"><pre><span></span><code>:::shell
./configure --with-platform=emu --disable-grub-emu-sdl CC=clang CXX=clang++
make CC="$AFL_PATH/afl-cc"
</code></pre></div>
<p>Sadly, things still break:</p>
<div class="highlight"><pre><span></span><code><span class="o">:::</span><span class="n">text</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">bin</span><span class="o">/</span><span class="nl">ld:</span><span class="w"> </span><span class="n">disk</span><span class="p">.</span><span class="k">module</span><span class="o">:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">x20</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">multiple</span><span class="w"> </span><span class="n">definition</span><span class="w"> </span><span class="n">of</span><span class="w"> </span><span class="no">`__afl_global_area_ptr</span><span class="p">';</span><span class="w"> </span><span class="n">kernel</span><span class="p">.</span><span class="nl">exec:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">xe078</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">first</span><span class="w"> </span><span class="n">defined</span><span class="w"> </span><span class="n">here</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">bin</span><span class="o">/</span><span class="nl">ld:</span><span class="w"> </span><span class="n">regexp</span><span class="p">.</span><span class="k">module</span><span class="o">:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">x70</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">multiple</span><span class="w"> </span><span class="n">definition</span><span class="w"> </span><span class="n">of</span><span class="w"> </span><span class="no">`__afl_global_area_ptr</span><span class="p">';</span><span class="w"> </span><span class="n">kernel</span><span class="p">.</span><span class="nl">exec:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">xe078</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">first</span><span class="w"> </span><span class="n">defined</span><span class="w"> </span><span class="n">here</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">bin</span><span class="o">/</span><span class="nl">ld:</span><span class="w"> </span><span class="n">blocklist</span><span class="p">.</span><span class="k">module</span><span class="o">:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">x28</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">multiple</span><span class="w"> </span><span class="n">definition</span><span class="w"> </span><span class="n">of</span><span class="w"> </span><span class="no">`__afl_global_area_ptr</span><span class="p">';</span><span class="w"> </span><span class="n">kernel</span><span class="p">.</span><span class="nl">exec:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">xe078</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">first</span><span class="w"> </span><span class="n">defined</span><span class="w"> </span><span class="n">here</span>
</code></pre></div>
<p>The problem is the module linkage that I talked about in <a href="/blog/2021/03/04/fuzzing-grub-part-1">part 1</a>.
There is a link stage of sorts for the kernel (<code>kernel.exec</code>) and each module
(e.g. <code>disk.module</code>), so some AFL support code gets linked into each of
those. Then there's another link stage for <code>grub-emu</code> itself, which also tries
to bring in the same support code. The linker doesn't like the symbols being in
multiple places, which is fair enough.</p>
<p>There are (at least) 3 ways you could solve this. I'm going to call them the hard way, and the ugly way and the easy way.</p>
<h2>The hard way: messing with makefiles</h2>
<p>We've been looking at fuzzing <code>grub-emu</code>. Building <code>grub-emu</code> links
<code>kernel.exec</code> and almost every <code>.module</code> file that grub produces into the
final binary. Maybe we could avoid our duplicate symbol problems entirely by
changing how we build things?</p>
<p>I didn't do this in my early work because, to be honest, I don't like working
with build systems and I'm not especially good at it. grub's build system is
based on autotools but is even more quirky than usual: rather than just having a
<code>Makefile.am</code>, we have <code>Makefile.core.def</code> which is used along with other things
to generate <code>Makefile.am</code>. It's a pretty cool system for making modules, but
it's not my idea of fun to work with.</p>
<p>But, for the sake of completeness, I tried again.</p>
<p>It gets unpleasant quickly. The generated <code>grub-core/Makefile.core.am</code> adds each module to <code>platform_PROGRAMS</code>, and then each is built with <code>LDFLAGS_MODULE = $(LDFLAGS_PLATFORM) -nostdlib $(TARGET_LDFLAGS_OLDMAGIC) -Wl,-r,-d</code>.</p>
<p>Basically, in the makefile this ends up being (e.g.):</p>
<div class="highlight"><pre><span></span><code><span class="err">:::make</span>
<span class="nf">tar.module$(EXEEXT)</span><span class="o">:</span><span class="w"> </span><span class="k">$(</span><span class="nv">tar_module_OBJECTS</span><span class="k">)</span> <span class="k">$(</span><span class="nv">tar_module_DEPENDENCIES</span><span class="k">)</span> <span class="k">$(</span><span class="nv">EXTRA_tar_module_DEPENDENCIES</span><span class="k">)</span>
<span class="w"> </span>@rm<span class="w"> </span>-f<span class="w"> </span>tar.module<span class="k">$(</span>EXEEXT<span class="k">)</span>
<span class="w"> </span><span class="k">$(</span>AM_V_CCLD<span class="k">)$(</span>tar_module_LINK<span class="k">)</span><span class="w"> </span><span class="k">$(</span>tar_module_OBJECTS<span class="k">)</span><span class="w"> </span><span class="k">$(</span>tar_module_LDADD<span class="k">)</span><span class="w"> </span><span class="k">$(</span>LIBS<span class="k">)</span>
</code></pre></div>
<p>Ideally I don't want them to be linked at all; there's no benefit if
they're just going to be linked again.</p>
<p>You can't just collect the sources and build them into <code>grub-emu</code> - they all
have to built with different <code>CFLAGS</code>! So instead I spent some hours messing
around with the build system. Given some changes to the python script that
converts the <code>Makefile.*.def</code> files into <code>Makefile.am</code> files, plus some other
bits and pieces, we can build <code>grub-emu</code> by linking the object files rather than
the more-processed modules.</p>
<p>The build dies immediately after linking <code>grub-emu</code> in other components, and it
requires a bit of manual intervention to get the right things built in the right
order, but with all of those caveats, it's enough. It works, and you can turn on
things like ASAN, but getting there was hard, unrewarding and unpleasant. Let's
consider alternative ways to solve this problem.</p>
<h2>The ugly way: patching AFL</h2>
<p>What I did when finding the bugs was to observe that we only wanted AFL to link
in its extra instrumentation at certain points of the build process. So I
patched AFL to add an environment variable <code>AFL_DEFER_LIB</code> - which prevented AFL
adding its own instrumentation library when being called as a linker. I combined
this with the older CFG instrumentation, as the PCGUARD instrumentation brought
in a bunch of symbols from LLVM which I didn't want to also figure out how to
guard.</p>
<p>I then wrapped this in a horrifying script that basically built bits and pieces
of grub with the environment variable on or off, in order to at least get the
userspace tools and <code>grub-emu</code> built. Basically it set <code>AFL_DEFER_LIB</code> when
building all the modules and turned it off when building the userspace tools
and <code>grub-emu</code>.</p>
<p>This worked and it's what I used to find most of my bugs. But I'd probably not
recommend it, and I'm not sharing the source: it's extremely fragile and
brittle, the hard way is more generally applicable, and the easy way is nicer.</p>
<h2>The easy way: adjusting linker flags</h2>
<p>After posting part 1 of this series, I had a fascinating twitter DM conversation
with <a href="https://twitter.com/hackerschoice">@hackerschoice</a>, who pointed me to some
new work that had been done in AFL++ between when I started and when I published
part 1.</p>
<p>AFL++ now has the ability to dynamically detect some duplicate symbols, allowing
it to support plugins and modules better. This isn't directly applicable because
we link all the modules in at build time, but in the conversation I was pointed
to a linker flag which instructs the linker to ignore the symbol duplication
rather than error out. This provides a significantly simpler way to instrument
<code>grub-emu</code>, avoiding all the issues I'd previously been fighting so hard to
address.</p>
<p>So, with a modern AFL++, and the patch from <a href="https://github.com/daxtens/grub/tree/fuzzing-pt2">part 1</a>,
you can sort out this entire process like this:</p>
<div class="highlight"><pre><span></span><code>:::shell
./bootstrap
./configure --with-platform=emu CC=clang CXX=clang++ --disable-grub-emu-sdl
make CC=/path/to/afl-clang-fast LDFLAGS="-Wl,--allow-multiple-definition"
</code></pre></div>
<p>Eventually it will error out, but <code>./grub-core/grub-emu</code> should be successfully
built first.</p>
<p>(Why not just build <code>grub-emu</code> directly? It gets built by <code>grub-core/Makefile</code>,
but depends on a bunch of things made by the top-level makefile and doesn't
express its dependencies well. So you can try to build all the things that you
need separately and then <code>cd grub-core; make ...flags... grub-emu</code> if you want -
but it's way more complicated to do it that way!)</p>
<h1>Going extra fast: <code>__AFL_INIT</code></h1>
<p>Now that we can compile with instrumentation, we can use <code>__AFL_INIT</code>. I'll
leave the precise details of how this works to the AFL docs, but in short it
allows us to do a bunch of early setup only once, and just fork the process
after the setup is done.</p>
<p>There's a patch that inserts a call to <code>__AFL_INIT</code> in the <code>grub-emu</code> start path
in <a href="https://github.com/daxtens/grub/tree/fuzzing-pt2">my GitHub repo</a>.</p>
<p>All up, this can lead to a 2x-3x speedup over the figures I saw in <a href="/blog/2021/03/04/fuzzing-grub-part-1">part 1</a>.
In part 1 we saw around 244 executions per second at this point - now we're over
500:</p>
<p><img alt="afl-fuzz fuzzing grub, showing fuzzing happening" src="/images/dja/grub-fuzzing-pt2.png"></p>
<h1>Finding more bugs with sanitisers</h1>
<p>A 'sanitizer' refers to a set of checks inserted by a compiler at build time to
detect various runtime issues that might not cause a crash or otherwise be
detected. A particularly common and useful sanitizer is ASAN, the
<a href="https://clang.llvm.org/docs/AddressSanitizer.html">AddressSanitizer</a>, which
detects out-of-bounds memory accesses, use-after-frees and other assorted memory
bugs. Other sanitisers can check for
<a href="https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html">undefined behaviour</a>,
<a href="https://clang.llvm.org/docs/MemorySanitizer.html">uninitialised memory reads</a>
or even breaches of
<a href="https://releases.llvm.org/12.0.0/tools/clang/docs/ControlFlowIntegrity.html">control flow integrity</a>.</p>
<p>ASAN is particularly popular for fuzzing. In theory, compiling with AFL++ and
LLVM makes it really easy to compile with ASAN. Setting <code>AFL_USE_ASAN=1</code> should
be sufficient.</p>
<p>However, in practice, it's quite fragile for grub. I believe I had it all
working, and then I upgraded my distro, LLVM and AFL++ versions, and everything
stopped working. (It's possible that I hadn't sufficiently cleaned my source
tree and I was still building based on the hard way? Who knows.)</p>
<p>I spent quite a while fighting "truncated relocations". ASAN instrumentation was
bloating the binaries, and the size of all the <code>*.module</code> files was over 512MB,
which I suspect was causing the issues. (Without ASAN, it only comes to 35MB.)</p>
<p>I tried <code>afl-clang-lto</code>: I installed <code>lld</code>, rebuilt AFL++, and managed to
segfault the linker while building grub. So I wrote that off. Changing the
instrumentation type to classic didn't help either.</p>
<p><a href="https://www.technovelty.org/c/relocation-truncated-to-fit-wtf.html">Some googling</a>
suggested GCC's <code>-mmodel</code>, which in Clang seems to be <code>-mcmodel</code>, but
<code>CFLAGS="-mcmodel=large"</code> didn't get me any further either: it's already added
in a few different links.</p>
<p>My default llvm is llvm-12, so I tried building with llvm-9 and llvm-11 in case
that helped. Both built a binary, but it would fail to start:</p>
<div class="highlight"><pre><span></span><code><span class="p">:::</span><span class="n">text</span>
<span class="o">==</span><span class="mi">375638</span><span class="o">==</span><span class="n">AddressSanitizer</span><span class="w"> </span><span class="n">CHECK</span><span class="w"> </span><span class="n">failed</span><span class="p">:</span><span class="w"> </span><span class="o">/</span><span class="n">build</span><span class="o">/</span><span class="n">llvm</span><span class="o">-</span><span class="n">toolchain</span><span class="o">-</span><span class="mi">9</span><span class="o">-</span><span class="mi">8</span><span class="n">fovFY</span><span class="o">/</span><span class="n">llvm</span><span class="o">-</span><span class="n">toolchain</span><span class="o">-</span><span class="mi">9</span><span class="o">-</span><span class="mf">9.0</span><span class="o">.</span><span class="mi">1</span><span class="o">/</span><span class="n">compiler</span><span class="o">-</span><span class="n">rt</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">sanitizer_common</span><span class="o">/</span><span class="n">sanitizer_common_libcdep</span><span class="o">.</span><span class="n">cc</span><span class="p">:</span><span class="mi">23</span><span class="w"> </span><span class="s2">"((SoftRssLimitExceededCallback)) == ((nullptr))"</span><span class="w"> </span><span class="p">(</span><span class="mh">0x423660</span><span class="p">,</span><span class="w"> </span><span class="mh">0x0</span><span class="p">)</span>
</code></pre></div>
<p>The same happens if I build with llvm-12 and <code>afl-clang</code>, the old-style
instrumentation.</p>
<p>I spun up a Ubuntu 20.04 VM and build there with LLVM 10 and the latest stable
AFL++. That didn't work either.</p>
<p>I had much better luck using GCC's and GCC's ASAN implementation, either with
the old-school <code>afl-gcc</code> or the newer GCC plugin-based <code>afl-gcc-fast</code>. (I have
some hypotheses around shared library vs static library ASAN, but having spent
way more work time on this than was reasonable, I was disinclined to debug it
further.) Here's what worked for me:</p>
<div class="highlight"><pre><span></span><code><span class="p">:::</span><span class="n">shell</span>
<span class="o">./</span><span class="n">configure</span><span class="w"> </span><span class="o">--</span><span class="n">with</span><span class="o">-</span><span class="n">platform</span><span class="o">=</span><span class="n">emu</span><span class="w"> </span><span class="o">--</span><span class="n">disable</span><span class="o">-</span><span class="n">grub</span><span class="o">-</span><span class="n">emu</span><span class="o">-</span><span class="n">sdl</span>
<span class="c1"># the ASAN option is required because one of the tools leaks memory and</span>
<span class="c1"># that breaks the generation of documentation.</span>
<span class="c1"># -Wno-nested-extern makes __AFL_INIT work on gcc</span>
<span class="n">ASAN_OPTIONS</span><span class="o">=</span><span class="n">detect_leaks</span><span class="o">=</span><span class="mi">0</span><span class="w"> </span><span class="n">AFL_USE_ASAN</span><span class="o">=</span><span class="mi">1</span><span class="w"> </span><span class="n">make</span><span class="w"> </span><span class="n">CC</span><span class="o">=/</span><span class="n">path</span><span class="o">/</span><span class="n">to</span><span class="o">/</span><span class="n">afl</span><span class="o">-</span><span class="n">gcc</span><span class="o">-</span><span class="n">fast</span><span class="w"> </span><span class="n">LDFLAGS</span><span class="o">=</span><span class="s2">"-Wl,--allow-multiple-definition"</span><span class="w"> </span><span class="n">CFLAGS</span><span class="o">=</span><span class="s2">"-Wno-nested-extern"</span>
</code></pre></div>
<p>GCC doesn't support as many sanitisers as LLVM, but happily it does support
ASAN. AFL++'s GCC plugin mode should get us most of the speed we would get from
LLVM, and indeed the speed - even with ASAN - is quite acceptable.</p>
<p>If you persist, you should be able to find some more bugs: for example there's a
very boring global array out-of-bounds read when parsing config files.</p>
<p>That's all for part 2. In part 3 we'll look at fuzzing filesystems and
more. Hopefully there will be a quicker turnaround between part 2 and part 3
than there was between part 1 and part 2!</p></div>
</article>
<article>
<header>
<h1 class="entry-title">
<a href="https://sthbrx.github.io/blog/2021/03/04/fuzzing-grub-part-1/">Fuzzing grub: part 1</a>
</h1>
<p class="meta">
<time datetime="2021-03-04T17:10:00+11:00" pubdate>Thu 04 March 2021</time> </p>
</header>
<div class="byline_index">
<span class="byline author vcard">
Posted by <span class="fn">
<a href="https://sthbrx.github.io/author/daniel-axtens.html">Daniel Axtens</a>
</span>
</span>
<time datetime="2021-03-04T17:10:00+11:00" pubdate>Thu 04 March 2021</time></div>
<div class="entry-content"><p>Recently a set of 8 vulnerabilities were disclosed for the <a href="https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021">grub bootloader</a>. I
found 2 of them (CVE-2021-20225 and CVE-2021-20233), and contributed a number of
other fixes for crashing bugs which we don't believe are exploitable. I found
them by applying fuzz testing to grub. Here's how.</p>
<p>This is a multi-part series: I think it will end up being 4 posts. I'm hoping to
cover:</p>
<ul>
<li>Part 1 (this post): getting started with fuzzing grub</li>
<li>Part 2: <a href="/blog/2021/06/14/fuzzing-grub-part-2-going-faster/">going faster by doing lots more work</a></li>
<li>Part 3: fuzzing filesystems and more</li>
<li>Part 4: potential next steps and avenues for further work</li>
</ul>
<h1>Fuzz testing</h1>
<p>Let's begin with part one: getting started with fuzzing grub.</p>
<p>One of my all-time favourite techniques for testing programs, especially
programs that handle untrusted input, and especially-especially programs written
in C that parse untrusted input, is fuzz testing. Fuzz testing (or fuzzing) is
the process of repeatedly throwing randomised data at your program under test
and seeing what it does.</p>
<p>(For the secure boot threat model, untrusted input is anything not validated by
a cryptographic signature - so config files are untrusted for our purposes, but
grub modules can only be loaded if they are signed, so they are trusted.)</p>
<p>Fuzzing has a long history and has recently received a new lease on life with
coverage-guided fuzzing tools like <a href="https://lcamtuf.coredump.cx/afl/">AFL</a> and
more recently <a href="https://aflplus.plus/">AFL++</a>.</p>
<h1>Building grub for AFL++</h1>
<p>AFL++ is extremely easy to use ... if your program:</p>
<ol>
<li>is built as a single binary with a regular tool-chain</li>
<li>runs as a regular user-space program on Linux</li>
<li>reads a small input files from disk and then exits</li>
<li>doesn't do anything fancy with threads or signals</li>
</ol>
<p>Beyond that, it gets a bit more complex.</p>
<p>On the face of it, grub fails 3 of these 4 criteria:</p>
<ul>
<li>
<p>grub is a highly modular program: it loads almost all of its functionality as
modules which are linked as separate ELF relocatable files. (Not runnable
programs, but not shared libraries either.)</p>
</li>
<li>
<p>grub usually runs as a bootloader, not as a regular app.</p>
</li>
<li>
<p>grub reads all sorts of things, ranging in size from small files to full
disks. After loading most things, it returns to a command prompt rather than
exiting.</p>
</li>
</ul>
<p>Fortunately, these problems are not insurmountable.</p>
<p>We'll start with the 'running as a bootloader' problem. Here, grub helps us out
a bit, because it provides an 'emulator' target, which runs most of grub
functionality as a userspace program. It doesn't support actually booting
anything (unsurprisingly) but it does support most other modules, including
things like the config file parser.</p>
<p>We can configure grub to build the emulator. We disable the graphical frontend
for now.</p>
<div class="highlight"><pre><span></span><code>:::shell
./bootstrap
./configure --with-platform=emu --disable-grub-emu-sdl
</code></pre></div>
<p>At this point in building a fuzzing target, we'd normally try to configure with
<code>afl-cc</code> to get the instrumentation that makes AFL(++) so powerful. However, the
grub configure script is not a fan:</p>
<div class="highlight"><pre><span></span><code>:::<span class="nv">text</span>
.<span class="o">/</span><span class="nv">configure</span><span class="w"> </span><span class="o">--</span><span class="nv">with</span><span class="o">-</span><span class="nv">platform</span><span class="o">=</span><span class="nv">emu</span><span class="w"> </span><span class="o">--</span><span class="nv">disable</span><span class="o">-</span><span class="nv">grub</span><span class="o">-</span><span class="nv">emu</span><span class="o">-</span><span class="nv">sdl</span><span class="w"> </span><span class="nv">CC</span><span class="o">=</span><span class="mh">$AF</span><span class="nv">L_PATH</span><span class="o">/</span><span class="nv">afl</span><span class="o">-</span><span class="nv">cc</span>
...
<span class="nv">checking</span><span class="w"> </span><span class="nv">whether</span><span class="w"> </span><span class="nv">target</span><span class="w"> </span><span class="nv">compiler</span><span class="w"> </span><span class="nv">is</span><span class="w"> </span><span class="nv">working</span>...<span class="w"> </span><span class="nv">no</span>
<span class="nv">configure</span>:<span class="w"> </span><span class="nv">error</span>:<span class="w"> </span><span class="nv">cannot</span><span class="w"> </span><span class="nv">compile</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="nv">the</span><span class="w"> </span><span class="nv">target</span>
</code></pre></div>
<p>It also doesn't work with <code>afl-gcc</code>.</p>
<p>Hmm, ok, so what if we just... lie a bit?</p>
<div class="highlight"><pre><span></span><code>:::shell
./configure --with-platform=emu --disable-grub-emu-sdl
make CC="$AFL_PATH/afl-gcc"
</code></pre></div>
<p>(Normally I'd use <code>CC=clang</code> and <code>afl-cc</code>, but clang support is slightly broken
upstream at the moment.)</p>
<p>After a small fix for gcc-10 compatibility, we get the userspace tools
(potentially handy!) but a bunch of link errors for <code>grub-emu</code>:</p>
<div class="highlight"><pre><span></span><code><span class="o">:::</span><span class="n">text</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">bin</span><span class="o">/</span><span class="nl">ld:</span><span class="w"> </span><span class="n">disk</span><span class="p">.</span><span class="k">module</span><span class="o">:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">x20</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">multiple</span><span class="w"> </span><span class="n">definition</span><span class="w"> </span><span class="n">of</span><span class="w"> </span><span class="no">`__afl_global_area_ptr</span><span class="p">';</span><span class="w"> </span><span class="n">kernel</span><span class="p">.</span><span class="nl">exec:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">xe078</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">first</span><span class="w"> </span><span class="n">defined</span><span class="w"> </span><span class="n">here</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">bin</span><span class="o">/</span><span class="nl">ld:</span><span class="w"> </span><span class="n">regexp</span><span class="p">.</span><span class="k">module</span><span class="o">:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">x70</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">multiple</span><span class="w"> </span><span class="n">definition</span><span class="w"> </span><span class="n">of</span><span class="w"> </span><span class="no">`__afl_global_area_ptr</span><span class="p">';</span><span class="w"> </span><span class="n">kernel</span><span class="p">.</span><span class="nl">exec:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">xe078</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">first</span><span class="w"> </span><span class="n">defined</span><span class="w"> </span><span class="n">here</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">bin</span><span class="o">/</span><span class="nl">ld:</span><span class="w"> </span><span class="n">blocklist</span><span class="p">.</span><span class="k">module</span><span class="o">:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">x28</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">multiple</span><span class="w"> </span><span class="n">definition</span><span class="w"> </span><span class="n">of</span><span class="w"> </span><span class="no">`__afl_global_area_ptr</span><span class="p">';</span><span class="w"> </span><span class="n">kernel</span><span class="p">.</span><span class="nl">exec:</span><span class="p">(.</span><span class="n">bss</span><span class="o">+</span><span class="mh">0</span><span class="n">xe078</span><span class="p">)</span><span class="o">:</span><span class="w"> </span><span class="n">first</span><span class="w"> </span><span class="n">defined</span><span class="w"> </span><span class="n">here</span>
</code></pre></div>
<p>The problem is the module linkage that I talked about earlier: because there is
a link stage of sorts for each module, some AFL support code gets linked in to
both the grub kernel (<code>kernel.exec</code>) and each module (here <code>disk.module</code>,
<code>regexp.module</code>, ...). The linker doesn't like it being in both, which is fair
enough.</p>
<p>To get started, let's instead take advantage of the smarts of AFL++ using Qemu
mode instead. This builds a specially instrumented qemu user-mode emulator
that's capable of doing coverage-guided fuzzing on uninstrumented binaries at
the cost of a significant performance penalty.</p>
<div class="highlight"><pre><span></span><code>:::shell
make clean
make
</code></pre></div>
<p>Now we have a grub-emu binary. If you run it directly, you'll pick up your
system boot configuration, but the <code>-d</code> option can point it to a directory of
your choosing. Let's set up one for fuzzing:</p>
<div class="highlight"><pre><span></span><code>:::shell
mkdir stage
echo "echo Hello sthbrx readers" > stage/grub.cfg
cd stage
../grub-core/grub-emu -d .
</code></pre></div>
<p>You probably won't see the message because the screen gets blanked at the end of
running the config file, but if you pipe it through <code>less</code> or something you'll
see it.</p>
<h1>Running the fuzzer</h1>
<p>So, that seems to work - let's create a test input and try fuzzing:</p>
<div class="highlight"><pre><span></span><code>:::<span class="nv">shell</span>
<span class="nv">cd</span><span class="w"> </span>..
<span class="nv">mkdir</span><span class="w"> </span><span class="nv">in</span>
<span class="nv">echo</span><span class="w"> </span><span class="s2">"echo hi"</span><span class="w"> </span><span class="o">></span><span class="w"> </span><span class="nv">in</span><span class="o">/</span><span class="nv">echo</span><span class="o">-</span><span class="nv">hi</span>
<span class="nv">cd</span><span class="w"> </span><span class="nv">stage</span>
#<span class="w"> </span><span class="o">-</span><span class="nv">Q</span><span class="w"> </span><span class="nv">qemu</span><span class="w"> </span><span class="nv">mode</span>
#<span class="w"> </span><span class="o">-</span><span class="nv">M</span><span class="w"> </span><span class="nv">main</span><span class="w"> </span><span class="nv">fuzzer</span>
#<span class="w"> </span><span class="o">-</span><span class="nv">d</span><span class="w"> </span><span class="nv">don</span><span class="err">'t do deterministic steps (too slow for a text format)</span>
<span class="err"># -f create file grub.cfg</span>
<span class="err">$AFL_PATH/afl-fuzz -Q -i ../in -o ../out -M main -d -- ../grub-core/grub-emu -d .</span>
</code></pre></div>
<p>Sadly:</p>
<div class="highlight"><pre><span></span><code><span class="c">:::text</span>
<span class="k">[</span><span class="nb">-</span><span class="k">]</span><span class="c"> The program took more than 1000 ms to process one of the initial test cases</span><span class="nt">.</span>
<span class="c"> This is bad news; raising the limit with the </span><span class="nb">-</span><span class="c">t option is possible</span><span class="nt">,</span><span class="c"> but</span>
<span class="c"> will probably make the fuzzing process extremely slow</span><span class="nt">.</span>
<span class="c"> If this test case is just a fluke</span><span class="nt">,</span><span class="c"> the other option is to just avoid it</span>
<span class="c"> altogether</span><span class="nt">,</span><span class="c"> and find one that is less of a CPU hog</span><span class="nt">.</span>
<span class="k">[</span><span class="nb">-</span><span class="k">]</span><span class="c"> PROGRAM ABORT : Test case 'id:000000</span><span class="nt">,</span><span class="c">time:0</span><span class="nt">,</span><span class="c">orig:echo</span><span class="nb">-</span><span class="c">hi' results in a timeout</span>
<span class="c"> Location : perform_dry_run()</span><span class="nt">,</span><span class="c"> src/afl</span><span class="nb">-</span><span class="c">fuzz</span><span class="nb">-</span><span class="c">init</span><span class="nt">.</span><span class="c">c:866</span>
</code></pre></div>
<p>What we're seeing here (and indeed what you can observe if you run <code>grub-emu</code>
directly) is that <code>grub-emu</code> isn't exiting when it's done. It's waiting for more
input, and will keep waiting for input until it's killed by <code>afl-fuzz</code>.</p>
<p>We need to patch grub to sort that out. It's on <a href="https://github.com/daxtens/grub/commit/ad2e84224e674eb1f9dcd8efc3d8efe78ed62bec">my GitHub</a>.</p>
<p>Apply that, rebuild with <code>FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION</code>, and voila:</p>
<div class="highlight"><pre><span></span><code>:::shell
cd ..
make CFLAGS="-DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION"
cd stage
$AFL_PATH/afl-fuzz -Q -i ../in -o ../out -M main -d -f grub.cfg -- ../grub-core/grub-emu -d .
</code></pre></div>
<p>And fuzzing is happening!</p>
<p><img alt="afl-fuzz fuzzing grub, showing fuzzing happening" src="/images/dja/grub-fuzzing-pt1.png"></p>
<p>This is enough to find some of the (now-fixed) bugs in the grub config file
parsing!</p>
<h1>Fuzzing beyond the config file</h1>
<p>You can also extend this to fuzzing other things that don't require the
graphical UI, such as grub's transparent decompression support:</p>
<div class="highlight"><pre><span></span><code>:::shell
cd ..
rm -rf in out stage
mkdir in stage
echo hi > in/hi
gzip in/hi
cd stage
echo "cat thefile" > grub.cfg
$AFL_PATH/afl-fuzz -Q -i ../in -o ../out -M main -f thefile -- ../grub-core/grub-emu -d .
</code></pre></div>
<p>You should be able to find a hang pretty quickly with this, an as-yet-unfixed
bug where grub will print output forever from a corrupt file: (your mileage may
vary, as will the paths.)</p>
<div class="highlight"><pre><span></span><code><span class="o">::</span><span class="p">:</span><span class="nx">shell</span>
<span class="nx">cp</span><span class="w"> </span><span class="p">..</span><span class="o">/</span><span class="nx">out</span><span class="o">/</span><span class="nx">main</span><span class="o">/</span><span class="nx">hangs</span><span class="o">/</span><span class="nx">id</span><span class="p">:</span><span class="mi">000000</span><span class="p">,</span><span class="nx">src</span><span class="p">:</span><span class="mi">000000</span><span class="p">,</span><span class="nx">time</span><span class="p">:</span><span class="mi">43383</span><span class="p">,</span><span class="nx">op</span><span class="p">:</span><span class="nx">havoc</span><span class="p">,</span><span class="nx">rep</span><span class="p">:</span><span class="mi">16</span><span class="w"> </span><span class="nx">thefile</span>
<span class="p">..</span><span class="o">/</span><span class="nx">grub</span><span class="o">-</span><span class="nx">core</span><span class="o">/</span><span class="nx">grub</span><span class="o">-</span><span class="nx">emu</span><span class="w"> </span><span class="o">-</span><span class="nx">d</span><span class="w"> </span><span class="p">.</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="nx">less</span><span class="w"> </span><span class="err">#</span><span class="w"> </span><span class="k">observe</span><span class="w"> </span><span class="nx">this</span><span class="w"> </span><span class="nx">going</span><span class="w"> </span><span class="nx">on</span><span class="w"> </span><span class="nx">forever</span>
</code></pre></div>
<p><code>zcat</code>, on the other hand, reports it as simply corrupt:</p>
<div class="highlight"><pre><span></span><code>:::text
$ zcat thefile
gzip: thefile: invalid compressed data--format violated
</code></pre></div>
<p>(Feel free to fix that and send a patch to the list!)</p>
<p>That wraps up part 1. Eventually I'll be back with part 2, where I explain the
hoops to jump through to go faster with the <code>afl-cc</code> instrumentation.</p></div>
</article>
<article>
<header>
<h1 class="entry-title">
<a href="https://sthbrx.github.io/blog/2020/01/22/linuxconfau-2020-recap/">linux.conf.au 2020 recap</a>
</h1>
<p class="meta">
<time datetime="2020-01-22T16:00:00+11:00" pubdate>Wed 22 January 2020</time> </p>
</header>
<div class="byline_index">
<span class="byline author vcard">
Posted by <span class="fn">
<a href="https://sthbrx.github.io/author/andrew-donnellan.html">Andrew Donnellan</a>
</span>
</span>
<time datetime="2020-01-22T16:00:00+11:00" pubdate>Wed 22 January 2020</time></div>
<div class="entry-content"><p>It's that time of year again. Most of OzLabs headed up to the Gold Coast for linux.conf.au 2020.</p>
<p>linux.conf.au is one of the longest-running community-led Linux and Free Software events in the world, and attracts a crowd from Australia, New Zealand and much further afield. OzLabbers have been involved in LCA since the very beginning and this year was no exception with myself running the Kernel Miniconf and several others speaking.</p>
<p>The list below contains some of our highlights that we think you should check out. This is just a few of the talks that we managed to make it to - there's plenty more worthwhile stuff on the <a href="https://www.youtube.com/user/linuxconfau2019/featured">linux.conf.au YouTube channel</a>.</p>
<p>We'll see you all at LCA2021 right here in Canberra...</p>
<h1>Keynotes</h1>
<p>A couple of the keynotes really stood out:</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=Yv4tI6939q0">Sean Brady - Drop Your Tools - Does Expertise have a Dark Side?</a></li>
</ul>
<p>Sean is a forensic structural engineer who shows us a variety of examples, from structural collapses and firefighting disasters, where trained professionals were blinded by their expertise and couldn't bring themselves to do things that were obvious.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=xfpy5c3thQo">Vanessa Teague - Who cares about Democracy?</a></li>
</ul>
<p>There's nothing quite like cryptography proofs presented to a keynote audience at 9:30 in the morning. Vanessa goes over the issues with electronic voting systems in Australia, and especially internet voting as used in NSW, including flaws in their implementation of cryptographic algorithms. There continues to be no good way to do internet voting, but with developments in methodologies like risk-limiting audits there may be reasonably safe ways to do in-person electronic voting.</p>
<h1>OpenPOWER</h1>
<p>There was an OpenISA miniconf, co-organised by none other than Hugh Blemings of the OpenPOWER Foundation.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=RU6RPYAqFzE">Michael Neuling / Anton Blanchard - Power OpenISA and Microwatt Introduction</a></li>
</ul>
<p>Anton (on Mikey's behalf) introduces the Power OpenISA and the Microwatt FPGA core which has been released to go with it.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=g3slH03MCmo">Anton Blanchard - Build your own Open Hardware CPU in 25 minutes or less</a></li>
</ul>
<p>Anton live demos Microwatt in simulation, and also tries to synthesise it for his FPGA but runs out of time...</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=JkDx_y0onSk">Paul Mackerras - Microwatt Microarchitecture</a></li>
</ul>
<p>Paul presents an in-depth overview of the design of the Microwatt core.</p>
<h1>Kernel</h1>
<p>There were quite a few kernel talks, both in the <a href="http://lca-kernel.ozlabs.org">Kernel Miniconf</a> and throughout the main conference. These are just some of them:</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=ggD-eb3yPVs">Aleksa Sarai - Designing Extensible Syscalls</a></li>
</ul>
<p>There's been many cases where we've introduced a syscall only to find out later on that we need to add some new parameters - how do we make our syscalls extensible so we can add new parameters later on without needing to define a whole new syscall, while maintaining both forward and backward compatibility? It turns out it's pretty simple but needs a few more kernel helpers.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=heib48KG-YQ">Russell Currey - Kernel hacking like it's 2020</a></li>
</ul>
<p>There are a bunch of tools out there which you can use to make your kernel hacking experience much more pleasant. You should use them.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=tGseJW_uBB8">Aleksa Sarai - Securing Container Runtimes - How Hard Can It Be?</a></li>
</ul>
<p>Among other security issues with container runtimes, using procfs to setup security controls during the startup of a container is fraught with hilarious problems, because procfs and the Linux filesystem API aren't really designed to do this safely, and also have a bunch of amusing bugs.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=0Bj6W7qrOOI">Kees Cook - Control Flow Integrity in the Linux Kernel</a></li>
</ul>
<p>Control Flow Integrity is a technique for restricting exploit techniques that hijack a program's control flow (e.g. by overwriting a return address on the stack (ROP), or overwriting a function pointer that's used in an indirect jump). Kees goes through the current state of CFI supporting features in hardware and what is currently available to enable CFI in the kernel.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=p5u-vbwu3Fs">Matthew Wilcox - Large Pages in Linux</a></li>
</ul>
<p>Linux has supported huge pages for many years, which has significantly improved CPU performance. However, the huge page mechanism was driven by hardware advancements and is somewhat inflexible, and it's just as important to consider software overhead. Matthew has been working on supporting more flexible "large pages" in the page cache to do just that.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=9Fzd6MapG3Y">Russell Currey - The magical fantasy land of Linux kernel testing</a></li>
</ul>
<p>Spoiler: the magical fantasy land is a trap.</p>
<h1>Community</h1>
<p>Lots of community and ethics discussion this year - one talk which stood out to me:</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=n55WClalwHo">Bradley M. Kuhn / Karen Sandler - Open Source Won, but Software Freedom Hasn't Yet: A Guide & Commisseration Session for FOSS activists</a></li>
</ul>
<p>Bradley and Karen argue that while open source has "won", software freedom has regressed in recent years, and present their vision for what modern, pragmatic Free Software activism should look like.</p>
<h1>Other</h1>
<p>Among the variety of other technical talks at LCA...</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=L2P501Iy6J8">Matthew Treinish - Building a Compiler for Quantum Computers</a></li>
</ul>
<p>Quantum compilers are not really like regular classical compilers (indeed, they're really closer to FPGA synthesis tools). Matthew talks through how quantum compilers map a program on to IBM's quantum hardware and the types of optimisations they apply.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=Dk6ZuydQt9I">Fraser Tweedale - Clevis and Tang: securing your secrets at rest</a></li>
</ul>
<p>Clevis and Tang provide an implementation of "network bound encryption", allowing you to magically decrypt your secrets when you are on a secure network with access to the appropriate Tang servers. This talk outlines use cases and provides a demonstration.</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=uBBaVtHkiOI">Christoph Lameter - How to capture 100G Ethernet traffic at wire speed to local disk</a></li>
</ul>
<p>Christoph discusses how to deal with the hardware and software limitations that make it difficult to capture traffic at wire speed on fast fibre networks.</p></div>
</article>
<div class="pagination">
<a class="prev" href="https://sthbrx.github.io/index3.html">← Older</a>
<a class="next" href="https://sthbrx.github.io/index.html">Newer →</a>
<br />
</div></div>
<aside class="sidebar">
<section>
<h1>Recent Posts</h1>
<ul id="recent_posts">
<li class="post">
<a href="https://sthbrx.github.io/blog/2023/08/07/going-out-on-a-limb-efficient-elliptic-curve-arithmetic-in-openssl/">Going out on a Limb: Efficient Elliptic Curve Arithmetic in OpenSSL</a>
</li>
<li class="post">
<a href="https://sthbrx.github.io/blog/2023/08/04/quirks-of-parsing-ssh-configs/">Quirks of parsing SSH configs</a>
</li>
<li class="post">
<a href="https://sthbrx.github.io/blog/2023/04/05/detecting-rootless-docker/">Detecting rootless Docker</a>
</li>
<li class="post">
<a href="https://sthbrx.github.io/blog/2023/04/04/dumb-bugs-the-pci-device-that-wasnt/">Dumb bugs: the PCI device that wasn't</a>
</li>
<li class="post">
<a href="https://sthbrx.github.io/blog/2023/03/24/dumb-bugs-when-a-date-breaks-booting-the-kernel/">Dumb bugs: When a date breaks booting the kernel</a>
</li>
</ul>
</section>
<section>
<h1>Categories</h1>
<ul id="recent_posts">
<li><a href="https://sthbrx.github.io/category/cryptography.html">Cryptography</a></li>
<li><a href="https://sthbrx.github.io/category/development.html">Development</a></li>
<li><a href="https://sthbrx.github.io/category/education.html">Education</a></li>
<li><a href="https://sthbrx.github.io/category/openpower.html">OpenPOWER</a></li>
<li><a href="https://sthbrx.github.io/category/performance.html">Performance</a></li>
<li><a href="https://sthbrx.github.io/category/petitboot.html">Petitboot</a></li>
<li><a href="https://sthbrx.github.io/category/snowpatch.html">snowpatch</a></li>
<li><a href="https://sthbrx.github.io/category/virtualisation-and-emulation.html">Virtualisation and Emulation</a></li>
</ul>
</section>
<section>
<h1>Tags</h1>
<a href="https://sthbrx.github.io/tag/ssh.html">ssh</a>, <a href="https://sthbrx.github.io/tag/docker.html">Docker</a>, <a href="https://sthbrx.github.io/tag/syzkaller.html">syzkaller</a>, <a href="https://sthbrx.github.io/tag/linux.html">linux</a>, <a href="https://sthbrx.github.io/tag/power8.html">power8</a>, <a href="https://sthbrx.github.io/tag/distro.html">distro</a>, <a href="https://sthbrx.github.io/tag/kernel.html">kernel</a>, <a href="https://sthbrx.github.io/tag/hardening.html">hardening</a>, <a href="https://sthbrx.github.io/tag/testing.html">testing</a>, <a href="https://sthbrx.github.io/tag/conferences.html">conferences</a>, <a href="https://sthbrx.github.io/tag/instruction-set-architecture.html">Instruction Set Architecture</a>, <a href="https://sthbrx.github.io/tag/openpower.html">openpower</a>, <a href="https://sthbrx.github.io/tag/firmware.html">firmware</a>, <a href="https://sthbrx.github.io/tag/goodposts.html">goodposts</a>, <a href="https://sthbrx.github.io/tag/realcontent.html">realcontent</a>, <a href="https://sthbrx.github.io/tag/madposting.html">madposting</a>, <a href="https://sthbrx.github.io/tag/op-test.html">op-test</a>, <a href="https://sthbrx.github.io/tag/qemu.html">qemu</a>, <a href="https://sthbrx.github.io/tag/pci.html">pci</a>, <a href="https://sthbrx.github.io/tag/sparseposting.html">sparseposting</a>, <a href="https://sthbrx.github.io/tag/petitboot.html">petitboot</a>, <a href="https://sthbrx.github.io/tag/security.html">security</a>, <a href="https://sthbrx.github.io/tag/vscode.html">vscode</a>, <a href="https://sthbrx.github.io/tag/code.html">code</a>, <a href="https://sthbrx.github.io/tag/openbmc.html">openbmc</a>, <a href="https://sthbrx.github.io/tag/ipmi.html">ipmi</a>, <a href="https://sthbrx.github.io/tag/opencapi.html">opencapi</a>, <a href="https://sthbrx.github.io/tag/openpower-summit.html">openpower summit</a>, <a href="https://sthbrx.github.io/tag/easyposts.html">easyposts</a>, <a href="https://sthbrx.github.io/tag/linuxboot.html">linuxboot</a>, <a href="https://sthbrx.github.io/tag/google.html">google</a>, <a href="https://sthbrx.github.io/tag/intel.html">intel</a>, <a href="https://sthbrx.github.io/tag/osfc.html">osfc</a>, <a href="https://sthbrx.github.io/tag/shortposts.html">shortposts</a>, <a href="https://sthbrx.github.io/tag/facebook.html">facebook</a>, <a href="https://sthbrx.github.io/tag/performance.html">performance</a>, <a href="https://sthbrx.github.io/tag/phoronix.html">phoronix</a>, <a href="https://sthbrx.github.io/tag/benchmarks.html">benchmarks</a>, <a href="https://sthbrx.github.io/tag/stupid-ideas.html">stupid ideas</a>, <a href="https://sthbrx.github.io/tag/network.html">network</a>, <a href="https://sthbrx.github.io/tag/power.html">power</a>, <a href="https://sthbrx.github.io/tag/xdp.html">xdp</a>, <a href="https://sthbrx.github.io/tag/networking.html">networking</a>, <a href="https://sthbrx.github.io/tag/remoteposts.html">remoteposts</a>, <a href="https://sthbrx.github.io/tag/ceph.html">ceph</a>, <a href="https://sthbrx.github.io/tag/raid.html">raid</a>, <a href="https://sthbrx.github.io/tag/storage.html">storage</a>, <a href="https://sthbrx.github.io/tag/erasure.html">erasure</a>, <a href="https://sthbrx.github.io/tag/lustre.html">lustre</a>, <a href="https://sthbrx.github.io/tag/hpc.html">hpc</a>, <a href="https://sthbrx.github.io/tag/nvlink.html">nvlink</a>, <a href="https://sthbrx.github.io/tag/namd.html">namd</a>, <a href="https://sthbrx.github.io/tag/cuda.html">cuda</a>, <a href="https://sthbrx.github.io/tag/gpu.html">gpu</a>, <a href="https://sthbrx.github.io/tag/minsky.html">minsky</a>, <a href="https://sthbrx.github.io/tag/s822lc-for-hpc.html">S822LC for hpc</a>, <a href="https://sthbrx.github.io/tag/debug.html">debug</a>, <a href="https://sthbrx.github.io/tag/virtualisation.html">virtualisation</a>, <a href="https://sthbrx.github.io/tag/dmesg.html">dmesg</a>, <a href="https://sthbrx.github.io/tag/printk.html">printk</a>, <a href="https://sthbrx.github.io/tag/boot.html">boot</a>, <a href="https://sthbrx.github.io/tag/early.html">early</a>, <a href="https://sthbrx.github.io/tag/error.html">error</a>, <a href="https://sthbrx.github.io/tag/centos.html">centos</a>, <a href="https://sthbrx.github.io/tag/centos7.html">centos7</a>, <a href="https://sthbrx.github.io/tag/p8.html">p8</a>, <a href="https://sthbrx.github.io/tag/bmc.html">bmc</a>, <a href="https://sthbrx.github.io/tag/rhel.html">RHEL</a>, <a href="https://sthbrx.github.io/tag/skiroot.html">skiroot</a>, <a href="https://sthbrx.github.io/tag/devmapper.html">devmapper</a>, <a href="https://sthbrx.github.io/tag/lvm.html">lvm</a>, <a href="https://sthbrx.github.io/tag/cgroups.html">cgroups</a>, <a href="https://sthbrx.github.io/tag/numa.html">numa</a>, <a href="https://sthbrx.github.io/tag/development.html">Development</a>, <a href="https://sthbrx.github.io/tag/netboot.html">netboot</a>, <a href="https://sthbrx.github.io/tag/pxe.html">pxe</a>, <a href="https://sthbrx.github.io/tag/education.html">Education</a>, <a href="https://sthbrx.github.io/tag/work-experience.html">work experience</a>, <a href="https://sthbrx.github.io/tag/asm.html">asm</a>, <a href="https://sthbrx.github.io/tag/vdso.html">vdso</a>, <a href="https://sthbrx.github.io/tag/snowpatch.html">snowpatch</a>, <a href="https://sthbrx.github.io/tag/tools.html">tools</a>, <a href="https://sthbrx.github.io/tag/intern.html">intern</a>, <a href="https://sthbrx.github.io/tag/srop.html">SROP</a>, <a href="https://sthbrx.github.io/tag/mitigation.html">mitigation</a>, <a href="https://sthbrx.github.io/tag/double.html">double</a>, <a href="https://sthbrx.github.io/tag/float.html">float</a>, <a href="https://sthbrx.github.io/tag/hex.html">hex</a>, <a href="https://sthbrx.github.io/tag/debugging.html">debugging</a>, <a href="https://sthbrx.github.io/tag/skiboot.html">skiboot</a>, <a href="https://sthbrx.github.io/tag/opal.html">OPAL</a>, <a href="https://sthbrx.github.io/tag/fsp.html">FSP</a>, <a href="https://sthbrx.github.io/tag/patches.html">patches</a>, <a href="https://sthbrx.github.io/tag/based16.html">based16</a>, <a href="https://sthbrx.github.io/tag/linux-gods.html">Linux Gods</a>, <a href="https://sthbrx.github.io/tag/ozlabs.html">Ozlabs</a>, <a href="https://sthbrx.github.io/tag/offtopic.html">offtopic</a>, <a href="https://sthbrx.github.io/tag/autoboot.html">autoboot</a>, <a href="https://sthbrx.github.io/tag/kexec.html">kexec</a>, <a href="https://sthbrx.github.io/tag/aufs.html">aufs</a>, <a href="https://sthbrx.github.io/tag/overlay.html">overlay</a>, <a href="https://sthbrx.github.io/tag/php.html">php</a>, <a href="https://sthbrx.github.io/tag/capi.html">capi</a> </section>
<section>
<h1><a href="https://sthbrx.github.io/authors.html">Authors</a></h1>
<ul id="authors_list">
<li><a href="https://sthbrx.github.io/author/alastair-dsilva.html">Alastair D'Silva</a></li>
<li><a href="https://sthbrx.github.io/author/andrew-donnellan.html">Andrew Donnellan</a></li>
<li><a href="https://sthbrx.github.io/author/anton-blanchard.html">Anton Blanchard</a></li>
<li><a href="https://sthbrx.github.io/author/benjamin-gray.html">Benjamin Gray</a></li>
<li><a href="https://sthbrx.github.io/author/callum-scarvell.html">Callum Scarvell</a></li>
<li><a href="https://sthbrx.github.io/author/cyril-bur.html">Cyril Bur</a></li>
<li><a href="https://sthbrx.github.io/author/daniel-axtens.html">Daniel Axtens</a></li>
<li><a href="https://sthbrx.github.io/author/daniel-black.html">Daniel Black</a></li>
<li><a href="https://sthbrx.github.io/author/joel-stanley.html">Joel Stanley</a></li>
<li><a href="https://sthbrx.github.io/author/nick-piggin.html">Nick Piggin</a></li>
<li><a href="https://sthbrx.github.io/author/rashmica-gupta.html">Rashmica Gupta</a></li>
<li><a href="https://sthbrx.github.io/author/rohan-mclure.html">Rohan McLure</a></li>
<li><a href="https://sthbrx.github.io/author/russell-currey.html">Russell Currey</a></li>
<li><a href="https://sthbrx.github.io/author/samuel-mendoza-jonas.html">Samuel Mendoza-Jonas</a></li>
<li><a href="https://sthbrx.github.io/author/suraj-jitindar-singh.html">Suraj Jitindar Singh</a></li>
</ul>
</section>
<section>
<h1>Social</h1>
<ul>
<li><a href="https://sthbrx.github.io/rss.xml" type="application/rss+xml" rel="alternate">RSS</a></li>
<li><a href="https://github.com/sthbrx/" target="_blank">GitHub</a></li>
<li><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_blank">linuxppc mailing list</a></li>
<li><a href="https://lists.ozlabs.org/listinfo/skiboot" target="_blank">Skiboot mailing list</a></li>
</ul>
</section>
<section>
<h1>Blogroll</h1>
<ul>
<li><a href="http://ozlabs.org" target="_blank">OzLabs</a></li>
</ul>
</section>
<section>
<h1>Disclaimer</h1>
<div>
This blog represents the views of the individual authors, and doesn't necessarily represent IBM's positions, strategies or opinions. </div>
</section>
</aside> </div>
</div>
<footer role="contentinfo"><p>
Copyright © 2015–2023 OzLabs —
<span class="credit">Powered by <a href="http://getpelican.com">Pelican</a></span>
</p></footer>
</body>
</html>