Re: OpenWrt One / project update
On Mon, 29 Apr 2024, Michael Richardson wrote:
{sorry for the long delay, been unwell}
Bjørn Mork wrote:
> Maybe it is possible to deploy the system with secure boot and a
> protected IDevId key by default, but allowing the user/owner to erase
> the key and disable secure boot? This way all use cases could be
> supported, including playing with the BL2 code etc.
It won't work that way. If someone can easily turn off secure boot, then so
can malware.
I hope we can go the other way.
can you do a hardware lock (jumper, washer under a mounting screw, etc)?
David Lang___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Hi Michael,
On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote:
>
> {sorry for the long delay, been unwell}
>
> Bjørn Mork wrote:
> > Maybe it is possible to deploy the system with secure boot and a
> > protected IDevId key by default, but allowing the user/owner to erase
> > the key and disable secure boot? This way all use cases could be
> > supported, including playing with the BL2 code etc.
>
> It won't work that way. If someone can easily turn off secure boot, then so
> can malware.
Malware cannot remove or add a physical jumper or press a physical button
on the board (we got a jumper to write-protect the SPI-NOR flash).
The only option of having secure boot enabled would be to allow users to
permanently disable it, otherwise the resulting hardware would not be
worth being called "Open", as it would, in fact, be closed.
Believing that secure boot could provide protection from malware also misses
an important point: Most malware nowadays doesn't even strive for
persistency but rather relies on exploitable run-time vulnerabilities.
We are in an always-online world, the classic "boot sector virus" is
an archaic thing from the 1980s.
Hence, a simple reboot would get rid of most IoT malware already today
and without secure boot, as leaving a trace on the flash would make the
infection recognizable: Cutting the power and dumping the content of the
flash is easy for malware analists. Dumping the content of the (DDR4)
RAM of a rootkit'ed system is not at all, it's nearly impossible.
The only really meaningful way to enhance system security on a technical
level is hence to reduce the attack surface and makeing sure the system
cannot be exploited at runtime. That means a whole lot of things,
ranging from human and machine review (ideally formal verification),
reproducible builds and a cryptographically trusted supply chain down to
language guarantees such as memory safety, making sure the code is easy
to understand, always keeping complexity as low as possible and much
more.
As secondary measures the principle of least privileges should be
applied, sandboxing, memory address randomization, even mandatory
access control systems like SELinux all have their place there.
Needless to say that there have also been vulnerabilities in the secure
enclaves as well as their secure operating systems, and that offered a
whole new dimension to nasty and persistent, and hard to detect malware.
So while I can see that having stuff like measured boot and TPM
encrypted credentials is generally nice to have, it quickly becomes
obvious that all that only works on a trusted computing environment, and
even then is only moderately meaningful if you consider the common
malware attack vectors: If an endpoint can authenticate my client using
credentials protected by a TPM or secure enclave, so can anyone else
*temporarily* in control of the client system at the same level of
privileges. And measured boot would not provide any meaningful way to
prevent that.
I think the recent increase of rather simple two-way-repeater attacks on
things like contactsless (and PIN-less) NFC payment systems as well as
car thefts aided by repeating Keyless Go demonstrates that point very
well.
Imho the whole secure boot fuzz is mostly about protecting the system
and its *remote* operators ("platform providers") from the actual users.
It's really very useful for that: SaS and other kind of intellectual
property licencing and subscriptions businesses. Things like Widevine
which is made to prevent users from source-ripping 4k HDR video content.
All that being said, I still believe it's important to have the core
components of all that stuff available as reproducible free open source
software, so people can learn how it all works and play with it
hands-on, just because it became ubiquitous in modern life and not
dealing with it kinda means living in denial and darkness. Hence,
despite all the critizism, I do appreciate your work and effort to allow
people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One.
> I hope we can go the other way.
>
> I'm willing to do the legwork, and I can sign an NDA if necessary, and then
> communicate what needs to be said.
NDA with whom? MediaTek?
When it comes to OpenWrt and the OpenWrt One: As a first step we would
have to come up with the methods to run the necessary PKI infrastructure
in a democratic and distributed way, without requiring any NDAs and
without any single point of responsibility or potential bus-factor.
Cheers
Daniel
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
{sorry for the long delay, been unwell}
Bjørn Mork wrote:
> Maybe it is possible to deploy the system with secure boot and a
> protected IDevId key by default, but allowing the user/owner to erase
> the key and disable secure boot? This way all use cases could be
> supported, including playing with the BL2 code etc.
It won't work that way. If someone can easily turn off secure boot, then so
can malware.
I hope we can go the other way.
I'm willing to do the legwork, and I can sign an NDA if necessary, and then
communicate what needs to be said.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 23.05 0/2] mt76: update for some fixes & important features
From: Rafał Miłecki I'd like to slightly update mt76 for 23.05. This update: 1. Is important for MT7996 (important features including WED support) 2. Includes minor fixes for mt7915 & mt7921 Felix Fietkau (2): mt76: update to the latest version mt76: update to Git HEAD (2023-12-08) package/kernel/mt76/Makefile | 56 +-- ..._wed-rename-mtk_rxbm_desc-in-mtk_wed.patch | 24 2 files changed, 52 insertions(+), 28 deletions(-) delete mode 100644 package/kernel/mt76/patches/0001-net-ethernet-mtk_wed-rename-mtk_rxbm_desc-in-mtk_wed.patch -- 2.35.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 23.05 1/2] mt76: update to the latest version
From: Felix Fietkau b5d13611d35e mt76: mt7915: fix monitor mode issues bbbac7deee3d wifi: mt76: rename mt76_packet_id_init/flush to mt76_wcid_init/cleanup f1e1e67d97d1 wifi: mt76: fix race condition related to checking tx queue fill status b3f739a64e6b wifi: mt76: mt7996: add eht rx rate support ca4917062f17 wifi: mt76: mt76x0: remove dead code in mt76x0_phy_get_target_power 325a0c493199 wifi: mt76: mt7996: fill txd by host driver cd371fcc98d4 mt76: mt7996: sync with upstream d71f8d1b172b wifi: mt76: use atomic iface iteration for pre-TBTT work 8d5ea32d4895 wifi: mt76: remove unused error path in mt76_connac_tx_complete_skb 01860c02c505 wifi: mt76: add DMA mapping error check in mt76_alloc_txwi() 62ddb6d46a97 wifi: mt76: connac: introduce helper for mt7925 chipset 0837f37e998b wifi: mt76: mt792x: support mt7925 chip init 899ff378082b wifi: mt76: connac: export functions for mt7925 c3858b5bf347 wifi: mt76: connac: add eht support for phy mode config 5df6b26a9fc5 wifi: mt76: connac: add eht support for tx power a8081345c636 wifi: mt76: connac: add data field in struct tlv 9b38aebecf78 wifi: mt76: connac: add more unified command IDs 84984e6dc87d wifi: mt76: connac: add more unified event IDs 6fe92398c9ce wifi: mt76: mt7996: set correct wcid in txp 2cfe2fb0bb80 wifi: mt76: mt7996: fix beamform mcu cmd configuration e512241bb5bb wifi: mt76: mt7996: fix beamformee ss subfield in EHT PHY cap 719a98f832c7 wifi: mt76: mt7996: fix wmm queue mapping 9723562f2a5b wifi: mt76: mt7996: fix rx rate report for CBW320-2 1bb5a6a54943 wifi: mt76: mt7996: fix TWT command format 751b054891f6 wifi: mt76: mt7996: only set vif teardown cmds at remove interface fea1e10c7741 wifi: mt76: mt7996: support more options for mt7996_set_bitrate_mask() d497ee8aa2f5 wifi: mt76: mt7996: support per-band LED control 8ccc8441 wifi: mt76: Use PTR_ERR_OR_ZERO() to simplify code 161f70217edf wifi: mt76: mt7921e: Support MT7992 IP in Xiaomi Redmibook 15 Pro (2023) 7d25bfc3f0cc wifi: mt76: fix clang-specific fortify warnings 5971aa968401 wifi: mt76: connac: add MBSSID support for mt7996 5a47dd323be1 wifi: mt76: update beacon size limitation d5b4b81dcc9e wifi: mt76: check sta rx control frame to multibss capability af0e1f6dafb5 wifi: mt76: fix potential memory leak of beacon commands 65d91a833b01 wifi: mt76: get rid of false alamrs of tx emission issues 29411e52059f wifi: mt76: fix per-band IEEE80211_CONF_MONITOR flag comparison 4da62774038a wifi: mt76: check vif type before reporting cca and csa 4a85678fe089 wifi: mt76: mt7915: update mpdu density capability 791a45cffadf wifi: mt76: mt7915: fix beamforming availability check 08e1e6cb7d41 wifi: mt76: Drop unnecessary error check for debugfs_create_dir() d1881b1b2bf6 wifi: mt76: move struct ieee80211_chanctx_conf up to struct mt76_vif 66d5694e1898 wifi: mt76: mt7921: fix the wrong rate pickup for the chanctx driver 9fc37b0ac546 wifi: mt76: mt7921: fix the wrong rate selected in fw for the chanctx driver 2afc7285f75d wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips Signed-off-by: Felix Fietkau (cherry picked from commit ef8e2f66f563d0d1864be37075dacf3f13defdc7) Signed-off-by: Rafał Miłecki --- package/kernel/mt76/Makefile | 56 +--- 1 file changed, 52 insertions(+), 4 deletions(-) diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile index 500735303f..dd75390ee7 100644 --- a/package/kernel/mt76/Makefile +++ b/package/kernel/mt76/Makefile @@ -1,16 +1,16 @@ include $(TOPDIR)/rules.mk PKG_NAME:=mt76 -PKG_RELEASE=2 +PKG_RELEASE=1 PKG_LICENSE:=GPLv2 PKG_LICENSE_FILES:= PKG_SOURCE_URL:=https://github.com/openwrt/mt76 PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2023-09-11 -PKG_SOURCE_VERSION:=f1e1e67d97d1e9a8bb01b59ab20c45ebc985a958 -PKG_MIRROR_HASH:=41fde79de5bec3aaafdb64658475a1fa99bc483b8122e6aad9b2aa8aa8edfce6 +PKG_SOURCE_DATE:=2023-09-18 +PKG_SOURCE_VERSION:=2afc7285f75dca5a0583fd917285bf33f1429cc6 +PKG_MIRROR_HASH:=2c9556b298246277ac2d65415e4449f98e6d5fdb99e0d0a92262f162df772bbc PKG_MAINTAINER:=Felix Fietkau PKG_USE_NINJA:=0 @@ -315,6 +315,38 @@ define KernelPackage/mt7921e AUTOLOAD:=$(call AutoProbe,mt7921e) endef +define KernelPackage/mt7996e + $(KernelPackage/mt76-default) + TITLE:=MediaTek MT7996E wireless driver + DEPENDS+=@PCI_SUPPORT +kmod-mt76-connac + FILES:= $(PKG_BUILD_DIR)/mt7996/mt7996e.ko + AUTOLOAD:=$(call AutoProbe,mt7996e) +endef + +define KernelPackage/mt7925-common + $(KernelPackage/mt76-default) + TITLE:=MediaTek MT7925 wireless driver common code + HIDDEN:=1 + DEPENDS+=+kmod-mt792x-common +@DRIVER_11AX_SUPPORT +kmod-hwmon-core + FILES:= $(PKG_BUILD_DIR)/mt7925/mt7925-common.ko +endef + +define KernelPackage/mt7925u + $(KernelPackage/mt76-default) + TITLE:=MediaTek MT7925U wireless driver + DEPENDS+=+kmod-mt792x-usb +kmod-mt7925-common + FILES:= $(PKG_BUILD_DIR)/mt7925/mt7925u.ko + AUTOLOAD:=$(call AutoProbe,mt7921u) +endef + +define KernelPackage/mt7925e +
[PATCH 23.05 2/2] mt76: update to Git HEAD (2023-12-08)
From: Felix Fietkau
890ae4d717f1 wifi: mt76: mt76x02: fix MT76x0 external LNA gain handling
fcc2f3d82bc9 wifi: mt76: fix lock dependency problem for wed_lock
77cc14596202 wifi: mt76: mt792x: move mt7921_skb_add_usb_sdio_hdr in mt792x
module
bc85355885d1 wifi: mt76: mt792x: move some common usb code in mt792x module
c27f01c4c834 wifi: mt76: mt7996: get tx_retries and tx_failed from txfree
30aba4c18307 wifi: mt76: mt7996: Add mcu commands for getting sta tx statistic
119bebff244b wifi: mt76: mt7996: enable PPDU-TxS to host
a4005e0e83e7 wifi: mt76: mt7996: remove periodic MPDU TXS request
d6cc20bf5913 wifi: mt76: reduce spin_lock_bh held up in mt76_dma_rx_cleanup
5d94251d641c wifi: mt76: mt7921: move connac nic capability handling to mt7921
266341b5019d wifi: mt76: mt7921: enable set txpower for UNII-4
581449ac5274 wifi: mt76: mt7921: add 6GHz power type support for clc
9bfd669e9477 wifi: mt76: mt7921: get regulatory information from the clc event
4a0f839da0f1 wifi: mt76: mt7921: update the channel usage when the regd domain
changed
f4df423d3d56 wifi: mt76: add ability to explicitly forbid LED registration with
DT
54d369e79972 wifi: mt76: mt7921: support 5.9/6GHz channel config in acpi
b39b6cba220f wifi: mt76: mt7996: fix uninitialized variable in parsing txfree
77194e652885 wifi: mt76: fix typo in mt76_get_of_eeprom_from_nvmem function
c37738fc9097 wifi: mt76: limit support of precal loading for mt7915 to MTD only
d6e8aa634a19 wifi: mt76: make mt76_get_of_eeprom static again
d1c671a90eba wifi: mt76: permit to use alternative cell name to eeprom NVMEM
load
5539001fe4e3 wifi: mt76: permit to load precal from NVMEM cell for mt7915
48d413380685 wifi: mt76: Remove unnecessary (void*) conversions
ea2814289147 wifi: mt76: mmio: move mt76_mmio_wed_{init,release}_rx_buf in
common code
9fb0277d7ee8 wifi: mt76: move mt76_mmio_wed_offload_{enable,disable} in common
code
4b47145ecf44 wifi: mt76: move mt76_net_setup_tc in common code
d798d5d6f770 wifi: mt76: introduce mt76_queue_is_wed_tx_free utility routine
48b0cedbf83f wifi: mt76: introduce wed pointer in mt76_queue
c550204e347d wifi: mt76: increase MT_QFLAG_WED_TYPE size
2e7f30f22cfd wifi: mt76: mt7996: add wed tx support
ec8765a02fc8 wifi: mt76: dma: introduce __mt76_dma_queue_reset utility routine
a469aaac9784 wifi: mt76: mt7996: use u16 for val field in mt7996_mcu_set_rro
signature
abca260a15c4 wifi: mt76: mt7996: add wed rx support
be2e74c0c495 wifi: mt76: move wed reset common code in mt76 module
7f17e164fbb4 wifi: mt76: mt7996: add wed reset support
0f89bf58efda wifi: mt76: mt7996: add wed rro delete session garbage collector
a58b75f863ca wifi: mt76: mt7915: fallback to non-wed mode if
platform_get_resource fails in mt7915_mmio_wed_init()
36d2ddd94eeb wifi: mt76: mt7996: add support for variants with auxiliary RX path
cec7720c9341 wifi: mt76: mt7996: add TX statistics for EHT mode in debugfs
9852093062e8 wifi: mt76: connac: add thermal protection support for mt7996
955540a4df74 wifi: mt76: mt7996: add thermal sensor device support
af41374a3b8e wifi: mt76: connac: add beacon duplicate TX mode support for mt7996
3c98d7b7fa23 wifi: mt76: mt7996: fix the size of struct bss_rate_tlv
ee2169c00539 wifi: mt76: mt7996: adjust WFDMA settings to improve performance
0aead5de68a7 wifi: mt76: connac: set fixed_bw bit in TX descriptor for fixed
rate frames
ab5580ff5a4f wifi: mt76: mt7996: handle IEEE80211_RC_SMPS_CHANGED
eed234afed7e wifi: mt76: mt7996: align the format of fixed rate command
d9a855285b95 wifi: mt76: mt7996: fix rate usage of inband discovery frames
47799aefe263 wifi: mt76: change txpower init to per-phy
264e1ecfe1b4 wifi: mt76: mt7996: add txpower setting support
c7b243b127eb wifi: mt76: use chainmask for power delta calculation
05f433900a02 wifi: mt76: mt7996: switch to mcu command for TX GI report
ae963198e605 wifi: mt76: mt7996: fix alignment of sta info event
d0d2e03591d6 wifi: mt76: mt7996: rework ampdu params setting
e87f4efc7638 wifi: mt76: connac: add beacon protection support for mt7996
0dfcc53a8e5d wifi: mt76: connac: fix EHT phy mode check
30c54a53bf8b wifi: mt76: mt7915: fix EEPROM offset of TSSI flag on MT7981
17297c97b737 wifi: mt76: mt7915: also MT7981 is 3T3R but nss2 on 5 GHz band
eeb48c081034 wifi: mt76: mt7996: fix mt7996_mcu_all_sta_info_event struct
packing
b74ad922659c wifi: mt76: mt7996: introduce mt7996_band_valid()
51cb541c1e53 wifi: mt76: connac: add firmware support for mt7992
c0eda4d96ec8 wifi: mt76: mt7996: add DMA support for mt7992
f12471968a53 wifi: mt76: mt7996: rework register offsets for mt7992
8d11dae73eb8 wifi: mt76: mt7996: support mt7992 eeprom loading
6c2b2c37abd7 wifi: mt76: mt7996: adjust interface num and wtbl size for mt7992
df1d3b3c67e5 wifi: mt76: connac: add new definition of tx descriptor
f997e759cea5 wifi: mt76: mt7996: add PCI IDs for mt7992
94e3632e4e93 wifi: mt76: mt7925: remove iftype from mt7925_init_eht_caps
signature
9c7b98c03173 net: ethernet: mtk_wed: rename mtk_rxbm_desc in
Re: Question to recent Qualcomm CVEs
On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: > > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > > It's quite strange that they updated 2.5.0.1 branch first but my > > understanding that there should be updates for the newer 2.7.0.1 branch > > as well (2.7.0.1 branch is also in linux-firmware). > > Yes, I also told them in the support ticket that this is from an older branch > than what is currently shipped in linux-firmware.git. But they told me > that they are working on newer versions (whatever that means) - but they > wanted to handle first the update to ATH.11.4 (2.5.0.x) and then > step-by-step release it for newer firmware branches. It seem like that would > be > up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP > SoCs. I would like to point out that IPQ6018 doesn't even have anything newer than 2.5.0.1 available publicly. Regards, Robert > > Kind regards, > Sven___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > It's quite strange that they updated 2.5.0.1 branch first but my > understanding that there should be updates for the newer 2.7.0.1 branch > as well (2.7.0.1 branch is also in linux-firmware). Yes, I also told them in the support ticket that this is from an older branch than what is currently shipped in linux-firmware.git. But they told me that they are working on newer versions (whatever that means) - but they wanted to handle first the update to ATH.11.4 (2.5.0.x) and then step-by-step release it for newer firmware branches. It seem like that would be up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP SoCs. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
Kalle Valo writes: > + ath11k, jeff > > Sven Eckelmann writes: > >> On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote: >> [...] The Qualcomm bulletin[1] says "Patches are being actively >>> > shared with OEMs". >>> > >>> > Were these bugfixes made available for OpenWRT? Is there an established >>> > procedure for such cases, where closed-source firmware gets bugfixes? >> [...] >>> > [1] >>> > https://docs.qualcomm.com/product/publicresources/securitybulletin/ >> december-2023-bulletin.html >>> >>> The fixes were not shared with OpenWrt. Qualcomm does not care about >>> OpenWrt support for their platforms. >> >> I've asked (using their qualcomm-cdmatech-support portal) for an official >> release of their WiFi firmware with all gathered bugfixes via >> linux-firmware.git. I got statements that the ath10k firmware is no longer >> supported + ath11k firmware is not developed further. But for some of them >> it >> is possible to request a release of the firmwares via Kalle's repositories. >> But also that Kalle's repositories are now replaced. Which seems to be >> confirmed by Kalle's statement [1] regarding the firmware-N.bin files on >> ath...@lists.infradead.org . >> >> The new positions for firmware files were not revealed but I found a couple >> of >> places [2,3,4,5] in my search. > > Yeah, the ath1?k-firmware.git repos are being moved to > git.codelinaro.org and we will send an announcement once everything is > ready. > >> And to the request to get the latest versions released via >> linux-firmware.git >> (or maybe even only in Kalle's repositories), I got (some weeks ago) the >> answer "Let me check with our team.". >> >> It is rather hard to make statements about Qualcomm - simply because it is >> not just a single person and I have no idea about the internal structures. >> But >> it doesn't seem to be the highest priority (for the "internal team"?) to >> make >> fixes available for everyone. I still hope that it is just delayed due to >> some >> unfortunate circumstances. But this is just the current state. > > Thanks for letting me know, I was not aware any of this. Me and Jeff > will investigate and get back to you. In case not everyone noticed but Jeff has now uploaded updates to 2.5.0.1 branch: https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/commit/97e0d33fe3e0f708459a682b167014906719337d https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/commit/04dd351414737ac14b3e381d3695b59f4de67eaa https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/commit/2dda8ce67f65af54f86fb2f49316174841fa95f7 It's quite strange that they updated 2.5.0.1 branch first but my understanding that there should be updates for the newer 2.7.0.1 branch as well (2.7.0.1 branch is also in linux-firmware). -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
