| created | 2020-07-28T21:11:14Z |
|---|---|
| begin | 2020-05-15T00:00:00Z |
| end | 2020-05-16T00:00:00Z |
| path | src/sys |
| commits | 13 |
| date | 2020-05-15T04:14:01Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/amd/amdgpu/uvd_v7_0.c | log | diff | annotate |
| message |
drm/amdgpu:change VEGA booting with firmware loaded by PSP From Feifei Xu bfcea5204287b0a09dac71fa56a5d066d94d9bb1 in mainline linux prevents hang on boot with vega10_sos.bin firmware from linux-firmware 20200421 https://bugs.freedesktop.org/show_bug.cgi?id=110733 |
|||
| date | 2020-05-15T04:17:12Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/amd/amdgpu/vce_v4_0.c | log | diff | annotate |
| message |
drm/amdgpu: Change VCE booting with firmware loaded by PSP From James Zhu aa5873dca46385454d36c3dca31d66d7b64574be in mainline linux prevents hang on boot with vega10_sos.bin firmware from linux-firmware 20200421 https://bugs.freedesktop.org/show_bug.cgi?id=110733 |
|||
| date | 2020-05-15T12:13:35Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/arch/amd64/conf/RAMDISK | log | diff | annotate |
| message |
disable ohci to compensate for bloat. sad |
|||
| date | 2020-05-15T13:05:04Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwmreg.h | log | diff | annotate |
| src/sys/dev/pci/if_iwxreg.h | log | diff | annotate | |
| message |
Fix wrong firmware API documentation comments for iwm(4) and iwx(4). Both drivers currently use SCAN_CHANNEL_CFG_S_VER1, not VER2. |
|||
| date | 2020-05-15T13:39:02Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/rnd.c | log | diff | annotate |
| message | remove unneccessary include files | |||
| date | 2020-05-15T13:48:57Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/rnd.c | log | diff | annotate |
| message |
The main comment block from 1996 has become highly inaccurate and misleading, so rewrite it. The interesting parts are bootblock-seeding from file + hwrng, arc4random() being available incredibly early, and seperate timeouts to pull entropy data forward into a stir of the chacha state (one for entropy ring crc whitening into a buffer, the 2nd for buffer folding into the chacha) Now that it is better documented, I can try to improve each component. |
|||
| date | 2020-05-15T13:53:00Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/rnd.c | log | diff | annotate |
| message |
The long explanation for CRC stirring isn't helping. If anything it suggests we should reconsider this mechanism and do something simpler... delete the explanation for now. |
|||
| date | 2020-05-15T13:58:37Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/rnd.c | log | diff | annotate |
| message |
Explain enqueue_randomness() better. It is the supply-entropy function, and change wording from 'entropy queue', what we have is a ring which collects 'damage' from successive calls until drawn down |
|||
| date | 2020-05-15T14:02:06Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/rnd.c | log | diff | annotate |
| message | The description of the enqueue_randomness() input parameter was crazy untrue. | |||
| date | 2020-05-15T14:04:00Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/rnd.c | log | diff | annotate |
| message | Describe the purpose of add_entropy_words() in simpler terms. | |||
| date | 2020-05-15T14:09:14Z | |||
|---|---|---|---|---|
| author | patrick | |||
| files | src/sys/dev/ic/bwfm.c | log | diff | annotate |
| src/sys/dev/ic/bwfmreg.h | log | diff | annotate | |
| src/sys/dev/ic/bwfmvar.h | log | diff | annotate | |
| src/sys/dev/sdmmc/if_bwfm_sdio.c | log | diff | annotate | |
| message |
Some newer bwfm(4) chips from Cypress hold their regulatory constraints in a separate blob, instead of in the firmware. This .clm_blob needs to be loaded as well. |
|||
| date | 2020-05-15T14:21:08Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/ic/ar5008.c | log | diff | annotate |
| src/sys/dev/pci/if_iwn.c | log | diff | annotate | |
| src/sys/dev/pci/if_wpi.c | log | diff | annotate | |
| message |
Fix CCMP replay check with 11n Rx aggregation and CCMP hardware offloading. So far, drivers using hardware CCMP decryption were expected to keep the most recently seen CCMP packet number (PN) up-to-date, and to discard frames with lower PNs as replays. A-MPDU subframes may legitimately arrive out of order, and the drivers skipped CCMP replay checking for such frames. Re-ordering happens in ieee80211_inputm(), after the driver is done with a frame. Drivers cannot tell replayed frames apart from legitimate out-of-order retransmissions. To fix this, update the PN value in ieee80211_inputm() after subframes have been reordered into their proper sequence. Drivers still perform replay checks but they no longer have to worry about updating the last seen PN value. The 802.11 spec confirms that replay checking is supposed to happen after A-MPDU re-ordering. Tested by jmc@, benno@, solene@, and myself with the following drivers: athn(4), iwn(4), iwm(4), wpi(4), urtwn(4) ok solene@ |
|||
| date | 2020-05-15T14:21:09Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/net80211/ieee80211_crypto.c | log | diff | annotate |
| src/sys/net80211/ieee80211_crypto.h | log | diff | annotate | |
| src/sys/net80211/ieee80211_crypto_ccmp.c | log | diff | annotate | |
| src/sys/net80211/ieee80211_crypto_tkip.c | log | diff | annotate | |
| src/sys/net80211/ieee80211_input.c | log | diff | annotate | |
| message |
Fix CCMP replay check with 11n Rx aggregation and CCMP hardware offloading. So far, drivers using hardware CCMP decryption were expected to keep the most recently seen CCMP packet number (PN) up-to-date, and to discard frames with lower PNs as replays. A-MPDU subframes may legitimately arrive out of order, and the drivers skipped CCMP replay checking for such frames. Re-ordering happens in ieee80211_inputm(), after the driver is done with a frame. Drivers cannot tell replayed frames apart from legitimate out-of-order retransmissions. To fix this, update the PN value in ieee80211_inputm() after subframes have been reordered into their proper sequence. Drivers still perform replay checks but they no longer have to worry about updating the last seen PN value. The 802.11 spec confirms that replay checking is supposed to happen after A-MPDU re-ordering. Tested by jmc@, benno@, solene@, and myself with the following drivers: athn(4), iwn(4), iwm(4), wpi(4), urtwn(4) ok solene@ |
|||