| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.19.304 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWbzh8ACgkQONu9yGCS
# aT6nzxAAkwiBVc/j4TFLnZw8XhsDiZdfTMdCHT5BmqH2uz1E9JNShKY3dO3PaTU1
# vSBjpj/K1l0wuQwwyM0uNTDOxCsJ+4xnbQdrN3QsE7jNnSaJRT+tGFF8DED1saky
# 1vvMm+aZmNVuOSm6zrQqq8Mz/pgeyfbvGF0wE+aYQg1b2b7gBJlmtafIg05jChi7
# J+fbZbQpw0/Peb0cNGmiOnypw5cXy/Th8S+Ua9IWTr7UbEf2uRS2ExakCpUbTjHU
# OUOd1gy9qgUMzS2aWacuR9jtfVxVZrC6MhrGNMAohhY9wJbF4ZlKSn75nCJwSDgd
# 150JY6QRwYwMcljJN7LWDW0d9aUV2Gs3y/OgfuHiwLdLG8yc1O88g4booV1dd/+K
# 3+D1layqNNvoT0dDRwBrea3gHD4AyNR9qHtPmiTWi3e1KYbzA/OTc3wucHtc30Bf
# /PwuOPEp6VyKD1wqE75d9cks2TgbsG9rxYrmWyxp3sfGsXO3FgiNul8JNXqz/P3Q
# U9SR9jXJ8GKW/e5DUfM+c6hK9kXFmccK0hf7+2TDoFOxdCss+RY8VTALqxcc89TC
# UISEP+1KeGmSFzNc+Re+FvLpjQKFfTKe8Ak2sVXySdK+w5uZbUGhE82RxaDDldjN
# u7iZRIHkc5Y8GDFWvHED8awsMcFsrqnrGunYmqahBek8eQu7JXU=
# =ck1B
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 08 Jan 2024 05:27:43 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.302 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmV53vEACgkQONu9yGCS
# aT4wng/9ECVr1tNbX+0oo5p4GFnY2wR3I39TslGkS048Yo1UiW/m7WX2nDJPhJXO
# YLLiSsm0xOKZEn1xDh99L5kIWZHeHywajMdrIDZwRhOtBj8RHX0NyWQQzxg2ftxs
# 7IrgXyt/38b6kcQ2or8rqPqINGeZWAErukMfGMQZIMkp48D68cyfPDk0xfFwryAL
# mfn1tQOe6OgPFSbNR7MiV1mWzC6f06J6ZOx3kUvS6tqu0ZF61yhE8QkB/U2dQb/z
# S7VTM4BQ5NuW9BiGfLF39OAppEZ7jB/JZjCzh5h2ZUWpKhxl09u5FFqT81fOqtBN
# b/rhPnNnG1gFarGChrRbdvU4YnomBce7f7knpe0/vUiZW+UBxIW5yagUoXz7Eo0X
# Lyowuj5bXhDAJ1T/G/AV8Fv0eIunBRUyXcdeF6qeHWV2NzDmcYbswY6gh5eWDZL3
# ST83NvEq+p5uGzZHEbjbP3AX0P5wHDPAkhLXKLCwTsylHKrfL12e1+FWY2Jv40PA
# Ze+8SNCZrdHIYXZWSczrGZJM+GJh1KCkOQt/wSkGzPPAmoqcOTyMqD7Tj7o8qUER
# lQGDYzEO7+ZGMQ3QtSqQ//3Mlaeh4JYjzEYgpuXA7bFeepn/9FVDUurKZW39A/o5
# 0TTWsgwRlt2j92Jfi8ajbT5aAVJ0+o6KFqElUhc2onMMEWngUXs=
# =Ryx9
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Dec 2023 11:42:25 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.298 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVLYWMACgkQONu9yGCS
# aT7TWxAArWfLx5B55f2sGj/cDvs2xil315t1p/uhXCtgcstc/E+lxRipw3Bi3B0g
# IwoBHoxteAhHVzscTJUypzi/lzNdKuIoNvtD/IxpIt/vcP2T/JMBVzrMTsClGkDI
# xnaMq51lWT6Kpc3zt0k4EeAA9ifAeM45kIbZlPooJ15D6zuCLLMGdKiai8eYbOkM
# X65dzw2FxtCvIP3FfBxr4opRsWmkXSxD7diRVe4XPE/RyLFePPMitFg/NvpK/QLW
# +3aR6n0hhafvsYBE3T2+mb2A408uK7nT4aup25k9JF/RKhSzU2ZKTTZEtp92pZBr
# pHiUGa2bitYryBvSt69wRRamqctonrwXcW0FCAX+JxxujcfBmSR/z1GudQEbKBm8
# ALY2vgoDHeilbVxUCVGqnBpvu8NgwBw7J3z5S5m913X2CtMpeotvGzgksEE+gzdV
# Dw+l6bhj0vxAveYEgA5WVritymrh9NFNPQh32zeMG6FCcQCzuUd3gZPDECjcgFji
# keK3e71vjVemvgsvwAyx1WPpD0KDwjqZCAUL39Zmc7gQUzLZx8E2ujTIabefwJIA
# L3RQHFsVE141FojccKFpHhF/5ne6qAv74ZlXz0DBxstgx/acUCxqN7XJSVZw7OHN
# bpF3F3KNv1xOpN28rh+4Qjzds4TKQ+de9OEVJA3ZG2QuUqoFWXE=
# =013M
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 08 Nov 2023 05:22:27 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.297 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmU43RMACgkQONu9yGCS
# aT6DURAAlNjp1I2Hi2sO/hvlYcY6vkZHAIDof1SXqJkthU4Chd8fvinjxbHTcuRd
# vYGBB/u+fTjKiyRYFYiK2vLVQsD2YBIuP+bQtK3v1s+62qarGf+ahbFqRRlHIoRR
# dE3rglx7SMITaZPdq4KFuC1etM206+JR0yU7lTcdLocNQRmZv9DEnVTq6SGLebUB
# C0l+CaHy7F1yn1uuBVJi/gJH1+obTHyAViJzKY38E2Nevq8a0rUZd6V0xfGHUFue
# x41NX+pjUkaAyH8qKahFxdIuabE/oNBjt6ZqEmceu2bOrjFI36a3r2/XYfqNxkD8
# HT9qEz+jY0ig2Zj4TdGcjrm58Ck3ZjTS9RBodeaYBYlqz/EnlR8Qk7kspfXGACF9
# iy5WcL0iSMbC3o5dy17k2Dhh6G9ZmhLlpzXuHlLvfM3U1dlO0aa48LhAO7MTNu6N
# Abdyfqv1q4tSqsixUyVe2MQqAoZ7Px1FJRq5l24xvqKljNKFOgBnw9sjKfcRfG1K
# O2F1dvEzLjFNxn7P+iZMfdoyg2Hf+GQ0gtLmq9fK04uAGW8UQRu51efJmujLZ42b
# XVeAI4iw+uR1bFt9YI+WeAx3vg/lzP768+2YPf0zWUDf2k7RORvnP4XUZbddajet
# fhqakuVIORwc53IM5m2XtMs7N88sWFrprbqjyoUPJYcgpzQyyOo=
# =0+07
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 25 Oct 2023 05:17:07 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.295 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUOpmEACgkQONu9yGCS
# aT6vSQ/8D3yjJUYiUnHkiSzTMZHAtwR5qk0jCsqw1Xlr+XVouGCG/wpk8z7ckT6W
# 4gsG5+QvuB4SfWXmbIn/rPApqQdQSiTicOfHrev705v0U+ib+kw1vgBKv38qkOlI
# EZKuo7Ir1vZUnqghw9uIGperU3kEAt2EvWK37EBryukDoxbzDGIctOvAN7KMMbAJ
# jPQciVOOAJrNNdgPOSrxs1OCdAkEYlDaNuBZ+9j/HjNQLB9KtdtsJ50gerCPA4rS
# oKpZhnx9VJYXI9szor3T7q71iNfpJeL+mOrnpCSFVAFCPkesXQ+MG/GdgJJQDCMJ
# 9VF12W6rpqVcKfYFdPX9WevkqMfHRpE4brotDQx36rpUwVFcP7HClJ2zE3p36QWV
# Mfu4O31ZNkLUF8SmFXc3JXVyrwe/ARiha9nLH9VKZ7cSHoYUKlO4NeSGyHjz5J99
# RErBGpea7SgHTSLk30+sHaB3zhdUZyv8ej++zjTG9QA8bRbMp97I9psQ7FWhWDng
# l6f87mdta1X76OJJPkL3yZfbiB/M58e514ptbDNhu4cnH/S6aB6I3K5IYVtfZI/9
# zESuavKEUks+Ng1vBUGsPGN/eHDaPWUkl7HewP7WXRDOQUjaIX/0saeaSiUFYNI7
# UYa72hD9fKMblkwxIl75ybI/WZRgw9fyrQeGG0DfX3t6kt6BhHM=
# =bQT4
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 23 Sep 2023 04:48:33 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.293 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTvUuwACgkQONu9yGCS
# aT7LpA/+N7Em43G700yL9LlPAwa6xWE22OMyidakDJfd2pZ/yfi7/rsdCKMpPi4o
# Y+jyax8jj1V473rAM1emBUpy8EMnJD+0Fh/279rO3C0F61wgt8QLU9M+8bb5g/lE
# IWziYXdugRoBsLvp22GYlNT1s/EAd1g5eWrUYkPaL0nZe6p1eF+rFF0+qUCbY77q
# q3jSh3SCeGPn9x3IGBwD7v21dA4ZlpIkbie3Pd8ARSKfeGKKaiRSVNH4xoEcimFt
# 6j13d0VEdJC4Ew5Ir5S0oFHaTsYAR8EcKiJoaPsJ+SAUNh+RH2v3D+t8+oBbXkj5
# JxTRwohL2P9MQAW/xXrArwuKN4PghtJeE3xZGjkwS/wJzuQ0oqxfZwFNsU1p467O
# KkInV+soyD9GoAAzpbGO3GwgP1mybUOpLzS5ERwn43yKgOad6XjYiTw7PIzahgJ7
# gvBrqqOQMFOMrPoLhVzhWnUP9kcVSjvn49HJ9blX0sg5ShDra/q0bs8l9fSIAJnv
# GBZkV7CyqoZNULXjG8/jqlzijf5FpGwTX4mHJ1n2M58CskmXxqRt2bP/KmFzn8j/
# ny3aVIN06c6VTNZ4Cu2h9CC1T4ZW0CNteMzweHMY+0PU8Y3BA+XBQVnQ1F+r+TF5
# hbSxiPB5uYJJFfTkUlf8QMAfC7h1pbxgCy4YsJ1QlEt3Ai8ypo4=
# =gx/M
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 30 Aug 2023 10:32:12 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.292 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTc9ZEACgkQONu9yGCS
# aT7IMw/+LYTds5reVeXvYpOM3sVuLYTDcij7wC9lqkuGQ9Q3Qtx+joPLznWtMsIQ
# 3GU6SV4IyB7clAckolxQBzcqAMDZ5yEl2qEKeQGMw2X5dR9svOsiTZCuRS4anCMZ
# V1N99hmN7RYvnnSdqcixOyhsyF3GsOJaSjKwo4s306IabKqyi5LFj1FxIXzrP2bt
# /hhJSgKtJ04CpcdlKdnXPGtjNwm6+K9H1IyJrzcqA0PUmIgmMVi4p+TL39H0o081
# hKuqvRZR/edek/DToNSpLltCFKPpy3PM7h/siWbJveqHpjim907ojxLbEzConDw8
# cVIOvevsf8W0mmly7B1jEW7yojWzUrfMY0DDMoBV3xT1EkIG7wtxfGoGVVIqlIft
# qe657kMuFFYT3qS1SoCfBP6nKA/jCZsKxe9enaEm7cD3HHFE3vcjHmTA/4/qvRRc
# mJ7M0X4qNosJ8YYxDeY63JWSB7JMOQJ65GmdobaJkTiHSca1prvPd8NBVuDBV2d4
# pMa1prMvPaAQZihasw/xKiiRc2/fMd8wCUxBzrlWxMtoeEhKEYXBiPby/GcMz2pp
# HDW5m4vz35vgaAdYbGu1nFFWawc+2ielH3xedM9Mqvb7iU0xDPf9awragTFPjvbk
# O7DOglpI5zOHsLjHBG7G7xKQuumUrErmJb/lQSKnTAVJaNbaIiY=
# =WEWA
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 16 Aug 2023 12:13:05 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.291 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTWBMYACgkQONu9yGCS
# aT5fcw//f8IqgXhnM1RmdENWcj8Yttld1jY0L8+z2fRvkzmuqFJAnOuTEP/BV9Zk
# iMNH6Hg5iZh/ajGyW4OxsWHvaDNyZtpPOgNtQkhHPPDq5tqAgg+8ZgPlZkmbvnGd
# askxaSJE7OuJOfG193o/Uf0CR/boSIN1ioIu0vumqhrP2NUbe44/PLeSB239ZdGy
# nIaBo1JXffOH8P7kSS4E9NSrfoA9MQEuJgcYPkc1c08W2FWO8MftM/hdQtXGwbNC
# LCy4yGc3PN40MT7tOsXE0w3P+ZUXfP6g8NgHooRKuLimSiAYodLgCwnvELZ/Nsg+
# w1TPDxbLD99te5J16GzlzhN4+9BUtf2qq9ZgiJQ8lmKaGc+hAMRKF2h2E5Qhla8R
# TJubYFjD5yilANlRumVHMzNJZntROw0hG0ZIX6An/1QM5JAy7B736jI6jt+RZFSx
# r08xhBXcO+m3s2Vc2OojJFKLot9i0ugiKkTuQBZsBFDfcOtSrUUarB6Vz6wZvCY8
# sojQOS0eoYb+2GlKJ0UzTPLEHrCpusRkEnv3QMAPfTkw6vqvkrYACfOEbBujfT8e
# TtC7wuS3beULYPKpObe9HrpCooOXX8YQFXyld5e5iBINXwt/UT4daDL85BbMsPEu
# MPaSKrTMGXUsRoOWHiuPumT/MDE5LBSCqhyi41k90R9qRW6M+Wk=
# =KuAb
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 11 Aug 2023 05:52:06 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.290 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTSgNMACgkQONu9yGCS
# aT7WJRAAne2EBFiKaxX9FLoGJ1+YTcx7QbG1kbxE3pVxSVRRmrGA+9D1L6p1bxlw
# 6oi4l12999o+fL9IZMfKPESrkU2lGeFc9ifwOkDRc2JOpn/Ejq7HBQ6xijs9TTdz
# X8HbHWUWevwGZXkcAbKXDJ7D1y6cVV6K7UxEe4eKbmbpHdaOfS1/KB1WDlfq2pIh
# 32JVcO0+tVn/1HjZNvNRV7qbsnLVmLH6vFEsBhOfSlaDU6Wdi5iF2B3stg7+TMSz
# AnVKT/Gv9LIHse2dmZlcTN1xeGYsmYXlN1JHqJ58X8Bsa/9FARxVDpOUxOlO4B2M
# A4tWi6SguIMeseFBo9iwDFvRG84x7Ht1CoNiTeX5TeBNI+hkcuXMCxKlzdc5JGE/
# Pz7+ryyWreW67VSX4CZfd20Ppm757dZUQ95MacWhhcMcm7HpmQT5dbi0ijHcJbBM
# wvcrU/XGGzAj44yFuhT2u6c0bFLjTn3AdsAnItadYdoIFI6J1akHXM8TC+p9TgW8
# T5D8M+6zDeHJQaQVwhp2Sp2Xjxbp/4L7Hh0tb3YfWcDbFrrWKazl9Bl0D6bvAg0g
# UkPl/yoYPjWraw1SGCegWsHkUVxGaegCLCYRUITmZ+Z7Cajdm87G7MI5wrpl1H0g
# YE8H7xyGevPMsIySdmkU1WGdnxPPE1dq89ZIKCJoi+lfeyI+xd0=
# =GaK6
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 08 Aug 2023 01:52:19 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.289 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmS+sQgACgkQONu9yGCS
# aT57rw/9EP/+Qt70LPLV8jzDPJRaWDjD9Tbr+b4vCL8TkU7gJK/9sIWafM3RlMM9
# 74wwP5J7Mmw+91tW2Gl89gapfAl9Ax5SSwWYXdAM/SFwLHaWMb1ylr+uFwxWLeQ4
# 3hqxXO/HhgrIDFQPi9fp1VUorlOcOaSUTPA4nB3PDVsvXOHODSdq08o7Er2Tps2L
# lqy7JtAmo3cVbTP5C5foMBLJvRjk2pK8OpNVswXfe3Mc/KHlTLFe8gCJYJR7TCuH
# mdGdkxGpsDdlQl5JQdekAFUATBFR5yl5iqBl1lo4yaULoRZP54yPDWDpDm+LG00d
# nW6wfCpO3+GW+UszMHg0pGqkrYkZHQ6Tdj8fUvEf+Ykmv9aW/itVoT5BTruHItvi
# 53JyurHTZhuVlToHZYRuJpfOnUzoTptOqQSYvgEDw+1mRu+VjhV3SmzVndf1DP1P
# AgSc/87Y+aeC9Z0NtTNlMUQPlzyE6nIX13wduHnbOawdwhBCoXAA6aFPRPe+A7gr
# 2s8qoajmdM7vE1h7O0JsiCLRk6CFQZpApnGSfjz1uYygDOIArKoEulA+bkBJSOUe
# h2UTtjsWVY4VhjN682DG7J2wsfEMogy/ssFcKDGKHiORV0t73uOM87CW35wU4Vx7
# WSYONO5kuClhnoF+BctWgKOc7xAfnxkoxvV3hEdlBjR+/kOFjhQ=
# =/2cy
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Jul 2023 01:12:40 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.288 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSb7KoACgkQONu9yGCS
# aT6s8A//U4Q/1LMrkXiew99gV76v0LlFNuXEVWkd0VqEdeK+UG86gLcfjZUaHmtX
# Jx0nAZ7GWvn90ZaCNgN6PrKQ8LSeABOCGcpdx8cvLxoSGoB0ipjVcwddocAjOIzp
# ly/+1HhC0UadE9NZ7vyaCiUZ3U+0Sj22J85JZz+A4y1FwpYbXHJclGmmmmUg4MCU
# NwBUiu+2ad8D7vR7a0yiTlsdxBAwU2LoEdysteBv8vDHB+BXjNXC0jpBhXsvaaBd
# VN0bav9XWvKHN73CMcWW8I8ABSirJRQhdGC43BMNjE2+I3KIHjOzgqALOvfd9eSJ
# Jl9ztoqO+tI4wee0ZIQbobJ57vgqik+oX4eTGxaAfxD1BgqtuNVaDDw+3Wg3pgpP
# mRdbbfUixFR4tP0VsuLN3b6Ff5q4nhq8h6ZJ0I4tiSRL6K9CNimBKhTh1ECexDPr
# t+se4Zr58KkgrZCM/ERrwn5NvRcjF5PuBA1i3u1DWecHptZ6FNAwHSKMPFM7CoCH
# FTyNikDe6FCtzA2gHkj85bC5W0QahU+SD65OIv7Ziz6SOLKu2HjLYxQbcW/1uCW0
# Nikd5nADhOpDAxLvb7Cjt7Gh1GxWOIVnZaAFXh+KCVT9p/Xt8JimXvRTdSN5PGkp
# Mhg525BLTdXHQPr32IHY3gbeRbiAMCBK/pygPQ2DBKRVS53jkyM=
# =RsRd
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 28 Jun 2023 04:17:46 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.284 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmR14SUACgkQONu9yGCS
# aT5twA/9FzPtWeYCa9WdaW3YrlwXAwUSX+Q749XupcGbrXS1cljiB7XzvSQ48Ce9
# FrI+b4UNRmq1sjBq39GMVTCpVcis1PhI5uthvP/eNIazFvAb8Ksidsv10cGKtmi6
# dhe8+z6InAut46npKt+YHLTrgu+rkQ7nWk5thT52JLD2VsTf/AwNvy2wDVrtpwND
# XldYW/jP6GErmPXVdy2nBzP5kFKWpd6DIVrnKrP0g+G1UF6mV1mg2Bt9aoMyWenK
# TU9cv+FwAr40EmPSn6ooJbo0oOgJrkOidaoJEIgzOw4MWv/lNd6dijuKlkfKg56s
# elIa+TAlQBkkfXWNDSg8RCT0Im6iw+qVMmuIUvn4Y6zyFhQS2kBPZHavOHrIdYK3
# HKkEjl1l24z/k7HSkPVS+FR7YxF9EeQunJBJjA3NGLx4woFVoqCgCp5C5cAyC1D1
# lVE8lAPq/R5oIPgsL7WwYCdwvlnoA4R8HFmS/53ySRxQ839A0Ea1vQB96ISPdoGk
# AxU1DarM+BxLQbYVaW+HmDctox0wlhV9pmlSmRNzGDno0OsME9e7grUSxBC96ogf
# GFFYs2zTKE8y9/1LzBQSrJdXHjofOrupIEVHHcb8Bit6tuQ/hAIYl4erzIrJUc1e
# c0OuIcevfYbyUFYzYnWFkPWo0akRWcAIUKba5rzQV4lPpCGOfJc=
# =0ViV
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 30 May 2023 07:42:29 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.283 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmRkmvoACgkQONu9yGCS
# aT77dw/6A648P7TZgPEqBR5L4aG1u4GC4wE762PUb5YCK1XEWzgUdVPXrcRM6+r4
# ntoKlSJxveJh3TYKLcUAJWvvIt2lbOEdQTb9BS2ALoZv35q5J8Npw/CUP148Vy47
# 52PQwr4M76+WTx8bfckrBeVPHyhgNjFtFjuwg1TLfIvo6pGrDPnuNYo57K1/O38m
# Sid+eFrGBkOIjUVlfaStMIP9RVZTUHpPWHWp+cmqGTDK3B0m8BkoTMXM0hLu/fJH
# HPivMQFnyRNa0ZZAe+iQVmUjiruSPbgqNOAGSqTr5FxxSrZ3ZUjvtI0BYTA7eo7q
# BnPbRHpuRQ+YOnDK0Q+Ps96DDNALCz2j8bXXEjJePpOrqv8IoxU8kGx+GVcbnQiJ
# Bd6bqZwXU3uPN8VLTR0KtfypEH6ELbBrCXjeeSw+RQqAgsdEGSbVSgfBtISo7UMt
# iL/VFwl03qdm4Y+Ww544kNMrtDV+Qmq2MWeP6uHzx54ZH6ic5rFhLGamHEuIUg54
# Ux/9dLoByzbVOEMS5SHaqaxcLd/Qx0FtUq02rhsHeV0IEFxviX4jPRet0kn2vVru
# 8o+Vh92K+gfNW+zT47GPeTCBRIK+YuH2cwsXJRucGkE7IyDccgyA/v1cchZO9xoD
# oetofMcWiZi3QNY26EVuYA8SlIwURWkhb3yTbFoOx2+jQ6JER6k=
# =VSYH
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 17 May 2023 05:14:34 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.281 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmRBDkEACgkQONu9yGCS
# aT6QQRAAuMXhQqInTov+2CjNyHlBGEIdl4F+ydPRkJdr+3ISZ/ocqxXu5ta59RJW
# ohyDRW7B/kHRomHxeh/g3fkR2EhfaigKgSdohUL1e1CUJgmAYqh3wWio8MH2NZKy
# MdNOB5oYKk7BPSBY01v3jLAd1B4Lz5HrvlagbQ5onasnk4+pNQKxG+TjfVPthWX+
# 3PZRS4t7rlVXCqPt09fbpaxG2Xr7OjelmZe3KtUFYfy0f+bZyQcvY4wn/jSZL9uy
# zIHQLCUevYwndgIpswjt6dJl1JittV/977hyEdu9nS1bcqVttLLRriLqpefjciza
# jHNwrWBkFl7G+KeTA7baYW9k0TOmpIr4ROjyeto6u9TEIlULvGzApAZfm57/zSt/
# CzRjkL9pSF9KP1VWDC4Wyx7JRUliBYB34esPVxqXUjW+idj4RII8ZxbacdzoICXT
# U+Je93RR9gQ9Lsp6ESBj3CnkjqGGWsKGZ+JUw0XXzurKqg2SCcHmIkIQ+2EFNJ4P
# 28FTlfnISxhvmvJnLXbecKQvL0qacWD+5Y8JidqlB9QCzGhN+T+4CRe3rjL7TKv/
# INzPF8h67VCA986vafDpUXLWRwhdWjea5gXOhukUsYfKbt1k1yjKNdr3dbkNMnsh
# 3tfJB7xgVcvd49sMDTwCN6fpJTLbj9kgVYpZcW0sHFQyLuztDZs=
# =TJcb
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 20 Apr 2023 06:04:49 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.278 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmQUF3AACgkQONu9yGCS
# aT4OSxAAswpeK9OJvLyqcaC/ee6e1twIqffN670U8TEIn7Ys4BnCuD4v7hPOOAOh
# 1VUFFFAi614G6D3Em4DZGZaTudPklIaHY+iIYVSUMM6N974CM+wMPgMpQzYeSCqt
# Jie/thl4ZVL14NE3tqIFwICEyxicU/1+YwykLmMOI1c+jEGR0aPSiBeuyie3Bg/3
# NAOm1DRgv0XRtJWg9APMUC85qbhQrO+Z9irfWNlq2NUwj8H9vJSZFGVL2qINGyMU
# F5l+hGjVJkXBO5y7ov380EdsXKLijubGUQMYOwHk6xK5DF8zXtD4e8l0tnvyQHtb
# Sf0/7tIW2w0chVHJodvmcpdGzIU7XJwPlexxAyiaDsh5CA2zzaqEZwcT+wFXx5cd
# iF516IuR64wDfYz5MhoFeK4J2H5qodQgtQY90PChy4+aw5ITIjZEGM8AtaeyHKQs
# y8uDx7O+RIzZLGsBLZSuMilsWlicko4eBeUDhzoIt8SOGcBojZ1b55DeAOnSw5rN
# yKRk3Am/m9utPQKpBWJkUk4ou5Hr02vMYo8IFOGoYUOzV8ZX4/vtEnSJLBwMtMUu
# DQ8PD6VcUS/2dbMgd8cGxPJ8DCN5g4BWEQnFRDg7MfHrNW6r7l256uxkC13s89cF
# UpUczRNwKF2ZkJ8bnQ7YD0Xa94tWtcKY/Ckebz0JnP8VgwgCaSQ=
# =0HUJ
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Mar 2023 03:32:00 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.276 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmQMnvwACgkQONu9yGCS
# aT7Wnw/8D4Y0jHf5hAU2MrVU+8aBdqdJ3CMUuqaq1/zi0yq3cWyDJo7sU5L3Tpdl
# NBDdEtdAPDVK/jZ+BCtgtwccTG8Vnt8uXsVpcKJ50hBPnWfcJ9g+asrEOnIN4MI4
# 2ltYKfDxN/n/QB9j2V1s+Nj5+VT1oTJQ112ksvn354REMO14htiSZtX7Y9Av3qks
# PhHf6R+482/a59zSKM4F3HMGhcSzvPz56FT736MPmd0hvfokDYzSmNRUWx5yKgHh
# MRUmS//yc7Q24VSmrwz4PlOqolso0w2FiIxUz6i2/O/vZ/qQiZMTlanSC9cQ3gx1
# /zEGSxMRzCzTS/huPIbldSIfaLmfRY4zHpnIuKsqT6OSq4xg5BXO1p6MuUkhN9E0
# FB8Wl4xPIcqZ7BMHNYUQIp61tE57NPKzI/WiAaqgDLQPKLDsNp3YOj5aGvxFZ4lc
# beeEIhv3nD7r4+7U1j+yGejdTigOU2LlBVyjjir93pDy0RsgjoGdvzp0pnjZqsPG
# An0R/2PlGINwYX5oROPt/lr6tFbshYKB5QfcMxCJ1+MN5h4T5Nc3SJsuw/U92iH/
# MSUb6oDOsbM3FuqnHlVGJu96ttiKNO3hz6IjC1NtaWFUCTtImbsBxWNn51mJ5Svg
# +YZhzyKFya40pXMQrT3dSV4NxPnUBqI65Il2Lq1LD5zLjZC2eRg=
# =zwmc
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 11 Mar 2023 10:32:12 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.273 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmP2ANYACgkQONu9yGCS
# aT6oNBAArmqskeKikeebAGPOtU1quHBGnnbpSOd0SFZVTLi0N9YD9SjVpJ8RoMTT
# PCPz1yc8qw+1nFL0DQ+nJ/hx7SK9mfGpBB5CP8ZNjI35Hpf7RMmftwXGvEp1FAMX
# 1xTUEB2dS2YH9fp8mZYAEjFAQ76XZ8u5fXntVPCcclJIbxMkcgvdRUKtWkPwK4vd
# rJytrqPYEe9UyPWU3Gw0OyRNNFpZcNB11ZbOWeCpe+G31naZWHiqcjzi7hF9IGsA
# lzElk9pWpMW/WxpPfNkxyJEW5NfnEJTwjaHoV5LF9jONOX6lV5e4hRr10KkrdnxM
# rQB82kN9JC1+r+5Zbkz1Zy8Tmas/aI1Gk1oJmZufi2nhP06uxsRVV06bqdg8MM0U
# z7giLCwj7+gIk7LXm/kmVLvTVuTGMXdhfUaVG1OKxcp9WjLIwpkDJS7raEZ2Iyy3
# 5/IkvICt+cINpc/s/eO3u9CaRZVCb2vUYVRxY4sc9j/+P8U9j/N3DmbIqYD8b3ty
# sO20M/DvD2Ra0PD11QofMqg0fegZTTCvhl9hFPu41gXHTKUlM9d5QqTZPC/JoJ3f
# vd/BoSvXuzxJHyljsQ2W5BUoEyOKbM12EBnbiuxPwospfy/U6y/nENe9v463bWFf
# DuZfaWx6+I3WW5mZeaWA7IMKVmfFazhjhztZqzhd1yUCkVINN70=
# =5lII
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 22 Feb 2023 06:47:34 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.272 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmPgoxsACgkQONu9yGCS
# aT7P4hAAiY1TIECbi0kriTeuRmi/cGkU1eo8ODV+5h0x31cEObCZnsvU6v2LeqOJ
# X0H8U3MwjxyVYoK1L1SUBClgPXqBq0jI4+CrjVSQcl8kWGKhUm/JXzjcOC6wAlB7
# M2BRD2z7M+K4Mem1Q6eV7UEuEBPteLquP4xPlaXKkRAoeWKXcbiRM3ns5h20Acmi
# igDqhzLUAiAIhL429vPAOp34aNDmaZzLXiMt9p0mYkDFP7I904FrlBAsceJV8NZ9
# 6oxxQspkoCf8MjBGrV6JcFwNgHjCHM+zXHWhROCE9WL7rknCJidttQKsOtzNE6Gx
# pFF60qFRx6JVsvm0D2lJpEW+ExdlcQ/aacByy3fXajkdyrsl9sTajiw0+1f6P4Oq
# hX8U+HianG4G1HgpOAUeZZBcTn7k7+pdTcogLaQW5Csch2RHMmmnPMZlZqudGUxD
# yJiyd9dRIEPOa8CAdCzI4/xgjEgogS1snS9jRhJ0rwRtSqL3lLrSRdeFWbVjgA54
# HAF9dR76Y4sbmWv4MbUPK+lvROvWv/NtLeiHXCJCGsxWdcOYQTw8ASenaK2IQRUF
# 1ows0gRXX3Xzm6R8CvpJqT80ta1rUfD3INycV4kUHeRUlVsrBtu48KX325+ZUXD9
# Lvcbips57QvMMigROx6HpQHbmA1fe/42mZfhf36sgzycAmIzThA=
# =yuwn
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 06 Feb 2023 01:50:03 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.271 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmPPdq4ACgkQONu9yGCS
# aT5hnA//fZ/v8ePI4NpgcbHlZjBiYJEpCRJrbKG9ruKJpGplGUGsPK5qupCooQSt
# a5akzjXfZBGgVYYuXc5GxS5Rnk2XXYyLzJWxgrq1ZU+tnZ/U2T5CJYULhw/J23JM
# RsixAuXdDoHmNSTouye5H8cuouIHZMgPo9r4JXF/CWjF3gHu65s3uY1WqmpxbL8d
# Bo1Krrq0HHtvQCKeSuSV6MlRSl7pjC5Ooqhb0cmMCk/ROt9lejSEKIrCOdjQtR/i
# nneiwSA267ZmihRD3tnWpT+5zkFWiH3LME5ANDbC+VIoUyYeKN6jd8o8Cz7t2v3F
# KLBhxNtjnjaNKaF9LztWt7qCRfsrs/Dhm1ZvCZWcaWmNoNyYbW+S+SGJy1wSLyx8
# h9HCvYgXfK04A/CBXuNqV4XYJ2vTQ4bCDmJYalxbiibK+9Wv8XuemLFsLuERg7I6
# pY9hdl24rumdlGpI6J27GwOzC8iInyjprs5SQRTYwOqGcQ8iiAf9lyEVegJ8WAyx
# Y2fCK9zt5lclT/fquHGv1+5dHcFLezCceBpndVwipVoIiu9o/Px0bMknScP1ptnn
# lvLida2R1yJ552Le+qSbAxQTfiby4uRzK0bupbmpg3/wLi8EhWi/inh4Hii0GxDI
# /TVST9OjvB8SVervqVXpndWKKjqy2McW8qXHLjd61Hp5SswWKZM=
# =W+3p
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 24 Jan 2023 01:11:58 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.270 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmPHynkACgkQONu9yGCS
# aT5AtBAAsdmYCYkmKZsRcS1EUTqdwKVN7FDILDcdMjfmrSp4ZDliaD1dUc0EmDRl
# yy+aNGCrhbuYACk9WdQsSUrUIh1dK0H5VsioB1m0cjCgifbNjsYqjYWK5ewXKUyX
# yjc+NmY1HVUFQDLnYHJxSbnB/o+nobWjts8nGuWHwQmoh7UmFe7lvMqZg753x6Bw
# wCiaC1DrU3aKHYK7IirdWgOiDiGia8DX1nX6PmLi6JTsXj+Io0i8PXKkFzANDf/p
# /rOyg7j8NOXIQPZGN0Zu88QiMWsNk7u2bOORZgtFbwo7r9BFbzXfWk/x8QxzDX1B
# iH1p02XQvBwm44xGJZKiWEY2nZdw4mpyzLXZNOL8V7vn9xhT6HDksVAPnyIkU8Dh
# wsij2r27x18VI9H7sstvAHvIyg6ihmq2E6WuC4W74tUcys7MXxCFc2DuJzMMocf0
# 7LMTmx3/oUHvuM1riJ9STo9mzXbTmfNd6hnqRnFgGKiGGhOE+pX//RHfupaXRieQ
# Rq51ODFKcJdDIM7hxeyPdACYF/kso8sNEODCgQ5/+3opel1mzLdBJ1T2bV12DpQe
# ZhTsESPCVSoUAjCnC9Jje3g0u3qztClYq1faHOXtnjykn9mHmmedVwvdfJL/sOsr
# ec7NgqzM9xvMQVe4CNf0mouugaLpn2m6uQDTu+GWswRfEKuCx2Q=
# =ksam
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 18 Jan 2023 05:31:21 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.268 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmORulwACgkQONu9yGCS
# aT7rlxAAqr6GK3Ei3JnP+/bWtrZxOZaMJ3v4d+o0x680B0MYPiCl8O2MGLOTFh5S
# TLhYsYEddu+xAmLBLDFJzylIPr6EDKXBDS8i4w6/WWJA2Wqvk2vp2Mculm6OeIly
# Np7NycSvqpxxfWCxqzilUqdu5pcTGbUB6fM+iCXIeDxLhFN+q4gztIBSBUwr2fHI
# Okek8QOPHQGT2dQQvQLSo/41MQYm0g6d5U2/mvkRysz9esUKB5TqYBxBkla6hb8s
# A83fZ/TGZwulwyJUhJVbEGsQ0Jbr/uzRS6LrRkAFYMp+FQN194w+2Xb/AN6xiKij
# miVZxUgS+tLbuL2CZ+AjEVlkOdtQMLvzn3GNX+iYAMPnXvPiLq6cVhCvm77EM6Xs
# gQ1fc42REvnLl03lIvYcIBNG6ESXCBzLaX+qHPqPzl3OPcOv9VYVMEzQ0DVXXp+I
# +3fzLoQNLbtV7OSQ17d+Uxijw0U2aXMemoPlGGAxhntIs/Pn/NGhGSKmYed9aImp
# 328YgGIBvaqINrAuenaXLckzEcxXRzfb+iM+V7yJ1gE5pam0eppbbuH2hTQTIzqS
# PPqWdq6fPSjgB/RvRURj36bGgUIMdei8Jt0/GXDWgIe4qgstDJKAQ2fQuiVVOfI0
# arMRtQSW8wTB/gOTOSgGpNiEywqK8mj7EtutOFUdGa5IAdloMZY=
# =+EDx
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 Dec 2022 05:20:12 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.267 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmOA8CAACgkQONu9yGCS
# aT6V4BAAxRZAMCEAeeruu1tUNaZHWVmZkpsawlC9c4+lavSkniYbcXenkmgYBBcs
# 4GCklhZawUnDFl9VqC9xrn39aRdLX8jTL5tFSNlN+qbQyZ1SkEgvM2eeXHBzBfWP
# SALX15eLoCe4p4RzhwL5nlZZ9Z1siSnPUKO8og+j81X65DpYrIWRmimZthOY733a
# u6emEYrC7wcpuO9DyEU6ZhkHrvrBRSeaSELeUcShwfK4vlAV5FKSRUgmcIDT7mTe
# gtLSh/qlsEO3t0UxPckqG6tsgDofuK7o04YkLzV6y2TMgRoLSJdzn9bid65e3h2R
# jT8FcnBBxJgA42i/0e1UIbYgIisnt2NG1Tq8OrrVXe6N5eF7KhoFOZXiZ+Qq0xam
# WbxPe6jZu1cgrSh9tV1xOX09By31uzc3C6zAMwz/KQbXYcaDQeL/krl+IolDxab7
# 4fIHDGpmIS26aSr2GMWs9z+UDgIH5KOXEweLCsCquRIEwLcpvsPMnq7fnHlAspMX
# O393TY53BtpGIHYGhHJuWuLFIH11Rb3RiTJxU2lsZzHrETR/THirf6T8a6yYWwCo
# lY8tk1XuHQ89X2e+TAsQJ6LJqz2tnHPo01zqhsH7wJKCmnBE3VMzg1NeNxhW3q/i
# CEpoZYF3NhHSRvg0Jcj/DyGI7zuMGRyxprzhtso348+rQ+lYhVQ=
# =Ufv3
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 25 Nov 2022 11:41:04 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.266 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmN9w4cACgkQONu9yGCS
# aT7tehAAjYiifqF6t6hdfYK+hzW91JMl8Fqc7Xmt7OnV/j5S6GfI239viCouQIpQ
# HlrynsxGzx4C6x3+R/O1EmXwbf/T6YT67GG4ApF7S2lXhIGiEqbsdBQg3Q4dxdLO
# xABQEaevdPZcVpsFm/m53kHHas1JBopB/6NXLLZDx/CLOtdltP7rpZ9+AbI6mJR6
# REChPegPjcl6V8MjeAmN5TbwhsNYcG50qAT/H+7tljnEF7qR36Kp+zj/JvetQwyj
# w9JVQYRder/J/EM1FhzF97grI73CY9Xw+y7JheL1nmZDFD0RTHzuN6sExEV/C5WQ
# O2e4Dv/764c991wAluUtO2ohb/Zoi/78nn93fF4R78Xkksa2oVVDcrC7s6o2aExl
# mwtXkO8qNDICbnunU3QnH6dnFOZOJB9FvulpkHZ3QFY8DflB+tFtdFnq20GCH7LL
# pTV9eQWqihSVh0UTOK3tushibdTaYoqOPZ/ZQXw00VZ+M4T8rwbbz/z91NFrcyG9
# jGzI699v4dWvcFnkw23/u7JmzgnRgPCCt5DrcdiXBnHgoAK9HIdneE6aoU9WiTNe
# 8ZuTQsLG0nexDgeNGSIX+j2tDejP6ffPxiacR6NbR4+vnwqSeScjvgCwv8FuiJaz
# C9YXaAXDJ5QNQQwTGdAg8dbW/24rRHF+9g0E3WssiBxvRey/GA0=
# =SDTk
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 23 Nov 2022 01:53:59 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.264 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmNj1bgACgkQONu9yGCS
# aT4ABQ/8CCO0lyrHTLSG/hmhXOaLkEq3q4sO5xI2hAAwaIGngivQpjR+qGicUxm2
# MmX9pLihi5uEpayVFM0Gb5+6NRObgUULAetiDk34gSqnWjFQksrS8WZdNzXSIq85
# yn3+1o87Nr+gOTGd1xighmRKw87Kaacqtt80MXBeTQ7SZt7ES7Oxn/I4zw1vjiDz
# 2nfUp+w2yWsUoQHOUGITe3+ae8QmTX1dwQhXf/z0EX8VqgGEKD7Sv6aSxZfmb4cL
# srBYw0D3bi5+cSH/auiN+rxkGQ7CZ24xsqaFZN4L5lAhO+TTfanp6XJAMAKFYm5N
# 1sjeBfNNDq8LEThqBG1RULlaMOkflW7fXAZuA6oGJTr1+V0MP8h79jniKSJ8kGnN
# xpprlnm7hKy0OazbRIcRBPim3hv5fvy+U7eiWQqZCOdYc93hTflzamXeu+OZNpsB
# flAJbUGDUniApKFhyXhEWr8jCz7oQvf2VzQmKRB6KpbEOgaEJ5S8Ls5pGzt3JqdW
# AOQHC4t4/EcyVvOBUcIiXYtnE3VQ4RuOU6bCU5soqDiWTYk1yeRWKFiFLpkzpMAR
# FjKBLFez2Dc+T09DXcXbJZ7V3t510hhLw9Pai1iXuZlkYuk6jJGZ/VMmi8txxyYt
# wChGDUcnv2W/Ub7hLSk9GkxtaXQ3zdLYVk2GtloCkuqorks8EFs=
# =7RS7
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 03 Nov 2022 10:52:40 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 3ea1704a92967834bf0e64ca1205db4680d04048 upstream.
text_poke_early() does:
local_irq_save(flags);
memcpy(addr, opcode, len);
local_irq_restore(flags);
sync_core();
That's not really correct because the synchronization should happen before
interrupts are re-enabled to ensure that a pending interrupt observes the
complete update of the opcodes.
It's not entirely clear whether the interrupt entry provides enough
serialization already, but moving the sync_core() invocation into interrupt
disabled region does no harm and is obviously correct.
Fixes: 6fffacb30349 ("x86/alternatives, jumplabel: Use text_poke_early() before mm_init()")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/ZT6narvE%2BLxX%2B7Be@windriver.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9b8493dc43044376716d789d07699f17d538a7c4 upstream.
Commit in Fixes added an AMD-specific microcode callback. However, it
didn't check the CPU vendor the kernel runs on explicitly.
The only reason the Zenbleed check in it didn't run on other x86 vendors
hardware was pure coincidental luck:
if (!cpu_has_amd_erratum(c, amd_zenbleed))
return;
gives true on other vendors because they don't have those families and
models.
However, with the removal of the cpu_has_amd_erratum() in
05f5f73936fa ("x86/CPU/AMD: Drop now unused CPU erratum checking function")
that coincidental condition is gone, leading to the zenbleed check
getting executed on other vendors too.
Add the explicit vendor check for the whole callback as it should've
been done in the first place.
Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Cc: <stable@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231201184226.16749-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7e09ac27f43b382f5fe9bb7c7f4c465ece1f8a23 upstream.
Commit in Fixes added the "NOLOAD" attribute to the .brk section as a
"failsafe" measure.
Unfortunately, this leads to the linker no longer covering the .brk
section in a program header, resulting in the kernel loader not knowing
that the memory for the .brk section must be reserved.
This has led to crashes when loading the kernel as PV dom0 under Xen,
but other scenarios could be hit by the same problem (e.g. in case an
uncompressed kernel is used and the initrd is placed directly behind
it).
So drop the "NOLOAD" attribute. This has been verified to correctly
cover the .brk section by a program header of the resulting ELF file.
Fixes: e32683c6f7d2 ("x86/mm: Fix RESERVE_BRK() for older binutils")
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/r/20220630071441.28576-4-jgross@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e32683c6f7d22ba624e0bfc58b02cf3348bdca63 upstream.
With binutils 2.26, RESERVE_BRK() causes a build failure:
/tmp/ccnGOKZ5.s: Assembler messages:
/tmp/ccnGOKZ5.s:98: Error: missing ')'
/tmp/ccnGOKZ5.s:98: Error: missing ')'
/tmp/ccnGOKZ5.s:98: Error: missing ')'
/tmp/ccnGOKZ5.s:98: Error: junk at end of line, first unrecognized
character is `U'
The problem is this line:
RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE)
Specifically, the INIT_PGT_BUF_SIZE macro which (via PAGE_SIZE's use
_AC()) has a "1UL", which makes older versions of the assembler unhappy.
Unfortunately the _AC() macro doesn't work for inline asm.
Inline asm was only needed here to convince the toolchain to add the
STT_NOBITS flag. However, if a C variable is placed in a section whose
name is prefixed with ".bss", GCC and Clang automatically set
STT_NOBITS. In fact, ".bss..page_aligned" already relies on this trick.
So fix the build failure (and simplify the macro) by allocating the
variable in C.
Also, add NOLOAD to the ".brk" output section clause in the linker
script. This is a failsafe in case the ".bss" prefix magic trick ever
stops working somehow. If there's a section type mismatch, the GNU
linker will force the ".brk" output section to be STT_NOBITS. The LLVM
linker will fail with a "section type mismatch" error.
Note this also changes the name of the variable from .brk.##name to
__brk_##name. The variable names aren't actually used anywhere, so it's
harmless.
Fixes: a1e2c031ec39 ("x86/mm: Simplify RESERVE_BRK()")
Reported-by: Joe Damato <jdamato@fastly.com>
Reported-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Joe Damato <jdamato@fastly.com>
Link: https://lore.kernel.org/r/22d07a44c80d8e8e1e82b9a806ddc8c6bbb2606e.1654759036.git.jpoimboe@kernel.org
[nathan: Fix conflict due to lack of 360db4ace311 and resolve silent
conflict with 360db4ace3117]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 128b0c9781c9f2651bea163cb85e52a6c7be0f9e upstream.
David and a few others reported that on certain newer systems some legacy
interrupts fail to work correctly.
Debugging revealed that the BIOS of these systems leaves the legacy PIC in
uninitialized state which makes the PIC detection fail and the kernel
switches to a dummy implementation.
Unfortunately this fallback causes quite some code to fail as it depends on
checks for the number of legacy PIC interrupts or the availability of the
real PIC.
In theory there is no reason to use the PIC on any modern system when
IO/APIC is available, but the dependencies on the related checks cannot be
resolved trivially and on short notice. This needs lots of analysis and
rework.
The PIC detection has been added to avoid quirky checks and force selection
of the dummy implementation all over the place, especially in VM guest
scenarios. So it's not an option to revert the relevant commit as that
would break a lot of other scenarios.
One solution would be to try to initialize the PIC on detection fail and
retry the detection, but that puts the burden on everything which does not
have a PIC.
Fortunately the ACPI/MADT table header has a flag field, which advertises
in bit 0 that the system is PCAT compatible, which means it has a legacy
8259 PIC.
Evaluate that bit and if set avoid the detection routine and keep the real
PIC installed, which then gets initialized (for nothing) and makes the rest
of the code with all the dependencies work again.
Fixes: e179f6914152 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately")
Reported-by: David Lazar <dlazar@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: David Lazar <dlazar@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218003
Link: https://lore.kernel.org/r/875y2u5s8g.ffs@tglx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d35652a5fc9944784f6f50a5c979518ff8dacf61 upstream.
Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:
BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...
On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
Fix it for real by disabling KASAN while the kernel is patching alternatives.
[ mingo: updated the changelog ]
Fixes: 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y")
Reported-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231012100424.1456-1-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f454b18e07f518bcd0c05af17a2239138bff52de upstream.
Fix erratum #1485 on Zen4 parts where running with STIBP disabled can
cause an #UD exception. The performance impact of the fix is negligible.
Reported-by: René Rebe <rene@exactcode.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: René Rebe <rene@exactcode.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/D99589F4-BC5D-430B-87B2-72C20370CF57@exactcode.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 4ba2909638a29630a346d6c4907a3105409bee7d ]
This source file already includes <linux/miscdevice.h>, which contains
the same macro. It doesn't need to be defined here again.
Fixes: 874bcd00f520 ("apm-emulation: move APM_MINOR_DEV to include/linux/miscdevice.h")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: x86@kernel.org
Cc: Sohil Mehta <sohil.mehta@intel.com>
Cc: Corentin Labbe <clabbe.montjoie@gmail.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Link: https://lore.kernel.org/r/20230728011120.759-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 2c66ca3949dc701da7f4c9407f2140ae425683a5 upstream.
0-Day found a 34.6% regression in stress-ng's 'af-alg' test case, and
bisected it to commit b81fac906a8f ("x86/fpu: Move FPU initialization into
arch_cpu_finalize_init()"), which optimizes the FPU init order, and moves
the CR4_OSXSAVE enabling into a later place:
arch_cpu_finalize_init
identify_boot_cpu
identify_cpu
generic_identify
get_cpu_cap --> setup cpu capability
...
fpu__init_cpu
fpu__init_cpu_xstate
cr4_set_bits(X86_CR4_OSXSAVE);
As the FPU is not yet initialized the CPU capability setup fails to set
X86_FEATURE_OSXSAVE. Many security module like 'camellia_aesni_avx_x86_64'
depend on this feature and therefore fail to load, causing the regression.
Cure this by setting X86_FEATURE_OSXSAVE feature right after OSXSAVE
enabling.
[ tglx: Moved it into the actual BSP FPU initialization code and added a comment ]
Fixes: b81fac906a8f ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/lkml/202307192135.203ac24e-oliver.sang@intel.com
Link: https://lore.kernel.org/lkml/20230823065747.92257-1-feng.tang@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit edc0a2b5957652f4685ef3516f519f84807087db ]
Traditionally, all CPUs in a system have identical numbers of SMT
siblings. That changes with hybrid processors where some logical CPUs
have a sibling and others have none.
Today, the CPU boot code sets the global variable smp_num_siblings when
every CPU thread is brought up. The last thread to boot will overwrite
it with the number of siblings of *that* thread. That last thread to
boot will "win". If the thread is a Pcore, smp_num_siblings == 2. If it
is an Ecore, smp_num_siblings == 1.
smp_num_siblings describes if the *system* supports SMT. It should
specify the maximum number of SMT threads among all cores.
Ensure that smp_num_siblings represents the system-wide maximum number
of siblings by always increasing its value. Never allow it to decrease.
On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are
not updated in any cpu sibling map because the system is treated as an
UP system when probing Ecore CPUs.
Below shows part of the CPU topology information before and after the
fix, for both Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore).
...
-/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff
-/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11
+/sys/devices/system/cpu/cpu0/topology/package_cpus:3fffff
+/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21
...
-/sys/devices/system/cpu/cpu12/topology/package_cpus:001000
-/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12
+/sys/devices/system/cpu/cpu12/topology/package_cpus:3fffff
+/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21
Notice that the "before" 'package_cpus_list' has only one CPU. This
means that userspace tools like lscpu will see a little laptop like
an 11-socket system:
-Core(s) per socket: 1
-Socket(s): 11
+Core(s) per socket: 16
+Socket(s): 1
This is also expected to make the scheduler do rather wonky things
too.
[ dhansen: remove CPUID detail from changelog, add end user effects ]
CC: stable@kernel.org
Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting cpu topology")
Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide detect_extended_topology_early()")
Suggested-by: Len Brown <len.brown@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/20230323015640.27906-1-rui.zhang%40intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 6dbef74aeb090d6bee7d64ef3fa82ae6fa53f271 upstream.
Commit
522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
provided a fix for the Zen2 VZEROUPPER data corruption bug affecting
a range of CPU models, but the AMD Custom APU 0405 found on SteamDeck
was not listed, although it is clearly affected by the vulnerability.
Add this CPU variant to the Zenbleed erratum list, in order to
unconditionally enable the fallback fix until a proper microcode update
is available.
Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230811203705.1699914-1-cristian.ciocaltea@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3f649ab728cda8038259d8f14492fe400fbab911 upstream.
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:
git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
xargs perl -pi -e \
's/\buninitialized_var\(([^\)]+)\)/\1/g;
s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'
drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.
No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.
[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/
Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers
Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f9c9987bf52f4e42e940ae217333ebb5a4c3b506 upstream.
Monitoring idletask::thread_info::flags in mwait_play_dead() has been an
obvious choice as all what is needed is a cache line which is not written
by other CPUs.
But there is a use case where a "dead" CPU needs to be brought out of
MWAIT: kexec().
This is required as kexec() can overwrite text, pagetables, stacks and the
monitored cacheline of the original kernel. The latter causes MWAIT to
resume execution which obviously causes havoc on the kexec kernel which
results usually in triple faults.
Use a dedicated per CPU storage to prepare for that.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230615193330.434553750@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Stable-tree-only change.
Due to the way the GDS and SRSO patches flowed into the stable tree, it
was a 50% chance that the merge of the which value GDS and SRSO should
be. Of course, I lost that bet, and chose the opposite of what Linus
chose in commit 64094e7e3118 ("Merge tag 'gds-for-linus-2023-08-01' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
Fix this up by switching the values to match what is now in Linus's tree
as that is the correct value to mirror.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 81ac7e5d741742d650b4ed6186c4826c1a0631a7 upstream
Gather Data Sampling (GDS) is a transient execution attack using
gather instructions from the AVX2 and AVX512 extensions. This attack
allows malicious code to infer data that was previously stored in
vector registers. Systems that are not vulnerable to GDS will set the
GDS_NO bit of the IA32_ARCH_CAPABILITIES MSR. This is useful for VM
guests that may think they are on vulnerable systems that are, in
fact, not affected. Guests that are running on affected hosts where
the mitigation is enabled are protected as if they were running
on an unaffected system.
On all hosts that are not affected or that are mitigated, set the
GDS_NO bit.
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 53cf5797f114ba2bd86d23a862302119848eff19 upstream
Gather Data Sampling (GDS) is mitigated in microcode. However, on
systems that haven't received the updated microcode, disabling AVX
can act as a mitigation. Add a Kconfig option that uses the microcode
mitigation if available and disables AVX otherwise. Setting this
option has no effect on systems not affected by GDS. This is the
equivalent of setting gather_data_sampling=force.
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream
The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.
Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.
Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.
This option will be ignored if cmdline mitigations=off.
This is a *big* hammer. It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration. Unfortunately, such userspace
does exist in the wild:
https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html
[ dhansen: add some more ominous warnings about disabling AVX ]
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8974eb588283b7d44a7c91fa09fcbaf380339f3a upstream
Gather Data Sampling (GDS) is a hardware vulnerability which allows
unprivileged speculative access to data which was previously stored in
vector registers.
Intel processors that support AVX2 and AVX512 have gather instructions
that fetch non-contiguous data elements from memory. On vulnerable
hardware, when a gather instruction is transiently executed and
encounters a fault, stale data from architectural or internal vector
registers may get transiently stored to the destination vector
register allowing an attacker to infer the stale data using typical
side channel techniques like cache timing attacks.
This mitigation is different from many earlier ones for two reasons.
First, it is enabled by default and a bit must be set to *DISABLE* it.
This is the opposite of normal mitigation polarity. This means GDS can
be mitigated simply by updating microcode and leaving the new control
bit alone.
Second, GDS has a "lock" bit. This lock bit is there because the
mitigation affects the hardware security features KeyLocker and SGX.
It needs to be enabled and *STAY* enabled for these features to be
mitigated against GDS.
The mitigation is enabled in the microcode by default. Disable it by
setting gather_data_sampling=off or by disabling all mitigations with
mitigations=off. The mitigation status can be checked by reading:
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b81fac906a8f9e682e513ddd95697ec7a20878d4 upstream
Initializing the FPU during the early boot process is a pointless
exercise. Early boot is convoluted and fragile enough.
Nothing requires that the FPU is set up early. It has to be initialized
before fork_init() because the task_struct size depends on the FPU register
buffer size.
Move the initialization to arch_cpu_finalize_init() which is the perfect
place to do so.
No functional change.
This allows to remove quite some of the custom early command line parsing,
but that's subject to the next installment.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.902376621@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1703db2b90c91b2eb2d699519fc505fe431dde0e upstream
No point in keeping them around.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.841685728@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1f34bb2a24643e0087652d81078e4f616562738d upstream
Nothing in the call chain requires it
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.783704297@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 439e17576eb47f26b78c5bbc72e344d4206d2327 upstream
Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and
remove the weak fallback from the core code.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.670360645@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7c7077a72674402654f3291354720cd73cdf649e upstream
check_bugs() is a dumping ground for finalizing the CPU bringup. Only parts of
it has to do with actual CPU bugs.
Split it apart into arch_cpu_finalize_init() and cpu_select_mitigations().
Fixup the bogus 32bit comments while at it.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230613224545.019583869@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Upstream commit: 522b1d69219d8f083173819fde04f994aa051a98
Add a fix for the Zen2 VZEROUPPER data corruption bug where under
certain circumstances executing VZEROUPPER can cause register
corruption or leak data.
The optimal fix is through microcode but in the case the proper
microcode revision has not been applied, enable a fallback fix using
a chicken bit.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Upstream commit: 8b6f687743dacce83dbb0c7cfacf88bab00f808a
Avoid new and remove old forward declarations.
No functional changes.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a32b0f0db3f396f1c9be2fe621e77c09ec3d8e7d upstream.
Do the same as early loading - load on both threads.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20230605141332.25948-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Bruce Ashfield
Thomas Gleixner
Borislav Petkov (AMD)
Juergen Gross
Josh Poimboeuf
Kirill A. Shutemov
Randy Dunlap
Feng Tang
Zhang Rui
Cristian Ciocaltea
Kees Cook
Greg Kroah-Hartman
Daniel Sneddon