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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
Status Report//EN"
"http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
<!-- $FreeBSD$ -->
<!-- This file was generated with https://github.com/trasz/md2docbook -->
<!--
Variables to replace:
%%START%% - report month start
%%STOP%% - report month end
%%YEAR%% - report year
%%NUM%% - report issue (first, second, third, fourth)
%%STARTNEXT%% - report month start
%%STOPNEXT%% - report month end
%%YEARNEXT%% - next report due year (if different than %%YEAR%%)
%%DUENEXT%% - next report due date (i.e., June 6)
-->
<report>
<date>
<month>January-March</month>
<year>2019</year>
</date>
<section>
<title>Introduction</title>
<p>As spring leads into summer, we reflect back on what the
FreeBSD project has accomplished in the first quarter of 2019.
Events included FOSDEM and AsiaBSDCon, the FreeBSD Journal
is now free to everyone, ASLR is available in -CURRENT and KPTI
can be controlled per-process. The run up to 11.3-RELEASE
has begun, and a team is applying syzkaller guided fuzzing
to the kernel, plus so much more. Catch up on many new and
ongoing efforts throughout the project, and find where you can
pitch in.</p>
</section>
<category>
<name>team</name>
<description>&os; Team Reports</description>
<p>Entries from the various official and semi-official teams,
as found in the <a href="&enbase;/administration.html">Administration
Page</a>.</p>
</category>
<category>
<name>proj</name>
<description>Projects</description>
<p>Projects that span multiple categories, from the kernel and userspace
to the Ports Collection or external projects.</p>
</category>
<category>
<name>arch</name>
<description>Architectures</description>
<p>Updating platform-specific features and bringing in support
for new hardware platforms.</p>.
</category>
<category>
<name>ports</name>
<description>Ports</description>
<p>Changes affecting the Ports Collection, whether sweeping
changes that touch most of the tree, or individual ports
themselves.</p>
</category>
<category>
<name>third</name>
<description>Third-Party Projects</description>
<p>Many projects build upon &os; or incorporate components of
&os; into their project. As these projects may be of interest
to the broader &os; community, we sometimes include brief
updates submitted by these projects in our quarterly report.
The &os; project makes no representation as to the accuracy or
veracity of any claims in these submissions.</p>
</category>
<project cat='team'>
<title>FreeBSD Release Engineering Team</title>
<contact>
<person>
<name>FreeBSD Release Engineering Team</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://www.freebsd.org/releases/11.3R/schedule.html">FreeBSD 11.3-RELEASE schedule</url>
<url href="https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/">FreeBSD development snapshots</url>
</links>
<body>
<p>The FreeBSD Release Engineering Team is responsible for
setting and
publishing release schedules for official project releases
of
FreeBSD, announcing code freezes and maintaining the
respective
branches, among other things.</p>
<p>During the first quarter of 2019, the FreeBSD Release
Engineering team
published the initial schedule for the upcoming the
11.3-RELEASE.</p>
<p>FreeBSD 11.3-RELEASE will be the fourth release from the
<tt>stable/11</tt>
branch, building on the stability and reliability of
11.2-RELEASE.
FreeBSD 11.3-RELEASE is currently targed for release in
early July, 2019.</p>
<p>Additionally throughout the quarter, several development
snapshots builds
were released for the <tt>head</tt>, <tt>stable/12</tt>,
and <tt>stable/11</tt> branches.</p>
<p>Much of this work was sponsored by the FreeBSD Foundation.</p>
</body>
</project>
<project cat='team'>
<title>Ports Collection</title>
<contact>
<person>
<name>René Ladan</name>
<email>portmgr-secretary@FreeBSD.org</email>
</person>
<person>
<name>FreeBSD Ports Management Team</name>
<email>portmgr@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://www.FreeBSD.org/ports/">About FreeBSD Ports</url>
<url href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">Contributing to Ports</url>
<url href="http://portsmon.freebsd.org/index.html">FreeBSD Ports Monitoring</url>
<url href="https://www.freebsd.org/portmgr/index.html">Ports Management Team">Ports Management Team</url>
</links>
<body>
<p>As always, below is a summary of what happened in the
Ports Tree during the
last quarter.</p>
<p>During 2019q1, the number of ports dropped slightly to
just over 32,500. At
the end of the quarter, we had 2092 open port PRs. The
last quarter saw 8205
commits from 167 committers. So more PRs were closed and
more commits were
made than in 2018q4.</p>
<p>During the last quarter, we welcomed Kai Knoblich (kai@)
and said goodbye to
Matthew Rezny (rezny@).</p>
<p>On the infrastructure side, two new USES were introduced
(azurepy and sdl) and
USES=gecko was removed. The default versions of Lazarus
and LLVM were bumped
to 2.0.0 and 8.0 respectively. Some big port frameworks
that were end-of-life
were removed: PHP 5.6, Postgresql 9.3, Qt4, WebKit-Gtk and
XPI. Firefox was
updated to 66.0.2, Firefox-ESR to 60.6.1, and Chromium was
updated to
72.0.3626.121.</p>
<p>During the last quarter, antoine@ ran 30 exp-runs for
package updates, moving
from GNU ld to LLVM ld, and switching clang to DWARF4.</p>
</body>
</project>
<project cat='team'>
<title>FreeBSD Core Team</title>
<contact>
<person>
<name>FreeBSD Core Team</name>
<email>core@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The FreeBSD Core Team is the governing body of FreeBSD.</p>
<p>Core initiated a <tt>Release Engineering Charter
Modernization</tt> working
group. The purpose of the working group is to present (to
Core) a
modernized version of the <tt>Release Engineering
Charter</tt> and a first
version of a new <tt>Release Engineering Team Operations
Plan</tt>. The
group hopes to complete its goals and dissolve by
2019-06-30.</p>
<p>The Core Team invites all members of the FreeBSD community
to
complete the <tt>2019 FreeBSD Community Survey</tt>.</p>
<p>https://www.research.net/r/freebsd2019</p>
<p>The purpose of the survey is to collect quantitative data
from the
public in order to help guide the project's priorities and
efforts.
It will remain open for 17 days and close at midnight May
13 UTC
(Monday 5pm PDT).
(Editor's note: Survey has finished)</p>
<p>Core voted to approve source commit bits for Johannes
Lundberg
(johalun@) and Mitchell Horne (mhorne@) and associate
membership
for Philip Jocks. Core also voted to revoke Michael
Dexter's
documentation bit.</p>
<p>After a long lapse of not closing idle source commit bits,
core has
taken in the commit bit for these developers. We thank
each for
contributing to the project as a source committer.</p>
<ul>
<li>Alfred Perlstein (alfred@)</li>
<li>Eric Badger (badger@)</li>
<li>Daniel Eischen (deischen@)</li>
<li>Ermal Luçi (eri@)</li>
<li>Tony Finch (fanf@)</li>
<li>Justin T. Gibbs (gibbs@)</li>
<li>Imre Vadász (ivadasz@)</li>
<li>Julio Merino (jmmv@)</li>
<li>John W. De Boskey (jwd@)</li>
<li>Kai Wang (kaiw@)</li>
<li>Luigi Rizzo (luigi@)</li>
<li>Neel Natu (neel@)</li>
<li>Craig Rodrigues (rodrigc@)</li>
<li>Stanislav Sedov (stas@)</li>
<li>Thomas Quinot (thomas@)</li>
<li>Andrew Thompson (thompsa@)</li>
<li>Pyun YongHyeon (yongari@)</li>
<li>Zbigniew Bodek (zbb@)</li>
</ul>
<p></p>
</body>
</project>
<project cat='team'>
<title>FreeBSD Foundation</title>
<contact>
<person>
<name>Deb Goodkin</name>
<email>deb@FreeBSDFoundation.org</email>
</person>
</contact>
<body>
<p>The FreeBSD Foundation is a 501(c)(3) non-profit
organization dedicated to
supporting and promoting the FreeBSD Project and community
worldwide.
Funding comes from individual and corporate donations and
is used to fund
and manage software development projects, conferences and
developer summits,
and provide travel grants to FreeBSD contributors.</p>
<p>The Foundation purchases and supports hardware to improve
and maintain
FreeBSD infrastructure and provides resources to improve
security,
quality assurance, and release engineering efforts;
publishes
marketing material to promote, educate, and advocate for
the FreeBSD Project;
facilitates collaboration between commercial vendors and
FreeBSD developers;
and finally, represents the FreeBSD Project in executing
contracts,
license agreements, and other legal arrangements that
require
a recognized legal entity.</p>
<p>Here are some highlights of what we did to help FreeBSD
last quarter:</p>
<p>We kicked off the year with an all-day board meeting in
Berkeley,
where FreeBSD began, to put together high-level plans for
2019.
This included prioritizing technologies and features we
should support,
long-term planning for the next 2-5 years, and
philosophical discussions
on our purpose and goals.</p>
<p>Partnerships and Commercial User Support</p>
<p>We began the year by meeting with a few commercial users,
to help them
navigate working with the Project, and understanding how
they are using
FreeBSD. We're also in the process of setting up meetings
for Q2 and
throughout the rest of 2019. Because we're a 501(c)(3)
non-profit, we
don't directly support commercial users.
However, these meetings allow us to focus on facilitating
collaboration
with the community.</p>
<p>Fundraising Efforts</p>
<p>Our work is 100% funded by your donations. We kicked off
the year with many
individual and corporate donations, including donations
and commitments from
NetApp, Netflix, Intel, Tarsnap, Beckhoff Automation,
E-Card, VMware, and
Stormshield. We are working hard to get more commercial
users to give back
to help us continue our work supporting FreeBSD.
Please consider making a
<a
href="https://www.FreeBSDfoundation.org/donate/">donation</a>
to help us continue and increase our support for FreeBSD
at:
<a
href="https://www.FreeBSDfoundation.org/donate/">www.FreeBSDfoundation.org/donate/</a>.</p>
<p>We also have the Partnership Program, to provide more
benefits for our
larger commercial donors. Find out more information at
https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/
and share with your companies!</p>
<p>OS Improvements</p>
<p>The Foundation improves the FreeBSD operating system by
employing our
technical staff to maintain and improve critical kernel
subsystems,
add features and functionality, and fix problems. This
also includes funding
separate project grants like
the arm64 port, porting the blacklistd access control
daemon, and the
integration of VIMAGE support,
to make sure that FreeBSD remains a viable solution for
research, education,
computing, products and more.</p>
<p>Over the quarter there were 241 commits from nine
Foundation-sponsored staff
members and grant recipients.</p>
<p>We kicked off or continued the following projects last
quarter:</p>
<ul>
<li>FUSE file system kernel support (update and bug fixes)</li>
<li>Linuxulator testing and diagnostics improvements</li>
<li>SDIO and WiFi infrastructure improvements</li>
<li>x86-64 scalability and performance improvements</li>
<li>OpenZFS Online RAID-Z Expansion</li>
</ul>
<p>
Having software developers on staff has allowed us to jump
in and
work directly on projects to improve FreeBSD like:</p>
<ul>
<li>amd64 and i386 pmap improvements and bugfixes</li>
<li>address userland threading library issues</li>
<li>improve i386 support to keep the platform viable</li>
<li>improve FreeBSD on RISC-V</li>
<li>application of the Capsicum sandboxing framework</li>
<li>build system improvements and bug fixes</li>
<li>respond to reports of security issues</li>
<li>implement vulnerability mitigations</li>
<li>tool chain updates and improvements</li>
<li>adding kernel code coverage support for the
<a
href="https://github.com/google/syzkaller">Syzkaller</a>
coverage-guided system call
fuzzer</li>
<li>improved Syzkaller support for FreeBSD</li>
<li>improve the usability of <tt>freebsd-update</tt></li>
<li>improve network stack stability and address race
conditions</li>
<li>ensure FreeBSD provides userland interfaces required by
contemporary
applications</li>
<li>implement support for machine-dependent optimized
subroutines</li>
<li>update and correct documentation and manpages</li>
<li>DTrace bug fixes</li>
<li>update the FreeBSD Valgrind port and try to upstream the
changes</li>
</ul>
<p>
Continuous Integration and Quality Assurance</p>
<p>The Foundation provides a full-time staff member who is
working on improving
our automated testing, continuous integration, and overall
quality assurance
efforts.</p>
<p>During the first quarter of 2019, Foundation staff
continued improving the
project's CI infrastructure, working with contributors to
fix failing build
and test cases, and working with other teams in the
project for their
testing needs. In this quarter, we started publishing the
<a
href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">CI
weekly report</a>
on the freebsd-testing@ mailing list.</p>
<p>See the FreeBSD CI section of this report for more
information.</p>
<p>Release Engineering</p>
<p>The Foundation provides a full-time staff member to
oversee the
release engineering efforts. This has provided timely and
reliable releases
over the last five years.</p>
<p>During the first quarter of 2019, the FreeBSD Release
Engineering team
continued providing weekly development snapshots for
13-CURRENT, 12-STABLE,
and 11-STABLE.</p>
<p>In addition, the Release Engineering team published the
schedule for the
upcoming 11.3-RELEASE cycle, the fourth release from the
stable/11 branch,
which builds on the stability and reliability of
11.2-RELEASE.</p>
<p>The upcoming
<a
href="https://www.freebsd.org/releases/11.3R/schedule.html">11.3-RELEASE
schedule</a>
can be found at:
https://www.freebsd.org/releases/11.3R/schedule.html</p>
<p>FreeBSD 11.3 is currently targeted for final release in
early July 2019.</p>
<p>Please see the FreeBSD Release Engineering Team section of
this quarterly
status report for additional details surrounding the above
mentioned work.</p>
<p>Supporting FreeBSD Infrastructure</p>
<p>The Foundation provides hardware and support to improve
FreeBSD infrastructure. Last quarter, we continued
supporting FreeBSD hardware located
around the world.</p>
<p>FreeBSD Advocacy and Education</p>
<p>A large part of our efforts are dedicated to advocating
for the Project.
This includes promoting work being done by others with
FreeBSD; producing
advocacy literature to teach people about FreeBSD and help
make the path to
starting using FreeBSD or contributing to the Project
easier; and attending
and getting other FreeBSD contributors to volunteer to run
FreeBSD events,
staff FreeBSD tables, and give FreeBSD presentations.</p>
<p>The FreeBSD Foundation sponsors many conferences, events,
and summits
around the globe. These events can be BSD-related, open
source,
or technology events geared towards underrepresented
groups. We support
the FreeBSD-focused events to help provide a venue for
sharing knowledge,
to work together on projects, and to facilitate
collaboration between
developers and commercial users. This all helps provide a
healthy ecosystem.
We support the non-FreeBSD events to promote and raise
awareness of FreeBSD,
to increase the use of FreeBSD in different applications,
and to recruit
more contributors to the Project.</p>
<p>Check out some of the advocacy and education work we did
last quarter:</p>
<ul>
<li>Attended FOSDEM 2019 where we: staffed the FreeBSD Stand,
sponsored the
co-located FreeBSD Developer Summit, and gave the 25 Years
of FreeBSD
presentation in the BSD Dev room.</li>
</ul>
<p></p>
<ul>
<li>Sponsored and presented at SANOG33 in Thimphu, Bhutan</li>
</ul>
<p></p>
<ul>
<li>Represented FreeBSD at APRICOT 2019 in Yuseong-gu, Daejeon
South Korea</li>
</ul>
<p></p>
<ul>
<li>Sponsored the USENIX FAST conference in Boston, MA as an
Industry Partner</li>
</ul>
<p></p>
<ul>
<li>Ran our first ever FreeBSD track at
<a href="https://www.socallinuxexpo.org/scale/17x">SCALE
17x</a>, which included an
all-day
<a
href="https://www.socallinuxexpo.org/scale/17x/presentations/getting-started-freebsd">Getting
Started with FreeBSD</a>
workshop. We were thrilled with the turnout of almost 30
participants and
received a lot of positive feedback. Thanks to Roller
Angel who taught the
class with the help of Deb Goodkin and Gordon Tetlow. We
also promoted
FreeBSD at the FreeBSD table in the Expo Hall.</li>
</ul>
<p></p>
<ul>
<li>Sponsored, presented, and exhibited at FOSSASIA in
Singapore</li>
</ul>
<p></p>
<ul>
<li>Sponsored AsiaBSDCon 2019</li>
</ul>
<p></p>
<ul>
<li>Committed to sponsoring Rootconf, BSDCan, and EuroBSDcon</li>
</ul>
<p></p>
<ul>
<li>Created registration systems for the Aberdeen Hackathon
and the upcoming
2019 Vienna FreeBSD Security Hackathon</li>
</ul>
<p></p>
<ul>
<li>Provided FreeBSD advocacy material</li>
</ul>
<p></p>
<ul>
<li>Provided 3 travel grants to FreeBSD contributors to attend
many
of the above events.</li>
</ul>
<p>
We continued producing FreeBSD advocacy material to help
people promote
FreeBSD around the world.</p>
<p>Read more about our conference adventures in the
conference recaps and trip
reports in our
<a
href="https://www.freebsdfoundation.org/news-and-events/newsletter/">monthly
newsletters</a>.</p>
<p>We help educate the world about FreeBSD by publishing the
professionally produced FreeBSD Journal. We're excited to
announce that with
the release of the January/February 2019 issue, the
FreeBSD Journal is now a
free publication. Find out more and access the latest
issues at
<a
href="https://www.FreeBSDfoundation.org/journal/">www.FreeBSDfoundation.org/journal/</a>.</p>
<p>You can find out more about events we attended and
upcoming events at
<a
href="https://www.FreeBSDfoundation.org/news-and-events/">www.FreeBSDfoundation.org/news-and-events/</a>.</p>
<p>We also engaged with a new website developer to help us
improve our website
to make it easier for community members to find
information more easily and
to make the site more efficient.</p>
<p>Legal/FreeBSD IP</p>
<p>The Foundation owns the FreeBSD trademarks, and it is our
responsibility to
protect them. We also provide legal support for the core
team to investigate
questions that arise.</p>
<p>Go to <a
href="http://www.FreeBSDfoundation.org">www.FreeBSDfoundation.org</a>
to find out
how we support FreeBSD and how we can help you!</p>
</body>
</project>
<project cat='team'>
<title>Continuous Integration</title>
<contact>
<person>
<name>Jenkins Admin</name>
<email>jenkins-admin@FreeBSD.org</email>
</person>
<person>
<name>Li-Wen Hsu</name>
<email>lwhsu@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url>
<url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url>
<url href="https://wiki.freebsd.org/Jenkins">FreeBSD Jenkins wiki</url>
<url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url>
<url href="https://github.com/freebsd/freebsd-ci">freebsd-ci Repository</url>
<url href="https://preview.tinyurl.com/y9maauwg">Tickets related to freebsd-testing@</url>
<url href="https://wiki.freebsd.org/HostedCI">Hosted CI wiki</url>
<url href="https://hackfoldr.org/freebsd-ci-report/">FreeBSD CI weekly report</url>
</links>
<body>
<p>The FreeBSD CI team maintains continuous integration
system and
related tasks for the FreeBSD project. The CI system
regularly
checks the changes committed to the project's Subversion
repository
can be successfully built, and performs various tests and
analysis
of the results. The results from build jobs are archived
in an
artifact server, for the further testing and debugging
needs. The
CI team members examine the failing builds and unstable
tests, and
work with the experts in that area to fix the code or
adjust test
infrastructure.</p>
<p>Starting from this quarter, we started to publish CI
weekly report at
<a
href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">freebsd-testing@</a>
mailing list. The archive is available at
<a
href="https://hackfoldr.org/freebsd-ci-report/">https://hackfoldr.org/freebsd-ci-report/</a></p>
<p>We also worked on extending test executing environment
to improve the code coverage, temporarily disabling flakey
test cases,
and opening tickets to work with domain experts. The
details are
of these efforts are available in the weekly CI reports.</p>
<p>We published the
<a
href="https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md">draft
FCP for CI policy</a>
and are ready to accept comments.</p>
<p>Please see freebsd-testing@ related tickets for more
information.</p>
<p>Work in progress:</p>
<ul>
<li>Fixing the failing test cases and builds</li>
<li>Adding drm ports building test against -CURRENT</li>
<li>Implementing automatic tests on bare metal hardware</li>
<li>Implementing the embedded testbed</li>
<li>Planning for running ztest and network stack tests</li>
<li>Help more 3rd software get CI on FreeBSD through a hosted
CI solution</li>
</ul>
<p></p>
</body>
</project>
<project cat='proj'>
<title>Security-Related changes</title>
<contact>
<person>
<name>Konstantin Belousov</name>
<email>kib@freebsd.org</email>
</person>
</contact>
<body>
<p>ASLR</p>
<p>The ASLR (Address Space Layout Randomization) patch from
<a href="https://reviews.freebsd.org/D5603">review
D5603</a> was
committed into svn. While debate continues about the
current and
forward-looking value ASLR provides, having an
implementation in
the FreeBSD source tree makes it easily available to those
who wish
to use it. This also moves the conversation past the
relative
merits to more comprehensive security controls.</p>
<p>KPTI per-process control</p>
<p>The KPTI (Kernel Page Table Isolation) implementation was
structured
so that most selections of page isolation mode were local
to the
current address space. In other words, the global control
variable
pti was almost unused in the code paths, instead the
user/kernel
%cr3 values were directly loaded into registers or
compared to see
if the user page table was trimmed. Some missed bits of
code were
provided by Isilon, and then bugs were fixed and last
places of
direct use of pti were removed.</p>
<p>Now when the system starts in the pti-enabled mode,
proccontrol(1) can
be used by root to selectively disable KPTI mode for
children of a
process. The motivation is that if you trust the program
that you
run, you can get the speed of non-pti syscalls back, but
still run
your normal user session in PTI mode. E.g., firefox would
be properly
isolated.</p>
<p>Feature-control bits</p>
<p>Every FreeBSD executable now contains a bit mask intended
for
enabling/disabling security-related features which makes
sense for the
binary. This mask is part of the executable segments
loaded on image
activation, and thus is part of any reasonable way to
authenticate the
binary content.</p>
<p>For instance, the ASLR compatibility is de-facto the
property of the
image and not of the process executing the image. The
first (zero)
bit in the mask controls ASLR opt-out. Other OSes (e.g.
Solaris) used
an OS-specific dynamic flag, which has the same runtime
properties
but leaves less bits to consume in the feature-control
mask.</p>
<p>The feature-control mask is read both by kernel and by
rtld during
image activation. It is expected that more features will
be added
to FreeBSD and the mask can be used for enabling/disabling
those
features..</p>
<p>It is expected that a tool to manipulate the mask will be
provided
shortly, see <a
href="https://reviews.freebsd.org/D19290">review
D19290</a>.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>AXP803 PMIC driver update</title>
<contact>
<person>
<name>Ganbold Tsagaankhuu</name>
<email>ganbold@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The AXP803 is a highly integrated PMIC that targets
Li-battery
(Li-ion or Li-polymer) applications. It provides flexible
power
management solution for processors such as the Allwinner
A64 SoC.
This SoC is used by <a
href="https://www.pine64.org/pinebook/">Pinebook</a>.</p>
<p>The following updates were performed on the AXP803 driver:</p>
<ul>
<li>Enabled necessary bits when activating interrupts. This
allows
reading some events from the interrupt status registers.
These
events are reported to devd via system "PMU" and subsystem
"Battery", "AC" and "USB" such as plugged/unplugged,
battery
absent, charged and charging.</li>
<li>Added sensors support for AXP803/AXP813. Sensor values
such as
battery charging, charge state, voltage, charging current,
discharging current, battery capacity can be obtained via
sysctl.</li>
<li>Added sysctl for setting battery charging current. The
charging
current can be set using steps from 0 to 13. These steps
correspond to 200mA to 2800mA, with a granularity of
200mA/step.</li>
</ul>
<p></p>
</body>
</project>
<project cat='proj'>
<title>Broadcom ARM64 SoC support</title>
<contact>
<person>
<name>Michal Stanek</name>
<email>mst@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
</contact>
<body>
<p>The Semihalf team continued working on FreeBSD support for
the
<a
href="https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm58712/">Broadcom
BCM5871X SoC series</a></p>
<p>BCM5871X are quad-core 64-bit ARMv8 Cortex-A57
communication
processors targeted for networking applications such as
10G routers,
gateways, control plane processing and NAS.</p>
<p>Completed since the last update:</p>
<ul>
<li>iProc PCIe root complex (internal and external buses)</li>
<li>OTP (One Time Programmable memory) driver</li>
</ul>
<p>
In progress:</p>
<ul>
<li>BNXT Ethernet support</li>
<li>Crypto engine acceleration for IPsec offloading.</li>
</ul>
<p>
Todo:</p>
<ul>
<li>Upstreaming of work. This work is expected to be
submitted/merged to HEAD in the second half of
2019.</li>
</ul>
<p></p>
</body>
<sponsor>
Juniper Networks, Inc
</sponsor>
</project>
<project cat='proj'>
<title>Capsicum</title>
<contact>
<person>
<name>Enji Cooper</name>
<email>ngie@freebsd.org</email>
</person>
<person>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>Mariusz Zaborski</name>
<email>oshogbo@FreeBSD.org</email>
</person>
<person>
<name>Bora Özarslan</name>
<email>borako.ozarslan@gmail.com</email>
</person>
</contact>
<links>
<url href="https://wiki.FreeBSD.org/Capsicum">Capsicum Wiki Page</url>
</links>
<body>
<p>Three themes for Capsicum work were:</p>
<ul>
<li>Importing Google's Capsicum test suite into FreeBSD</li>
<li>Porting and sandboxing openrsync for FreeBSD</li>
<li>Applying capsicum to additional base system utilities</li>
</ul>
<p>
The Googletest-based Capsicum test cases are now
integrated into
FreeBSD. After some discussion with David Drysdale - the
main
maintainer and developer for the Capsicum port on Linux -
we decided that
from now the FreeBSD will be upstream for Capsicum test
cases.</p>
<p>The next major step was sandboxing openrsync. In the
course of that work we
extended our fileargs service with two new
functionalities. We modified
the fileargs service to allow limiting the operations
which can be performed,
and can now delegate <tt>lstat</tt> to the Casper service.</p>
<p>Furthermore, openrsync highly depends on the <tt>fts</tt>
API. We spend
some time in optimizing <tt>fts</tt> and making it sandbox
friendly by
introducing <tt>fts_openat</tt> function and removing the
need to change the
working directory to traverse the paths. The changes to
the <tt>fts</tt> API
are now in the tests phase.</p>
<p>Moreover, we improved bootstrapping for non-FreeBSD
machines. Thanks
to this work we can now build tools needed to bootstrap
FreeBSD which
use Casper services. In the base system <tt>strings</tt>
is now sandboxed as a
result.</p>
<p>We also sandboxed <tt>rtsol</tt>, <tt>rtsold</tt>, and
<tt>savecore</tt>.</p>
<p>We host biweekly Capsicum calls. The notes from the
meetings are published
in FreeBSD's
<a
href="https://github.com/freebsd/meetings/tree/master/capsicum">Capsium
meeting repository</a>
on GitHub.
If you would like to join the call do not hesitate to send
us an email.</p>
</body>
</project>
<project cat='proj'>
<title>C Runtime changes</title>
<contact>
<person>
<name>Konstantin Belousov</name>
<email>kib@freebsd.org</email>
</person>
</contact>
<body>
<p>Several changes where made to the C runtime which
generally improves
the environment provided to an application.</p>
<p>Fix for libraries with initial exec TLS mode</p>
<p>Some libraries, most prominent of which is NVidia-provided
and thus
binary-only libGL.so.1, use so called initial exec mode
for TLS
variables access. This is the fastest mode of TLS access,
but its
drawback is that it only reliably work when the main
binary is linked
against the library, i.e. dlopen-ing the library to load
it at runtime
is not guaranteed to work.</p>
<p>This mode works by placing the TLS variables for objects
in one area
allocated during the executable initialization, which
somewhat
explains the name of the mode. An obvious consequence is
that if such
library is loaded later, there is no space in the TLS area
for an
application to put its TLS variables.</p>
<p>The FreeBSD dynamic linker is aware of misbehaviour of the
app
builders, and provides some amount of slack in the TLS
area to give space
for such libraries. But it appeared that the initial
content of the
TLS segment from libraries was not distributed among the
threads' TLS
areas, still breaking libraries which use initial exec
mode for TLS.</p>
<p>Another issue that somewhat mitigates mis-use of the mode
is the
<tt>DF_STATIC_TLS</tt> flag in the dynamic section. This
flag allows the
linker to check for the space earlier and avoid loading
dependencies
if there is no total required space. This linker flag was
implemented
by the BFD ld linker, but not by the LLVM lld linker.</p>
<p>The FreeBSD dynamic linker was fixed to properly
distribute TLS
initialization data to all threads' initial segments,
which required
reasonably extensive per-architecture changes to libc and
libthr.
Simultaneously, LLD was improved to mark libraries using
initial exec
TLS mode with the appropriate flag.</p>
<p>These measures should make FreeBSD more resilent to
improperly
linked libraries. The most interesting fix is to users of
the
nvidia libgl library, because it cannot be fixed by
relinking.</p>
<p>Use rtld malloc in libthr</p>
<p>The FreeBSD implementation of mutexes in libthr allocates
some
memory to keep the mutex data needed for mutex
initialization. In
contrast, the malloc implementation used by FreeBSD,
jemalloc(3),
requires working pthread mutexes for operation.</p>
<p>This creates a chicken-and-egg problem during executable
startup, and
requires jemalloc to provide fragile hacks to make it
possible to
initialize mutexes. This has been a constant source of
mismatches on
imports of new versions of jemalloc.</p>
<p>The FreeBSD rtld implementation already contained a very
light-weight
malloc implementation, suitable for limited use in
pre-C-runtime
environments. This seemed to be the ideal fit for an
allocator for the
pthread private mutexes memory. By using this allocator, a
method
to address the cyclic dependencies between jemalloc and
libthr could
finally be implemented.</p>
<p>The entry points in the rtld malloc.c were renamed to
avoid a clash with
the libc exported symbols, and now the file is linked
statically into
libthr, providing an allocator for private mutexes and
pthread key
storage. The later was already switched to direct use of
mmap(2) for
similar reasons. Now less memory is wasted when key
storage requires
less than a page.</p>
<p>Destructors order bug</p>
<p>Alexander Kabaev (kan@) noted that C++ destructors for the
static objects from the linked shared libraries are
executed before
C++ destructors of the static objects from the main
binary. This was
verified both for clang++ and g++, but amusingly not for
<tt>__attribute__(((destructor)))</tt>.</p>
<p>The bug was introduced when init functions and init arrays
for main
binary startup are called from the rtld instead of csu (C
startup
code linked to the binary, typically from crt1.o). The
cause is
due to the somewhat complicated way of how destructors are
called
both by fini/fini arrays and rtld-registered atexit(3)
handler.</p>
<p>Solution is to register rtld atexit(3) handler before main
binary init
functions are called, using new internal ABI
<tt>__libc_atexit()</tt> function.</p>
<p>It is amusing that the bug was not noticed for so many
years.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>ENA FreeBSD Driver Update</title>
<contact>
<person>
<name>Michal Krawczyk</name>
<email>mk@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
</contact>
<links>
<url href="https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README">ENA README</url>
</links>
<body>
<p>ENA (Elastic Network Adapter) is the smart NIC available
in the
virtualized environment of Amazon Web Services (AWS). The
ENA
driver supports multiple transmit and receive queues and
can handle
up to 100 Gb/s of network traffic, depending on the
instance type
on which it is used.</p>
<p>ENAv2 has been under development for FreeBSD, similar to
Linux
and DPDK. Since the last update internal review and
improvements
of the patches were done, followed by validation on
various AWS
instances.</p>
<p>To do:</p>
<ul>
<li>Upstream of the ENAv2 patches</li>
</ul>
<p>
Recently, AWS released the A1 instances which are arm64
instances.
The FreeBSD kernel was fixed, so the ENA can be used on
those
instances with no issues. There were changes required in
resource
activation in the ENA driver
<a
href="https://svnweb.freebsd.org/base?view=revision&amp;revision=345371">r345371</a>
and the addition of a missing bus release method to the
nexus module
for aarch64
<a
href="https://svnweb.freebsd.org/base?view=revision&amp;revision=345373">r345373</a>.
With these changes, the ENA driver can run on A1 instances
without
any known issues.</p>
<p></p>
</body>
<sponsor>
Amazon.com Inc
</sponsor>
</project>
<project cat='proj'>
<title>FUSE</title>
<contact>
<person>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</person>
</contact>
<body>
<p>FUSE (File system in USErspace) allows a userspace program
to
implement a file system. It is widely used to support
out-of-tree file
systems like NTFS, as well as for exotic pseudo file
systems like
sshfs. FreeBSD's fuse driver was added as a GSoC project
in 2012.
Since that time, it has been largely neglected. The FUSE
software is
<a
href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&amp;known_name=fusefs&amp;list_id=289348&amp;query_based_on=fusefs&amp;query_format=advanced&amp;short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&amp;short_desc_type=anywordssubstr">buggy</a>
and out-of-date. Our implementation is about 11 years
behind.</p>
<p>The FreeBSD Foundation has agreed to fund a project to
improve the state of the
FreeBSD FUSE driver. So far I've written a test suite for
the fusefs(5)
module, fixed 1 previously reported bug, discovered and
fixed 6 new bugs, fixed
all of fusefs's Coverity CIDs, made some minor performance
enhancements and
done some general cleanup. During the next quarter I plan
to continue fixing
bugs, and I'll also raise the driver's API level as high
as I can before the
quarter runs out. We're currently at 7.8; the highest
defined level is 7.28.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>Kernel ZLIB Update</title>
<contact>
<person>
<name>Yoshihiro Ota</name>
<email>ota@j.email.ne.jp</email>
</person>
</contact>
<links>
<url href="https://reviews.freebsd.org/D19706">Review D19706</url>
</links>
<body>
<p>The FreeBSD system still uses an ancient (over 20
year-old) version
of zlib (version 1.0.4). The FreeBSD kernel zlib
implementation
has special enhancements only used by netgraph. There is a
separate
version of code derived from unzip 5.12 used to inflate
gzip files
in the kernel which could be replaced with a more modern
zlib.
More detailed information is written in
sys/modules/zlib/README in
the review.</p>
<p>In order to use the latest zlib, version 1.2.11, work has
been done
to revisit all existing zlib uses in the system. Most of
the code works
with the newer version of zlib as is. The unzip code will
need
some conversion work to use the newer zlib. A few callers
will be
made simplier by using some newer APIs available in the
updated zlib.
There are some zombie programs that have been broken and I
would
like to delete.</p>
<p>This will clean up zombie programs and duplicated zlib
code.
This will also make future zlib version updates easier.</p>
<p>These changes touch some very sensitive areas of the
system, such
as kernel loading, or are architecture specific like
armv6/armv7,
and also touch some legacy code like kgzip+kgzldr on i386.
Testers
and active users of these legacy zlib code are welcomed.</p>
<ul>
<li>armv elf_trampoline
Arm up to v5 can boot from gzipped kernel. This code is
modified
to use newer API for simplicity. Please verify gzipped
kernel
still boots with new code (Current code has fall back to
legacy
zlib in case of failure).
Please also elaborate how to link such kernel, too. I'm
still
trying to figure that out.</li>
<li>netgraph compression/decompression
Please help testing and/or teach how to test. Netgraph
compiles
in the FreeBSD zlib version inside.</li>
<li>gzipped a.out
Does anyone use gzipped a.out executables, still? If so,
does
someone have an easy and safe program to run?
Is a.out format i386 only?</li>
<li>zfs boot
Can we boot from gzipped file system today?</li>
<li>CTF
Checking how I can test.</li>
</ul>
<p></p>
</body>
</project>
<project cat='proj'>
<title>FreeBSD boot security improvements</title>
<contact>
<person>
<name>Michal Stanek</name>
<email>mst@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
<person>
<name>Kornel Duleba</name>
<email>mindal@semihalf.com</email>
</person>
</contact>
<links>
<url href="https://svnweb.freebsd.org/changeset/base/345830">Veriexec manifest verification in kernel</url>
<url href="https://svnweb.freebsd.org/changeset/base/345438">TPM as entropy source</url>
<url href="https://svnweb.freebsd.org/changeset/base/344840">UEFI support in libsecureboot</url>
</links>
<body>
<p>FreeBSD gained TPM 2.0 (Trusted Platform Module) support
at the end
of 2018. A kernel configuration option, TPM_HARVEST, was
also added
to use the TPM RNG as system entropy source. When used
this way,
the TPM can be harvested every ten seconds for entropy
which is
mixed into the OS entropy pool. The kernel option is
currently
disabled by default in amd64 GENERIC kernel configuration.</p>
<p>UEFI Secure Boot support, developed by Semihalf, has been
merged
with sjg's Veriexec support, resulting in a unified
library named
libsecureboot. This library is used for verification of
kernel and
modules by the loader. The library uses BearSSL as the
cryptographic
backend. The library supports loading trusted and
blacklisted
certificates from UEFI (DB/DBx databases) and can use them
as trust
anchors for the verification.</p>
<p>The library is also used by Veriexec to verify and parse
the
authentication database (called 'manifest')
in the kernel. Previously the manifest was
verified and parsed by a userspace application, then sent
to the
kernel via /dev/veriexec, which was a significant
limitation and a
security weakness.</p>
<p>To do:</p>
<ul>
<li>Backport to stable branches.</li>
</ul>
<p>
Special thanks to sjg and Juniper for fruitful cooperation
around
Veriexec and the libsecureboot development.</p>
<p></p>
</body>
<sponsor>
Stormshield
</sponsor>
</project>
<project cat='proj'>
<title>LLVM's lld as the FreeBSD system linker</title>
<contact>
<person>
<name>Ed Maste</name>
<email>emaste@freebsd.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/LLD">LLD on the FreeBSD Wiki</url>
<url href="https://bugs.freebsd.org/214864">lld exp-run</url>
</links>
<body>
<p>In FreeBSD-HEAD and 12.0 the default FreeBSD system linker
(i.e., <tt>/usr/bin/ld</tt>) is LLVM's lld, on amd64,
arm64, and armv7.
For i386 in 12.0 lld is used as the bootstrap linker
(i.e., to build the kernel and base system) but it is not
enabled
as the system linker because of multiple issues building
FreeBSD ports
with it enabled.</p>
<p>The primary issue affecting i386 with lld is that many
ports build
position-dependent code (i.e., non-PIC) for use in shared
libraries.
This either comes from omitting the <tt>-fPIC</tt>
compiler flag, or using
hand-written position-dependent assembly. Compared with
other
CPU architectures i386 position-independent code is rather
inefficient,
which may be responsible for port authors making an
explicit decision
to avoid PIC.</p>
<p>By default lld does not allow position-dependent code in
shared objects
(in particular, it does not permit relocations against
read-only segments -
typically containing the`.text` section).</p>
<p>Over the last quarter many commits were made to the ports
tree to fix
the build when the system linker is lld - either building
PIC code,
or adding the <tt>-znotext</tt> linker flag to permit
relocations against
read-only segments, or just switching the port to link
with GNU ld
if it is incompatible with lld in some other way.</p>
<p>At this point there are only a few dozen open bug reports
for issues
linking ports with lld as the system linker, and I expect
FreeBSD 12.1
to use lld as the system linker on i386 as well.</p>
<p>Tasks:</p>
<ul>
<li>Fix freepascal/Lazarus ports with lld</li>
<li>Triage and address remaining port failures</li>
<li>Holistic review of lld workarounds in the ports tree, to
identify changes
that are no longer needed, should be addressed in lld, or
should be sent
upstream</li>
</ul>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>mlx5 Drivers Update</title>
<contact>
<person>
<name>Slava Shwartsman, Hans Petter Selasky, Konstantin Belousov</name>
<email>freebsd-drivers@mellanox.com</email>
</person>
</contact>
<links>
<url href="http://www.mellanox.com/page/products_dyn?product_family=193&mtag=freebsd_driver">Mellanox OFED for FreeBSD Documentation</url>
</links>
<body>
<p>The mlx5 driver provides support for PCI Express adapters
based on
ConnectX-4(LX), ConnectX-5(EX) and ConnectX-6(DX).
The mlx5en driver provides support for Ethernet and the
mlx5ib driver provides
support for InfiniBand and RDMA over Converged Ethernet,
RoCE.</p>
<p>Following updates done in mlx5 drivers:</p>
<ul>
<li>Added support for ConnectX-6 and ConnectX-6dx devices,
which support of
up to 200Gb/s interface speeds!</li>
<li>Added TLS hardware offload support for ConnectX-6dx
devices. TLS Tx
crypto offload is a new feature for network devices. It
enables the kernel
TLS socket to skip encryption and authentication
operations on the transmit
side of the data path, delegating those to the NIC. In
turn, the network
adapter encrypts packets that belong to an offloaded TLS
socket on the fly.
The Mellanox network adapter does not modify any packet
headers. It expects
to receive fully framed TCP packets with TLS records as
payload. The NIC
replaces plaintext with ciphertext and fills the
authentication tag. The
adapter does not hold any state beyond the context needed
to encrypt the
next expected packet, i.e. expected TCP sequence number
and crypto state.</li>
<li>Add support for Dynamic Receive Queue Interrupt
Moderation. Dynamic
Interrupt Moderation (DIM) refers to any action made by
hardware and/or
software on run time to control interrupt rate on the
system. The
moderation action itself should not interfere with the
system's operation
and should not require any human interaction. In
networking, dynamic
interrupt moderation is used for controlling the rate of
interrupts
generated by the hardware for multiple traffic scenarios.</li>
<li>Enhanced support for self-healing mechanism:
In a rare occasion when Mellanox network adapters fail,
due to a firmware
bug for example, the driver will sense the catastrophic
error. As
a result of this failure detection, the device driver can
trigger a firmware reset for the device so it can recover
- without the
need to reboot the entire host.</li>
<li>Added support for in-driver firmware updating using
mlx5tool.</li>
</ul>
<p></p>
</body>
<sponsor>
Mellanox Technologies
</sponsor>
</project>
<project cat='proj'>
<title>PCI Express Resets</title>
<contact>
<person>
<name>Konstantin Belousov</name>
<email>konstantinb@mellanox.com</email>
</person>
</contact>
<body>
<p>Sometimes the need to reset a device attached to the
system presents
itself. Preferrably this device reset can be accomplished
without
causing the whole machine to reboot. It is easy to do with
USB
devices if the physical access is available -- you can
just re-plug
the device. For in-chassis devices, built-in, or on add-on
cards,
it is not possible to reset the device with physical
action, unless
the device is hot-plugged. Nonetheless, for typical modern
PCIe
devices, and most built-in PCI-emulation devices, the
reset can be
initiated using software actions.</p>
<p>If device is a real plugged-in PCIe device, then reset can
be
initiated by disabling and then re-training PCIe-link by
the upstream
port controls. For most PCI devices, which support the PCI
power
management specification, the proven way to accomplish the
reset
is to put the device into state D3 (off) and then return
to the
previous power state.</p>
<p>FreeBSD was missing a way to conveniently request user- or
driver-initiated reset of devices. While it was possible
to manually
fiddle with registers using pciconf, this is impractical
for users,
and requires a lot of boilerplate code from drivers.</p>
<p>A new BUS_RESET_CHILD() method was added to the newbus bus
interface,
and implementations added for PCIe bridges and PCI
devices. The
libdevctl(3) library call and devctl(8) command provide
convenient
userspace accessors for applications and administrators.</p>
<p>During the reset, the device driver must stop its
operations with
the device. One way to achieve this is to detach drivers
before
reset, and re-attach after the device afterwards. This is
mostly
fine for network interfaces, but other devices require
more
coordination to handle properly. For example, an NVMe disk
device
being detached it means that all mounted volumes abruptly
disapper
from VFS view. Due to this, the BUS_RESET_CHILD() method
allows
the caller to select either detach/re-attach or
suspend/resume
driver actions around the reset.</p>
<p>Mellanox uses the infrastructure to perform reset of the
mlx(5) card
after firmware reset without server reboot. It is believed
that
'devctl reset' will be more widely useful.</p>
<p></p>
</body>
<sponsor>
Mellanox Technologies
</sponsor>
</project>
<project cat='proj'>
<title>CFT - Package Base</title>
<contact>
<person>
<name>Kris Moore</name>
<email>kmoore@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://trueos.github.io/pkgbase-docs/">Package Base CFT - FAQ</url>
</links>
<body>
<p>The TrueOS project has been working on a Package Base
implementation,
and is pleased to issue its first
<a
href="https://lists.freebsd.org/pipermail/freebsd-pkgbase/2019-April/000396.html">CFT
to the FreeBSD community</a>.</p>
<p>The TrueOS packaging work has been in development for
close to 6
months, and differs from the original FreeBSD package base
effort,
in that it is an "out of tree" implementation. It allows
any version
of FreeBSD to be packaged, and only requires a
<a
href="https://github.com/freebsd/poudriere/pull/664">patch
to poudriere</a>, as well
as some minor ports enhancements, the first which is
<a href="https://reviews.freebsd.org/D20055">currently in
review</a>. For more information
on the current status, please refer to the FAQ page.</p>
<p>Additionally there will be a
<a
href="https://wiki.freebsd.org/DevSummit/201905/PackageBase">working-group
at BSDCan 2019</a>, and
we encourage porters to attend and join the discussion.</p>
<p></p>
</body>
<sponsor>
iXsystems Inc
</sponsor>
</project>
<project cat='arch'>
<title>FreeBSD/RISC-V Update</title>
<contact>
<person>
<name>Ruslan Bukin</name>
<email>br@FreeBSD.org</email>
</person>
<person>
<name>Mitchell Horne</name>
<email>mhorne@FreeBSD.org</email>
</person>
<person>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work has continued on RISC-V port in the past quarter.</p>
<p>Support for transparent superpage promotion was added to
the RISC-V
port, meaning that applications will now automatically use
large
page mappings when possible. Per-CPU pmap activation
tracking was
added, reducing the overhead of various pmap operations.
This
noticeably improves the responsiveness of FreeBSD when
running in
a multi-CPU virtual machine.</p>
<p>A RISC-V implementation of minidumps was completed.
Support for
debugging RISC-V kernel dumps will land in devel/gdb after
the
next GDB release.</p>
<p>It is now possible to compile the in-tree LLVM's RISC-V
target by
setting WITH_LLVM_TARGET_RISCV=YES in /etc/src.conf. The
use of
LLVM to compile the RISC-V port is currently experimental
and
further investigation is ongoing.</p>
<p>Work is ongoing to bring up FreeBSD on SiFive's HiFive
Unleashed
development board now that one has been obtained by a
FreeBSD
developer. We also expect to work on support for a new
version
of the SBI specification.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation, DARPA, AFRL
</sponsor>
</project>
<project cat='ports'>
<title>FreeBSD GNOME status report</title>
<contact>
<person>
<name>Koop Mast</name>
<email>kwm@FreeBSD.org</email>
</person>
<person>
<name>Eric Turgeon</name>
<email>ericbsd@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://freebsd.org/gnome/">GNOME FreeBSD</url>
<url href="https://github.com/freebsd/freebsd-ports-gnome">GNOME development Repo</url>
</links>
<body>
<p>Ports activity in this quarter were:</p>
<ul>
<li>The x11-toolkits/gtk30 port updated to 3.24.5 and later to
3.24.7.</li>
<li>The www/webkit2-gtk3 port was updated to 2.24.0.</li>
<li>And the old insecure webkit-gtk2 and webkit-gtk3 where
finally removed.</li>
</ul>
<p>
Work in progress, the branches are available in the GNOME
development
repo, see the link above.</p>
<ul>
<li>Eric Turgeon is working on MATE 1.22 in the
<tt>mate-1.22</tt> branch.
And is almost complete.</li>
<li>Charlie Li (IRC: vishwin) is working on a long overdue
update of
the cinnamon desktop. This update is almost complete. The
only
real blocker is that the screensaver can't be unlocked
after it
activates. The work is in the <tt>cinnamon</tt> branch.</li>
</ul>
<p></p>
<ul>
<li>Koop Mast works on GNOME 3.32. The desktop is usable apart
from
gdm which is currently non-functional. Due to lack of free
time
the work is going slowly. This work is available in the
<tt>gnome-3.32</tt>
branch.</li>
</ul>
<p>
People who are willing to contribute can find us on
#freebsd-gnome
on freenode.</p>
</body>
</project>
<project cat='ports'>
<title>FreeBSD KDE status report</title>
<contact>
<person>
<name>Adriaan de Groot</name>
<email>adridg@FreeBSD.org</email>
</person>
<person>
<name>Tobias C. Berner</name>
<email>tcberner@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://freebsd.kde.org/">KDE FreeBSD</url>
</links>
<body>
<p>The two biggest accomplishements this quarter were:</p>
<ul>
<li>Qt4 and all its consumers have been removed from the ports
tree.</li>
<li>www/qt5-webengine has been updated from the ancient 5.9.4
to 5.12.x by kai@</li>
</ul>
<p>
Further we have kept the KDE Frameworks, Plasma and
Applications
ports up to date with upstreams releases, which thanks to
upstreams'
FreeBSD-CI uses less and less patches.</p>
<p>All the kde@ maintained ports (including cmake) have been
kept up
to date with their releases.</p>
<p>The plans for the next quarter are in no particular order</p>
<ul>
<li>Cleanup PyQt ports and pyqt.mk</li>
<li>Improve qt.mk components</li>
<li>Update sddm to 0.18.x</li>
<li>Implement user management functionality in system settings
(write
non-logind backend)</li>
</ul>
<p>
People who are willing to contribute can find us on
#kde-freebsd
on freenode, and the kde@FreeBSD.org mailing list. Further
we accept
pull-requests and contributions on
github.com/freebsd/freebsd-ports-kde.</p>
<p></p>
</body>
</project>
<project cat='third'>
<title>sysctlmibinfo API 1.0</title>
<contact>
<person>
<name>Alfonso Sabato Siciliano</name>
<email>alfonso.siciliano@email.com</email>
</person>
</contact>
<links>
<url href="https://gitlab.com/alfix/sysctlmibinfo">gitlab.com/alfix/sysctlmibinfo</url>
</links>
<body>
<p>Port: <a
href="https://www.freshports.org/devel/libsysctlmibinfo/">devel/libsysctlmibinfo</a></p>
<p>The <tt>sysctl()</tt> system call can get or set the value
of a 'property'
of the system. A 'property' has others info (description,
type,
label, etc.), they are necessary to build an utility like
<tt>/sbin/sysctl</tt>,
example:</p>
<p><programlisting>
% sysctl -d kern.ostype<br/>
kern.ostype: Operating system type<br/>
% sysctl -t kern.ostype<br/>
kern.ostype: string<br/>
</programlisting></p>
<p>Primarily <tt>sysctlmibinfo</tt> wraps the undocumented
kernel interface
and provides an easy C API: <tt>sysctlmif_name()</tt>,
<tt>sysctlmif_description()</tt>,
<tt>sysctlmif_info()</tt>,
<tt>sysctlmif_label()</tt>,
<tt>sysctlmif_nextnode()</tt> and
<tt>sysctlmif_nextleaf()</tt>, to retrieve
the info of a 'property'.</p>
<p>Moreover <tt>sysctlmibinfo</tt> provides a high level API:
defines a
<tt>struct sysctlmif_object</tt> and has some function:
<tt>sysctlmif_filterlist()</tt>,
<tt>sysctlmif_grouplist()</tt> and
<tt>sysctlmif_tree()</tt>, to build lists and trees of
objects.</p>
<p>You can use this library to quickly build a custom
<tt>sysctl</tt> utility.
For example, the core of <tt>deskutils/sysctlview</tt> (a
graphical explorer
for the sysctl MIB Tree) is just a call to
<tt>sysctlmif_tree()</tt> and
a visit to the resulting tree to show its
<tt>sysctlmif_object</tt> nodes.</p>
<p>Note, actually a 'property' is an OID of the sysctl MIB,
it is
implemented by a <tt>struct sysctl_oid</tt> defined in
<tt>sys/sysctl.h</tt>.</p>
</body>
</project>
<project cat='third'>
<title>sysctlview 1.0</title>
<contact>
<person>
<name>Alfonso Sabato Siciliano</name>
<email>alfonso.siciliano@email.com</email>
</person>
</contact>
<links>
<url href="https://www.gitlab.com/alfix/sysctlview">gitlab.com/alfix/sysctlview</url>
</links>
<body>
<p>Port: <a
href="https://www.freshports.org/deskutils/sysctlview/">deskutils/sysctlview</a></p>
<p>The FreeBSD's kernel maintains a Management Information
Base where
the objects are properties to tuning the system using the
<tt>sysctl()</tt> syscall and the <tt>/sbin/sysctl</tt>
utility. The <tt>sysctlview</tt>
utility is a "graphical sysctl MIB explorer", it depends
on <tt>gtkmm</tt>
(to build a GUI) and <tt>sysctlmibinfo</tt> (to retrieve
the info from the
kernel).</p>
<p>The version 1.0 provides two "TreeView":</p>
<ul>
<li>"Main" to show 'name', 'description', 'type', 'format' and
'value'</li>
<li>"Flags" to show 'name' and a column for each 'flag'
defined in <tt>sys/sysctl.h</tt></li>
</ul>
<p>
The rows are "clickable" to display others info (e.g.,
'label').
Currently <tt>sysctlview</tt> can show numeric and string
values, the
support for some opaque value will be added in the future.</p>
</body>
</project>
<project cat='third'>
<title>Fuzzing FreeBSD with syzkaller</title>
<contact>
<person>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</person>
<person>
<name>Andrew Turner</name>
<email>andrew@FreeBSD.org</email>
</person>
<person>
<name>Michael Tuexen</name>
<email>tuexen@FreeBSD.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://github.com/google/syzkaller">syzkaller</url>
</links>
<body>
<p>Syzkaller is a coverage-guided system call fuzzer. It was
originally
developed for Linux. It programmatically creates programs
consisting
of sequences of random system calls and executes them in a
VM
(virtual machine). Using feedback from a kernel code
coverage
facility called kcov, syskaller mutates the generated test
programs
in an attempt to expand the executed coverage of code
paths within
the kernel. Sometimes exercising a seldom or infrequently
used
code path will crash the kernel. When syzkaller manages to
crash
the running kernel in the VM, it attempts to generate a
minimal
test case which reproduces the crash, simplifying
debugging.
Syzkaller is very effective at finding kernel bugs and has
uncovered
hundreds of issues in Linux. Over the past couple of
years,
syzkaller's author, Dmitry Vyukov, has added support for
other
operating systems, including FreeBSD.</p>
<p>Recently, a number of FreeBSD developers have been using
syzkaller
to find and fix bugs in the FreeBSD kernel. If interested,
one can
search the commit logs for "syzkaller" to find examples.
Syzkaller
can be run on a FreeBSD or Linux host to fuzz FreeBSD
running in
QEMU instances. It can also fuzz FreeBSD instances running
on GCE
(Google Compute Engine). Additionally, Google maintains a
dedicated
cluster of GCE hosts to continuously fuzz the latest
builds of
several different OS kernels. A
<a href="https://syzkaller.appspot.com/freebsd">FreeBSD
target</a> was recently added.
Subscribe to the
<a
href="https://groups.google.com/forum/#!forum/syzkaller-freebsd-bugs">syzkaller-freebsd-bugs</a>
Google Group to receive notifications for newly discovered
bugs.</p>
<p>Work is ongoing to improve syzkaller's coverage of
FreeBSD's system
calls. In particular, syzkaller needs to be taught about
all of
the target kernel's entry points and argument types in
order to be
useful. Many of the standard POSIX system calls are
already covered,
but most FreeBSD-specific system calls are not. Similarly,
many
ioctl(2) definitions are missing.</p>
<p>Some in-progress work aims to add support for bhyve as a
VM backend
for syzkaller, making it easier to fuzz FreeBSD VMs hosted
on
FreeBSD. Currently that can be done using QEMU, but QEMU
on FreeBSD
lacks support for hardware acceleration. See the
<a
href="https://github.com/google/syzkaller/pull/1150">PR</a>
for the
implementation.</p>
<p>Finally, a number of bugs identified by syzkaller have yet
to be
fixed. If you are interested in helping out with any of
the above,
please mail the contacts listed above.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='third'>
<title>University of Waterloo Co-operative Education Students</title>
<contact>
<person>
<name>Ed Maste</name>
<email>emaste@freebsd.org</email>
</person>
</contact>
<body>
<p>For the January-April 2019 term the FreeBSD Foundation has
again brought
on two co-operative education (co-op) students from the
University of
Waterloo.</p>
<p>Gerald Aryeetey is a 2nd year Computer Engineering
student. Gerald
started looking at a FreeBSD tool chain issue - our static
library
archiver (<literal>ar</literal>) did not read or write archives in the
64-bit format.
Gerald submitted a
<a
href="https://github.com/libarchive/libarchive/pull/1116">libarchive
change</a>
to support 64-bit archives followed by
<a href="https://reviews.freebsd.org/D19814">change to
FreeBSD's ar</a>
to add 64-bit support.</p>
<p>Gerald later looked at a number of <tt>freebsd-update</tt>
issues in FreeBSD's
bugzilla database, and submitted many fixes. Around a
dozen have been
committed to FreeBSD, and more are in review.</p>
<p>Gerald also worked on the
<a
href="https://github.com/freebsdfoundation/hardware-ci">FreeBSD
Foundation's hardware continuous integration</a>
effort.
The prototype installation is building FreeBSD on a
commit-by-commit basis
and testing on a BeagleBone Black and a Pine64 LTS.
The prototype will be converted to a permanent, public
installation in the
near future, after which additional test devices will be
added.</p>
<p>For his final project Gerald intends to write a device
driver for the
<a
href="https://www.microchip.com/wwwproducts/en/LAN7430">Microchip
LAN743x PCIe NIC</a>.</p>
<p>Bora Özarslan is a 3rd year student in Computing and
Financial Management.
Bora's initial focus was also on tool chain issues in
FreeBSD, starting with
improvements or bug fixes in FreeBSD's <tt>readelf</tt>
(from the
<a
href="https://sourceforge.net/p/elftoolchain/wiki/Home/">ELF
Tool Chain</a> project).</p>
<p>Bora developed a
<a href="https://reviews.freebsd.org/D19290">tool</a> to
modify feature control bits
in ELF binaries - for example, allowing binaries
incompatible with ASLR to
request to opt-out.
As part of his readelf work Bora also added support to
report the status of
the feature control bits.</p>
<p>Bora continued investigating security topics, looking at
applying
<a href="https://reviews.freebsd.org/D19407">Capsicum
sandboxing</a> to
Kristaps' BSD licensed rsync implementation,
<a
href="https://github.com/kristapsdz/openrsync">openrsync</a>.
This work required first implementing
<a
href="https://reviews.freebsd.org/D19548">fileargs_lstat</a>
support in <tt>cap_fileargs</tt>
(which as now been committed) as well as changes to the
<tt>fts</tt> directory hierarchy routines (which have not
yet been committed to
FreeBSD).</p>
<p>For the rest of the work term Bora will investigate and
test unmodified
Linux Docker containers on FreeBSD, to evaluate the state
of Linuxulator
support.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='third'>
<title>FreeBSD Wiki Apple Intel Mac mini update</title>
<contact>
<person>
<name>Trevor Roydhouse</name>
<email>fbsdwiki@gmx.net</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/IntelMacMini">FreeBSD Wiki</url>
</links>
<body>
<p>The FreeBSD Wiki page for the Apple Intel Mac minis has
been
comprehensively updated over the last quarter to drag it
from 2009
into 2019.</p>
<p>There are now detailed instructions for installing FreeBSD
as the
only operating system on models from 2007 through 2014 and
itemised
model specific information detailing FreeBSD support.</p>
<p>If anyone is interested, help is needed to provide more
specific
information for the macmini 1,1 and 6,1 through 8,1 models
and to
test patches for the asmc(4) driver for temperature sensor
feedback
and for setting fan speed. If you would like to help and
have access
to these Mac minis, please contact me.</p>
<p>Future tasks:</p>
<ul>
<li>Create and test more patches for asmc(4) to cover all
Intel Mac minis</li>
<li>Provide more information for 2006, 2012, 2014 and 2018 Mac
minis</li>
<li>Instructions for dual boot (macOS/FreeBSD) installations</li>
</ul>
<p></p>
</body>
</project>
</report>
|