Re: OpenWrt One / project update
On Mon, 29 Apr 2024 21:05:15 +0100
Daniel Golle wrote:
> 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).
Correct, and IIRC a switch to choose which on-board flash to boot from?
This, plus the lockable boot block feature found in about all modern
flash chips is really all it takes to implement a really secure boot. It
is only a question of U-Boot patches, which can be 100% free and open
source software, absolutely no NDA required.
> 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.
Exactly. Thanks for the public reminder!
Torsten
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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
Re: OpenWrt One / project update
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. (I'm sure all of you have noticed, but I'm just throwing out random thoughts without knowing anything about how hard they are to implement) Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Bjørn Mork wrote: > Michael Richardson writes: >> Having orange and red pieces "secured" *does* mean that u-boot updates would >> have to come from openwrt. > Does it? Is it possible to modify the BL2 to verify signatures of the > BL31 and BL32 stages only? I don't know. > If not, is it feasible to deploy an automated fip.bin signer, taking an > any unverified U-Boot binary as input and building a signed fip.bin for > the OpenWrt One using verified BL31 and BL32 blobs? I wouldn't want to do this in too automated a fashion. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Fixing typos to make the whole message clearer. On Sun, Apr 14, 2024 at 01:03:04AM +0200, Enrico Mioso wrote: > On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote: > > > > Daniel Golle wrote: > > >> In the first PDF, there is mention of: > > >> Security Support 2 * 256-bit multi-key on OTP eFuse > > >> Support 64 version OTP eFuse for anti-rollback > > > > > Those features require proprietary tools provided by MediaTek only to > > > clients under NDA. Unless some 3rd-party reverse-engineers those > > > tools, we won't ever use those features. Also note that those 256-bit > > > keys are *symmetric* keys probably, so not that useful for IDevID. > > > > Yes, I know they are symmetrical. > > Typically, the way that a 256-bit seed is used is that it is blown in the > > MediaTek fab with a strong random number. This seed is then provided via > > secure storage to the OEM (us). [You ought to be thinking Johnny Nmemonic, > > but in practive, I think it's a USB drive with a password protected .xlsx > > file, sigh] > > > > Our factory then uses the seed to generate a (256-bit ECDSA) keypair, for > > which a CSR and then certificate are generated. The private key is securely > > erased, and the certificate is loaded into the device. The device > > "simultaenously" uses the seed to generate the same keypair, and it now has > > the private key that goes with the certificate. > > This process has become common, but it doesn't have a good name. > > https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03.html#name-carrot-method-key-setup-bas > > (I tried to rename the methods: (A)vocado, (B)amboo, and (C)arrot, but that > > was considered too whimsical by some) > > > > >> which is often the key to getting IDevID deployed, but I didn't find > > further > > >> mention of that in the three datasheets. > > > > > Another option for deploying IDevID is using MMU to prevent access to > > > the SPI-NOR I/O range from non-secure land and handling cryptographic > > > operations entirely in the secure enclave, e.g. using OP-TEE and fTPM. > > > > > This is possible without burning any fuses and without any proprietary > > > tools (but will probably not be implemented in time for the firmware > > > which will ship with the device -- however, it can be done after, I > > > can help and point who ever wants to do it to the right directions.) > > > > If we are going to use OP-TEE to get an fTPM enabled, then that can be used > > for IDevID, and it's much faster (and rather more secure) than i2c > > interfaced > > discreet chips. But, it means more factory work for us. > > > > Usually, the ARM TrustZone must be initialized pretty early, at the latest > > in > > our u-boot. > > > > https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html > > Has a nice picture of how the various *SECURE BOOT* goes together. > > This is not for this CPU/SOC, but the Genio eval cards. My guess is that > > it's probably pretty common across their line, and it's within epsilon of > > other ARM processors. > > > > The issue is that we don't want SECURE BOOT, at least not past u-boot, > > because that would get in the way of the people who want to use this board. > > We might want the orange, and red pieces in the diagram. > > > > My suggestion (which I think is feasible) is that we put a signed u-boot > > onto > > the board, but that we turn u-boot verification of Linux-kernel/initramfs > > (the "FIT" stuff) *off*. Owners can install their own signing keys and sign > > their images if they want to do that. Probably, we can leave measure boot > > on. > > > > Measured boot collects the hashes (into the fTPM usually), and then asks a > > third party if they are okay. > > https://www.rfc-editor.org/rfc/rfc9334#name-two-types-of-environments-o > > > > Having orange and red pieces "secured" *does* mean that u-boot updates would > > have to come from openwrt. That's descending into a thresherous way < > > https://www.gnu.org/philosophy/can-you-trust.html > a bit. > > Probably we can offer to sign other people's u-boot images; but probably > > there won't be more than a dozen such requests. > > No thanks - enough proprietary/signing/secure crap all over already, and I've > been there long enough to tell you this is really not fun. > > Please guys wake up and stop these things. > If you really want to play with this kind of thing, why not build your own > line of hardware? > And if you're kind enough to leave off secure boot in hw, we may be able to > replace the bootloader with one allowing people to do what they feel like > with their hardware. > And I am saying nothing new here since we, as project, find ourselves having > to replace the bootloader sometimes, exactly due to signature checking and > other limitations making things overall more difficult. > I feel like we would damage our
Re: OpenWrt One / project update
On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote: > > Daniel Golle wrote: > >> In the first PDF, there is mention of: > >> Security Support 2 * 256-bit multi-key on OTP eFuse > >> Support 64 version OTP eFuse for anti-rollback > > > Those features require proprietary tools provided by MediaTek only to > > clients under NDA. Unless some 3rd-party reverse-engineers those > > tools, we won't ever use those features. Also note that those 256-bit > > keys are *symmetric* keys probably, so not that useful for IDevID. > > Yes, I know they are symmetrical. > Typically, the way that a 256-bit seed is used is that it is blown in the > MediaTek fab with a strong random number. This seed is then provided via > secure storage to the OEM (us). [You ought to be thinking Johnny Nmemonic, > but in practive, I think it's a USB drive with a password protected .xlsx > file, sigh] > > Our factory then uses the seed to generate a (256-bit ECDSA) keypair, for > which a CSR and then certificate are generated. The private key is securely > erased, and the certificate is loaded into the device. The device > "simultaenously" uses the seed to generate the same keypair, and it now has > the private key that goes with the certificate. > This process has become common, but it doesn't have a good name. > https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03.html#name-carrot-method-key-setup-bas > (I tried to rename the methods: (A)vocado, (B)amboo, and (C)arrot, but that > was considered too whimsical by some) > > >> which is often the key to getting IDevID deployed, but I didn't find > further > >> mention of that in the three datasheets. > > > Another option for deploying IDevID is using MMU to prevent access to > > the SPI-NOR I/O range from non-secure land and handling cryptographic > > operations entirely in the secure enclave, e.g. using OP-TEE and fTPM. > > > This is possible without burning any fuses and without any proprietary > > tools (but will probably not be implemented in time for the firmware > > which will ship with the device -- however, it can be done after, I > > can help and point who ever wants to do it to the right directions.) > > If we are going to use OP-TEE to get an fTPM enabled, then that can be used > for IDevID, and it's much faster (and rather more secure) than i2c interfaced > discreet chips. But, it means more factory work for us. > > Usually, the ARM TrustZone must be initialized pretty early, at the latest in > our u-boot. > > https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html > Has a nice picture of how the various *SECURE BOOT* goes together. > This is not for this CPU/SOC, but the Genio eval cards. My guess is that > it's probably pretty common across their line, and it's within epsilon of > other ARM processors. > > The issue is that we don't want SECURE BOOT, at least not past u-boot, > because that would get in the way of the people who want to use this board. > We might want the orange, and red pieces in the diagram. > > My suggestion (which I think is feasible) is that we put a signed u-boot onto > the board, but that we turn u-boot verification of Linux-kernel/initramfs > (the "FIT" stuff) *off*. Owners can install their own signing keys and sign > their images if they want to do that. Probably, we can leave measure boot > on. > > Measured boot collects the hashes (into the fTPM usually), and then asks a > third party if they are okay. > https://www.rfc-editor.org/rfc/rfc9334#name-two-types-of-environments-o > > Having orange and red pieces "secured" *does* mean that u-boot updates would > have to come from openwrt. That's descending into a thresherous way < > https://www.gnu.org/philosophy/can-you-trust.html > a bit. > Probably we can offer to sign other people's u-boot images; but probably > there won't be more than a dozen such requests. No thanks - enough proprietary/signing/secure crap all over already, and I've been there enough to tell you this is really not fun. Please guys wake up and stop these things. If you really want to play with this kind of thing, why not build your own line of hardware? And if you're kind enough to leave off secure boot in hw, we may be able to replace the bootloader with a one allowing people to do what they feel like with their hardware. And I am saying nothing new here since we, as project, find ourselves having to replace the bootloader sometimes, exactly due to signature checking and other limitations making things overall more difficult. I feel like we would damager our reputation allowing something like "ask us if you want your bootloader binary to be signed". Developing the technology is of course interesting, but the decision to engage on this should come from the user. This may create additional problems like e.g.: the user losing the key used to sign things and so on, and
Re: OpenWrt One / project update
Michael Richardson writes: > Having orange and red pieces "secured" *does* mean that u-boot updates would > have to come from openwrt. Does it? Is it possible to modify the BL2 to verify signatures of the BL31 and BL32 stages only? If not, is it feasible to deploy an automated fip.bin signer, taking an any unverified U-Boot binary as input and building a signed fip.bin for the OpenWrt One using verified BL31 and BL32 blobs? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On Fri, Apr 12, 2024 at 05:37:22PM -0400, Michael Richardson wrote: > > John Crispin wrote: > >> using OP-TEE and fTPM. > > > pretty high on my list once we find the time > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html > > Where you thinking about OP-TEE as the BL32, or were you thinking that we > could attempt this: >OP-TEE OS after boot via an SMC call by enabling the option for >OPTEE_ALLOW_SMC_LOAD Imho only OP-TEE as BL32 really makes sense. Running U-Boot as secure OS is insane and nobody should be doing that, especially not on a SoC which can be brought up with TF-A BL2. > > my reading of this is that it only works if you securely boot a linux kernel. > If we had a securely boot (the u-boot checks the signature) linux kernel, > then nobody could change their kernel. > > -- > 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
John Crispin wrote: >> using OP-TEE and fTPM. > pretty high on my list once we find the time > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html Where you thinking about OP-TEE as the BL32, or were you thinking that we could attempt this: OP-TEE OS after boot via an SMC call by enabling the option for OPTEE_ALLOW_SMC_LOAD my reading of this is that it only works if you securely boot a linux kernel. If we had a securely boot (the u-boot checks the signature) linux kernel, then nobody could change their kernel. -- 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
Re: OpenWrt One / project update
Daniel Golle wrote: >> In the first PDF, there is mention of: >> Security Support 2 * 256-bit multi-key on OTP eFuse >> Support 64 version OTP eFuse for anti-rollback > Those features require proprietary tools provided by MediaTek only to > clients under NDA. Unless some 3rd-party reverse-engineers those > tools, we won't ever use those features. Also note that those 256-bit > keys are *symmetric* keys probably, so not that useful for IDevID. Yes, I know they are symmetrical. Typically, the way that a 256-bit seed is used is that it is blown in the MediaTek fab with a strong random number. This seed is then provided via secure storage to the OEM (us). [You ought to be thinking Johnny Nmemonic, but in practive, I think it's a USB drive with a password protected .xlsx file, sigh] Our factory then uses the seed to generate a (256-bit ECDSA) keypair, for which a CSR and then certificate are generated. The private key is securely erased, and the certificate is loaded into the device. The device "simultaenously" uses the seed to generate the same keypair, and it now has the private key that goes with the certificate. This process has become common, but it doesn't have a good name. https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03.html#name-carrot-method-key-setup-bas (I tried to rename the methods: (A)vocado, (B)amboo, and (C)arrot, but that was considered too whimsical by some) >> which is often the key to getting IDevID deployed, but I didn't find further >> mention of that in the three datasheets. > Another option for deploying IDevID is using MMU to prevent access to > the SPI-NOR I/O range from non-secure land and handling cryptographic > operations entirely in the secure enclave, e.g. using OP-TEE and fTPM. > This is possible without burning any fuses and without any proprietary > tools (but will probably not be implemented in time for the firmware > which will ship with the device -- however, it can be done after, I > can help and point who ever wants to do it to the right directions.) If we are going to use OP-TEE to get an fTPM enabled, then that can be used for IDevID, and it's much faster (and rather more secure) than i2c interfaced discreet chips. But, it means more factory work for us. Usually, the ARM TrustZone must be initialized pretty early, at the latest in our u-boot. https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html Has a nice picture of how the various *SECURE BOOT* goes together. This is not for this CPU/SOC, but the Genio eval cards. My guess is that it's probably pretty common across their line, and it's within epsilon of other ARM processors. The issue is that we don't want SECURE BOOT, at least not past u-boot, because that would get in the way of the people who want to use this board. We might want the orange, and red pieces in the diagram. My suggestion (which I think is feasible) is that we put a signed u-boot onto the board, but that we turn u-boot verification of Linux-kernel/initramfs (the "FIT" stuff) *off*. Owners can install their own signing keys and sign their images if they want to do that. Probably, we can leave measure boot on. Measured boot collects the hashes (into the fTPM usually), and then asks a third party if they are okay. https://www.rfc-editor.org/rfc/rfc9334#name-two-types-of-environments-o Having orange and red pieces "secured" *does* mean that u-boot updates would have to come from openwrt. That's descending into a thresherous way < https://www.gnu.org/philosophy/can-you-trust.html > a bit. Probably we can offer to sign other people's u-boot images; but probably there won't be more than a dozen such requests. An alternative is that we find a way not to sign or initialize the BROM/TF-A secured boot, leaving those fuses unblown, and leave this to end owners to do. That might be impossible, and my experience with other ARM boards is that unless they get the fTPM loaded by the OAM board manufacturer, it just doesn't work out. ps: I'm willing to operate and secure the PK *I* junk that is needed to make this all work. It won't pass PCI on round one, but I'm sure if that was important, it could be done. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
using OP-TEE and fTPM. pretty high on my list once we find the time https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On Fri, Apr 12, 2024 at 01:38:01PM -0400, Michael Richardson wrote: > > John Crispin wrote: > > On 12.04.24 15:30, Michael Richardson wrote: > >> Is the MT7981B specification available publically at this point? > >> > >> I can find a 7986 sheet on hackaday, but who knows how it differs > (marketing > >> people and their numbers) > >> > > Hi > > > http://mirror2.openwrt.org/docs/ > > Thank you, I'm reading through now. > > I didn't grok all the GPIO pin sharing, there are a lot of choices there > which I think you've already made when you listed the high-level specs. > > Will we be able to support the: > "the hardware-based NAT engine with QoS embedded in MT7981B" > Any IPv6 support down there? Yes, for various tunnel protocols even. > Is it the "NEON"? > > I see 64 Tx queues for wired ethernet, but I imagine Dave Taht will want to > know if there are per-host queues for the wireless. Hmm. Well, it looks like > there are at least 4, but I could have mis-understood. > > In the first PDF, there is mention of: >Security Support 2 * 256-bit multi-key on OTP eFuse >Support 64 version OTP eFuse for anti-rollback Those features require proprietary tools provided by MediaTek only to clients under NDA. Unless some 3rd-party reverse-engineers those tools, we won't ever use those features. Also note that those 256-bit keys are *symmetric* keys probably, so not that useful for IDevID. > > which is often the key to getting IDevID deployed, but I didn't find further > mention of that in the three datasheets. Another option for deploying IDevID is using MMU to prevent access to the SPI-NOR I/O range from non-secure land and handling cryptographic operations entirely in the secure enclave, e.g. using OP-TEE and fTPM. This is possible without burning any fuses and without any proprietary tools (but will probably not be implemented in time for the firmware which will ship with the device -- however, it can be done after, I can help and point who ever wants to do it to the right directions.) > > I found: 11008014 GLOBAL_SEC_EN, but I think it has to do with locking down > the timers, or some I2C thing. > > (I turned on hypothes.is while reading the PDFs, if someone wants to see my > notes) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
John Crispin wrote: > On 12.04.24 15:30, Michael Richardson wrote: >> Is the MT7981B specification available publically at this point? >> >> I can find a 7986 sheet on hackaday, but who knows how it differs (marketing >> people and their numbers) >> > Hi > http://mirror2.openwrt.org/docs/ Thank you, I'm reading through now. I didn't grok all the GPIO pin sharing, there are a lot of choices there which I think you've already made when you listed the high-level specs. Will we be able to support the: "the hardware-based NAT engine with QoS embedded in MT7981B" Any IPv6 support down there? Yes, for various tunnel protocols even. Is it the "NEON"? I see 64 Tx queues for wired ethernet, but I imagine Dave Taht will want to know if there are per-host queues for the wireless. Hmm. Well, it looks like there are at least 4, but I could have mis-understood. In the first PDF, there is mention of: Security Support 2 * 256-bit multi-key on OTP eFuse Support 64 version OTP eFuse for anti-rollback which is often the key to getting IDevID deployed, but I didn't find further mention of that in the three datasheets. I found: 11008014 GLOBAL_SEC_EN, but I think it has to do with locking down the timers, or some I2C thing. (I turned on hypothes.is while reading the PDFs, if someone wants to see my notes) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On 12.04.24 15:30, Michael Richardson wrote: Is the MT7981B specification available publically at this point? I can find a 7986 sheet on hackaday, but who knows how it differs (marketing people and their numbers) Hi http://mirror2.openwrt.org/docs/ John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Is the MT7981B specification available publically at this point? I can find a 7986 sheet on hackaday, but who knows how it differs (marketing people and their numbers) signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
> Bjørn Mork wrote: "And I consider immutable source-less compiled binary blobs > the absolute worst kind of all binary blobs. > They are impossible to debug and fix, and have exactly no theoretical chance > of ever been replaced by an open source alternative, even in the wettest > libre software dreams." Why I consider BootROM - if present - as a lesser evil: said BootROM is always much smaller and does much less stuff than the higher level binary blobs, and also it is better having "just a BootROM" than "BootROM + said binary blobs" (because of course you can't expect "blobbed" WiFi chips to be better in this regard). > Paul D wrote: "This seems part of a much larger debate: finding a company who > would produce a spec compliant SoC which does or does not contain IP, and > gives it away freely" This is another approach, which may be better in the long term. However, what I am suggesting (and have proposed a long time ago while seeing the 1st "OpenWRT One" message) - is much more simple: " Dear colleagues, so here is a list of 30 WiFi chips of X generation and might be a good candidate for our new routers. Let's take a quick look at each chip to determine its "liberation-potential" and choose a chip which appears to be easier to liberate. Oh, there is a very detailed public datasheet available for Y chip, and Z researcher has shared his analysis of its existant binary blob? That's cool, let's choose Y chip for our new router - even if it is slightly worse / slightly more expensive than a S chip without such benefits." > ... "Things like RPi and its analogues seem evidence that people want to hack > and tinker." To be honest the success of RPi is kinda undeserved, seeing RPi is closely affiliated with Broadcom which is one of the most hostile companies towards the opensource (on the same level as NVidia). Also, it disappointed me so much that Pine64 chose Broadcom as a WiFi chip for their Pinephone Pro, that I chose a regular Pinephone despite its clearly worse performance (because there has been at least some reverse work done for its Realtek chip - sadly it doesnt use AR9462 chip like Purism Librem phone) > Daniel Golle wrote: Thank you Daniel for a very detailed reply > We are well aware of that and of course would appreciate any efforts > towards a blob-less system. The advantage of the chosen MT7981+MT7976 > chip combination is that it is generally well-understood and people > of our community have been working with the vendor (MediaTek) to write > a high-quality WiFi driver for it. It this moment, this is definitely > as good as it gets, the situation for all other modern WiFi chips is a > lot worse. For this SoC we are going to have open source datasheets > which cover most parts. We already got an Open Source implementation > of the ARM TrustedFirmware-A as well as U-Boot (see DDR4-exception > below, however). This sounds quite inspiring. Do you think there is a possibility of opensource source replacement for the existent Mediatek blobs, i.e. are there any firmware signatures that might be blocking us from even trying to develop them? > You won't find *any* device using DDR3 or more recent and faster DRAM chips > which do not need to run proprietary code to carry out the initial > calibration of the DRAM controller The things are better than may seem, here are a few examples of such devices - DDR3 and DDR4 (don't know about DDR5 but hopefully it isn't more locked-down in these regards) : 1) my coreboot-supported AMD hardware (without a PSP backdoor) - G505S laptop, A88XM-E desktop and AM1I-A mini-desktop (+ KGPE-D16 server which I don't have yet) - has a 100% opensource AGESA library which covers a lot of low-level things, including the completely blobless source code for multi-stage training of DDR3 controller. Together with my pen friend Mike Banon we have even debugged this code and modded it i.e. to be able to use 1866MHz CL9 RAM on A88XM-E without it downclocking to 1333 MHz (were a few unsolved issues inside that AGESA library and when AMD paused cooperation with coreboot community - we stopped getting any updates which might have fixed them). 2) Talos II workstation by Raptor Engineering uses DDR4 memory and does it bloblessly, as you could see by its RYF (respects your freedom) certification by Free Software Foundation. All this shows to me that the source code for DDR3 / DDR4 init does not necessarily has to be blobbed, it may be just a desire of particular chip vendors to put everything into a binary blob > What we do have are blobs which are part of linux-firmware and published > under a license which allows their free distribution, and those blobs are > uploaded to the WiFi chip itself, and they typically contain bytecode which > is run on the various built-in processors of those WiFi chips. Thank you for clarification > They key factors which would allow reverse engineering here are: > - known architecture and available free toolchain > - the small the blob
Re: OpenWrt One / project update
Hi Ivan, On Thu, Apr 11, 2024 at 10:15:58AM +, Ivan Ivanov wrote: > > there are no Wifi-5+ chips on the market that can run without blobs > > This is true, but at the same time - undoubtedly - some chips are more > likely to be liberated from blobs than the others. Some WiFi chip may > have been partially researched (i.e. someone tried to reverse-engineer > its binary blob) or at least a detailed-enough public PDF datasheet is > available so that its clear how the hardware operates, while some > other WiFi chip may lack these advantages and even use a firmware > signature that prevents the binary blob replacement by the opensource > alternative. > > What I am afraid of, and what forces me to write e-mails like this > once-in-a-while - is a POSSIBILITY that OpenWrt One project has not > taken this "liberation-potential" into consideration while choosing a > chip for a new router - and as result, it may turn out after that > OpenWrt One project becomes popular and the people would like it to > become blobless (i.e. by some crowdfunding initiative), but then find > out it impossible to liberate because of some technical limitation > like that firmware signature. We are well aware of that and of course would appreciate any efforts towards a blob-less system. The advantage of the chosen MT7981+MT7976 chip combination is that it is generally well-understood and people of our community have been working with the vendor (MediaTek) to write a high-quality WiFi driver for it. It this moment, this is definitely as good as it gets, the situation for all other modern WiFi chips is a lot worse. For this SoC we are going to have open source datasheets which cover most parts. We already got an Open Source implementation of the ARM TrustedFirmware-A as well as U-Boot (see DDR4-exception below, however). > > > Could you please list the wifi chips you know of which ether have > > a) completely open source firmware, or > > b) no firmware at all (neither loaded in ram, nor in internal flash)? > > The best WiFi hardware capable of working on 100% opensource, I am > aware of and using at the moment, is based on the chips of Atheros > ath9k / ath9k_htc families: > 1) Netgear WNDR3800 router, SoC : Atheros AR7161 rev 2, yes it is > 802.11n but it supports 5 GHz, and my ISP is slower than 300 Mbps in > any case > (bought it locally but you may visit this page for a more complete > description - shop [dot] vikings [dot] > net/product/wndr3800-wlan-router/ ) > This router runs on LibreCMC (fork of OpenWRT to designate the routers > which could work on 100% opensource) and its U-Boot is blobless too > AFAIK And here comes the next serious limitation: You won't find *any* device using DDR3 or more recent and faster DRAM chips which do not need to run proprietary code to carry out the initial calibration of the DRAM controller. The DRAM consortium enforce this with their patents and licensing strategies down to the SoC companies. Literally *all* of them ever since DDR3 require such blobs which have increased size with every generation of DRAM. In case of MediaTek those blobs are neither obfuscated nor not signed, they are merely compiled objects with a symbol table (which is probably the most relaxed interpretation of those DRAM consortium rules, but who knows, even the rules themselves are not public). > 2) AR9462 MiniPCIe WiFi module, also 802.11n with 5 GHz support, for > G505S laptop with a coreboot opensource BIOS > (btw this G505S is the most powerful coreboot-supported laptop without > Intel ME/AMD PSP backdoors, has a quadcore AMD and up to 16/32GB RAM) AR9462 can't be bought new any more at this point in time. I remember that TP-LINK had licenced some older QCA silicon and was still building batches of it for a while, but even this is now more than 5 years ago and I believe they have stopped doing that. > 3) There are also ath9k-based USB adapters which work on 100% > opensource, but those with 5 GHz support are rare (haven't been able > to find in the wild) Also those you can't order or buy new anywhere at this point. > > However, of course it does not mean that there is nothing newer than > this "ath9k" that could theoretically work on 100% opensource without > any blobs in userspace. Sorry, but none of those blobs run in userspace. Userspace is 100% built from Free Open Source Software for practically all OpenWrt-supported devices. What we do have are blobs which are part of linux-firmware and published under a license which allows their free distribution, and those blobs are uploaded to the WiFi chip itself, and they typically contain bytecode which is run on the various built-in processors of those WiFi chips. As you correctly stated, there isn't any post-WiFi-4 chip which does not require such firmware blobs. > A couple of years ago I've seen someone trying to reverse-engineer a > newer chip's blob (think it was 802.11ac ), but a Google does not want > me to find this page atm :P They key
Re: OpenWrt One / project update
On 2024-04-11 10:52, Bjørn Mork wrote: > Ivan Ivanov writes: > >>> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C >> >> Are these Mediateks capable of working without any binary blobs, at >> least in theory? > > A simple question back to you: Could you please list the wifi chips you > know of which ether have > a) completely open source firmware, or > b) no firmware at all (neither loaded in ram, nor in internal flash)? > > And of those, do any of them support 802.11g? 802.11a? 802.11ac? > 802.11ax? > > No need to list more than a couple of examples of each If your lists are > very long. I'm just curious what you are asking. Or whether you are > aware what you are asking, TBH > > This seems part of a much larger debate: finding a company who would produce a spec compliant SoC which does or does not contain IP, and gives it away freely. With the right licensing it's possible, but it doesn't prevent China from copying the hell out of it. Today it's already *really* difficult to tell fake chips and components apart from real ones, which is part of the battle. This 'numbers game' means any well intentioned open source Soc initiative could drown. It's not impossible, however. In the next decade, perhaps, with new chip foundries in the EU and USA. Things like RPi and its analogues seem evidence that people want to hack and tinker. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Ivan Ivanov writes: > BootROM is considered by Free Software Foundation as a part of > hardware And I consider immutable source-less compiled binary blobs the absolute worst kind of all binary blobs. They are impossible to debug and fix, and have exactly no theoretical chance of ever been replaced by an open source alternative, even in the wettest libre software dreams. We're different. You should follow up your ideas with a "LibreCMC One" or something like that. It won't be an alternative to the OpenWrt One for a single use case AFAICS, so there should be room for both. Not that I would buy one. But maybe the FSF board will? Good luck! Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
> there are no Wifi-5+ chips on the market that can run without blobs This is true, but at the same time - undoubtedly - some chips are more likely to be liberated from blobs than the others. Some WiFi chip may have been partially researched (i.e. someone tried to reverse-engineer its binary blob) or at least a detailed-enough public PDF datasheet is available so that its clear how the hardware operates, while some other WiFi chip may lack these advantages and even use a firmware signature that prevents the binary blob replacement by the opensource alternative. What I am afraid of, and what forces me to write e-mails like this once-in-a-while - is a POSSIBILITY that OpenWrt One project has not taken this "liberation-potential" into consideration while choosing a chip for a new router - and as result, it may turn out after that OpenWrt One project becomes popular and the people would like it to become blobless (i.e. by some crowdfunding initiative), but then find out it impossible to liberate because of some technical limitation like that firmware signature. > Could you please list the wifi chips you know of which ether have > a) completely open source firmware, or > b) no firmware at all (neither loaded in ram, nor in internal flash)? The best WiFi hardware capable of working on 100% opensource, I am aware of and using at the moment, is based on the chips of Atheros ath9k / ath9k_htc families: 1) Netgear WNDR3800 router, SoC : Atheros AR7161 rev 2, yes it is 802.11n but it supports 5 GHz, and my ISP is slower than 300 Mbps in any case (bought it locally but you may visit this page for a more complete description - shop [dot] vikings [dot] net/product/wndr3800-wlan-router/ ) This router runs on LibreCMC (fork of OpenWRT to designate the routers which could work on 100% opensource) and its U-Boot is blobless too AFAIK 2) AR9462 MiniPCIe WiFi module, also 802.11n with 5 GHz support, for G505S laptop with a coreboot opensource BIOS (btw this G505S is the most powerful coreboot-supported laptop without Intel ME/AMD PSP backdoors, has a quadcore AMD and up to 16/32GB RAM) 3) There are also ath9k-based USB adapters which work on 100% opensource, but those with 5 GHz support are rare (haven't been able to find in the wild) However, of course it does not mean that there is nothing newer than this "ath9k" that could theoretically work on 100% opensource without any blobs in userspace. A couple of years ago I've seen someone trying to reverse-engineer a newer chip's blob (think it was 802.11ac ), but a Google does not want me to find this page atm :P > And don't forget about the "bootROM", stored in silicon BootROM is considered by Free Software Foundation as a part of hardware, + it is not as bad as those bloated binary blobs running at your OpenWRT space On Thu, Apr 11, 2024 at 9:51 AM Piotr Dymacz wrote: > > Hi, > > On 11.04.2024 10:52, Bjørn Mork wrote: > > Ivan Ivanov writes: > > > >>> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C > >> > >> Are these Mediateks capable of working without any binary blobs, at > >> least in theory? > > > > A simple question back to you: Could you please list the wifi chips you > > know of which ether have > > a) completely open source firmware, or > > b) no firmware at all (neither loaded in ram, nor in internal flash)? > > [...] > > And don't forget about the "bootROM", stored in silicon, taking care of > (among other things) booting the SoC from different media. > > -- > Cheers, > Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Hi, On 11.04.2024 10:52, Bjørn Mork wrote: Ivan Ivanov writes: SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C Are these Mediateks capable of working without any binary blobs, at least in theory? A simple question back to you: Could you please list the wifi chips you know of which ether have a) completely open source firmware, or b) no firmware at all (neither loaded in ram, nor in internal flash)? [...] And don't forget about the "bootROM", stored in silicon, taking care of (among other things) booting the SoC from different media. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Ivan Ivanov writes: >> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C > > Are these Mediateks capable of working without any binary blobs, at > least in theory? A simple question back to you: Could you please list the wifi chips you know of which ether have a) completely open source firmware, or b) no firmware at all (neither loaded in ram, nor in internal flash)? And of those, do any of them support 802.11g? 802.11a? 802.11ac? 802.11ax? No need to list more than a couple of examples of each If your lists are very long. I'm just curious what you are asking. Or whether you are aware what you are asking, TBH Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On 11.04.24 10:15, Ivan Ivanov wrote: SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C Are these Mediateks capable of working without any binary blobs, at least in theory? (i.e. some existent reverse-engineering research) If not, why have they been chosen in particular? IMHO the "OpenWRT One" project hardware should not be worse than LibreCMC one As far as I know, there are no Wifi-5+ chips on the market that can run without blobs. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C Are these Mediateks capable of working without any binary blobs, at least in theory? (i.e. some existent reverse-engineering research) If not, why have they been chosen in particular? IMHO the "OpenWRT One" project hardware should not be worse than LibreCMC one On Wed, Apr 10, 2024 at 7:18 AM Bjørn Mork wrote: > > Michael Richardson writes: > > Bjørn Mork wrote: > > > > > I assume the private key must be protected on the device. What are the > > > hardware requirements? > > > > There are no hard and fast rules. It certainly would be best if it's in > > some > > enclave. But, my take is that something is better than nothing > > I agree that this sounds useful in any case. > > But a key which can actually certify that you're talking to that > specific device is so much better. I believe it should be seriously > considered if you're going to do this. > > Maintaining a PKI and adding more device specific data will have a > cost. Doing it "properly" might not be significanty more expensive. At > least not if you can use functionaliy already there in the SoC (or other > chips). Of which I know absolutely nothing, except that todays SoCs come > with more functional blocks than I can count on my fingers. > > > In the RFC8995 onboarding situation, it would be used directly during > > bootstrap, but then probably replaced with an LDevID with a more accessible > > private key. > > Thanks for the pointer. This section is pretty close to answering my > "IDevID howto for dummies" request: > https://datatracker.ietf.org/doc/html/rfc8995#name-initial-device-identifier > > (and a sidenote: I'm really impressed that you got the IETF to > standardize > > "BRSKI", pronounced like "brewski", is a colloquial term for beer in > Canada and parts of the Midwestern United States > > Great work! :-) > > > Bjørn > > ___ > 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
Michael Richardson writes: > Bjørn Mork wrote: > > > I assume the private key must be protected on the device. What are the > > hardware requirements? > > There are no hard and fast rules. It certainly would be best if it's in some > enclave. But, my take is that something is better than nothing I agree that this sounds useful in any case. But a key which can actually certify that you're talking to that specific device is so much better. I believe it should be seriously considered if you're going to do this. Maintaining a PKI and adding more device specific data will have a cost. Doing it "properly" might not be significanty more expensive. At least not if you can use functionaliy already there in the SoC (or other chips). Of which I know absolutely nothing, except that todays SoCs come with more functional blocks than I can count on my fingers. > In the RFC8995 onboarding situation, it would be used directly during > bootstrap, but then probably replaced with an LDevID with a more accessible > private key. Thanks for the pointer. This section is pretty close to answering my "IDevID howto for dummies" request: https://datatracker.ietf.org/doc/html/rfc8995#name-initial-device-identifier (and a sidenote: I'm really impressed that you got the IETF to standardize "BRSKI", pronounced like "brewski", is a colloquial term for beer in Canada and parts of the Midwestern United States Great work! :-) Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Bjørn Mork wrote: > Michael Richardson writes: >> I'd really like to find a way to work with your manufacturer to get an >> IDevID certificate into each unit as it is manufacturered. > For those of us who are not going to pay USD 100 for a document we > won't be able to comprehend anyway: Do you have a pointer to a "IDevID > howto for dummies"? Hi. The IEEE is rather daft, the 2018 version of 802.1AR is available free of charge, but it does require hoops. There isn't much content in it that you can't find in RFC5280. > I assume the private key must be protected on the device. What are the > hardware requirements? There are no hard and fast rules. It certainly would be best if it's in some enclave. But, my take is that something is better than nothing > What's the root of the IDevID, and why do I trust it? It's a private PKI root that we'd have to establish. > What's the lifetime of an IDevID certificate? Unlimited? The spec says: notAfter: 1231 > Are there any special constraints to consider when validating an IDevID > certificate? They don't tend to contain fqdn SAN, so the rules of RFC6125 (now RFC9525) do not tend to apply. > What's the typical usecase on a device like this? Signing short lived > device generated TLS server certificates for e.g a local https server? > Signing client certificates for CPE management (tr-x69 etc)? That's one. Or establishing a mutual TLS connection to a CA (RFC7030 for instance) that would then be able to provision a WebPKI anchored cert. > Do you ever use the IDevID certificate directly, or is it always just > an intermediate CA? Depends upon the use case. In the RFC8995 onboarding situation, it would be used directly during bootstrap, but then probably replaced with an LDevID with a more accessible private key. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Michael Richardson writes: > I'd really like to find a way to work with your manufacturer to get an IDevID > certificate into each unit as it is manufacturered. For those of us who are not going to pay USD 100 for a document we won't be able to comprehend anyway: Do you have a pointer to a "IDevID howto for dummies"? I assume the private key must be protected on the device. What are the hardware requirements? What's the root of the IDevID, and why do I trust it? What's the lifetime of an IDevID certificate? Unlimited? Are there any special constraints to consider when validating an IDevID certificate? What's the typical usecase on a device like this? Signing short lived device generated TLS server certificates for e.g a local https server? Signing client certificates for CPE management (tr-x69 etc)? Do you ever use the IDevID certificate directly, or is it always just an intermediate CA? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Fernando Frediani writes: > Yeah, USB may be Ok, but M.2 isn't for all usages, specially the > simplest and less costly ones. I see that a SD Card is still quiet > universal, very cheap for all sorts of projects. Would something like this work? https://www.mikroe.com/microsd-click Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Hi Felix Thanks for the clarification. Yeah, USB may be Ok, but M.2 isn't for all usages, specially the simplest and less costly ones. I see that a SD Card is still quiet universal, very cheap for all sorts of projects. Regarding the the standard for the SD card spec I can't answer that, but I would say that whoever uses it should not expect high performance, but rather simplicity and cost. Those who may need storage performance may well use the M.2. I see a Winbond 25N01GVZEIG NAND memory in the PCB which seem to be 128MB of storage. Can I understand that can be used similarly to a SD Card for projects which don't require much storage space ? Thanks Fernando On 04/04/2024 13:57, Felix Baumann via openwrt-devel wrote: Hi Fernando, the announced specs were Hardwarespecifications: * SOC: MediaTek MT7981B * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz) * DRAM: 1 GiB DDR4 * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE) * USB (host): USB 2.0 (Type-A port) * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port) * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) * Buttons: 2x (reset + user) * Mechanical switch: 1x for boot selection (recovery, regular) * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven) * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven) * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220) * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module) * Expansion slots: mikroBUS * Certification: FCC/EC/RoHS compliance * Case: PCB size is compatible to BPi-R4 and the case design can be re-used * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD) * Antenna connectors: 3x MMCX for easy usage, assembly and durability * Schematics: these will be publicly available (license TBD) * GPL compliance: 3b. "Accompany it with a written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code" * Price: aiming for below 100$ So yeah: no micro sd card slot. But you get usb and m.2 for storage which should be fine. What is it you require one for? Talking about SD but a bit exaggerated: The micro SD card spec has gone to shit anyways (who even has devices with UHS-III or SD express 7.0 or 8.0? Should the micro SD card slot use UHS-III or SD express? both at the same time isn't possible even though the cards look the same). The SD card spec can't keep up with CFexpress in the camera sector. Regards Felix Baumann ___ 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
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Am 4. April 2024 18:05:13 MESZ schrieb Fernando Frediani : >Hello there > >Good work so far. >Did I miss anything, but I couldn't find a SD Card slot. Isn't there one ? > >Regards >Fernando > >On 04/04/2024 07:00, John Crispin wrote: >> Hi, >> >> Just dropping a quick update on the OpenWrt One project. I've received the >> first batch of three PCBs for testing today. I am in the process of testing >> the hardware to make sure everything works as intended. >> >> There are twelve further early prototype boards on standby in case we need >> to tweak anything hardware-wise. You can find some pictures showing off the >> PCB from different angles at these URLs: >> >> http://mirror2.openwrt.org/OpenWrtOne_top.png >> http://mirror2.openwrt.org/OpenWrtOne_bottom.png >> http://mirror2.openwrt.org/OpenWrtOne_side.png >> >> Work is underway to establish a website where all legal information and >> links to our sources will be provided. Keeping everything transparent and >> accessible is crucial for us. >> >> MediaTek also generously released a substantial amount of programming >> manuals for the SoC used by the OpenWrt One which will be made available >> shortly. >> >> I would like to express my gratitude to the Software Freedom Conservancy >> (SFC), our manufacturer (BPi), the silicon vendor (MTK) and fellow >> developers for their support throughout this journey. >> >> John >> >> >> ___ >> 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 Hi Fernando, the announced specs were Hardwarespecifications: * SOC: MediaTek MT7981B * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz) * DRAM: 1 GiB DDR4 * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE) * USB (host): USB 2.0 (Type-A port) * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port) * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) * Buttons: 2x (reset + user) * Mechanical switch: 1x for boot selection (recovery, regular) * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven) * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven) * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220) * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module) * Expansion slots: mikroBUS * Certification: FCC/EC/RoHS compliance * Case: PCB size is compatible to BPi-R4 and the case design can be re-used * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD) * Antenna connectors: 3x MMCX for easy usage, assembly and durability * Schematics: these will be publicly available (license TBD) * GPL compliance: 3b. "Accompany it with a written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code" * Price: aiming for below 100$ So yeah: no micro sd card slot. But you get usb and m.2 for storage which should be fine. What is it you require one for? Talking about SD but a bit exaggerated: The micro SD card spec has gone to shit anyways (who even has devices with UHS-III or SD express 7.0 or 8.0? Should the micro SD card slot use UHS-III or SD express? both at the same time isn't possible even though the cards look the same). The SD card spec can't keep up with CFexpress in the camera sector. Regards Felix Baumann --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Hello there Good work so far. Did I miss anything, but I couldn't find a SD Card slot. Isn't there one ? Regards Fernando On 04/04/2024 07:00, John Crispin wrote: Hi, Just dropping a quick update on the OpenWrt One project. I've received the first batch of three PCBs for testing today. I am in the process of testing the hardware to make sure everything works as intended. There are twelve further early prototype boards on standby in case we need to tweak anything hardware-wise. You can find some pictures showing off the PCB from different angles at these URLs: http://mirror2.openwrt.org/OpenWrtOne_top.png http://mirror2.openwrt.org/OpenWrtOne_bottom.png http://mirror2.openwrt.org/OpenWrtOne_side.png Work is underway to establish a website where all legal information and links to our sources will be provided. Keeping everything transparent and accessible is crucial for us. MediaTek also generously released a substantial amount of programming manuals for the SoC used by the OpenWrt One which will be made available shortly. I would like to express my gratitude to the Software Freedom Conservancy (SFC), our manufacturer (BPi), the silicon vendor (MTK) and fellow developers for their support throughout this journey. John ___ 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
On 2024-04-04 12:00, John Crispin wrote: > Hi, > > > http://mirror2.openwrt.org/OpenWrtOne_top.png Looks nice. Is that silkscreened PD1 - 5V or PD - 15V? I guess it's not critical since PD auto-negotiates, but avoiding ambiguity is good. Were the chip numbers modified in the photos after? extra clarity? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Thank you for the update. I'd really like to find a way to work with your manufacturer to get an IDevID certificate into each unit as it is manufacturered. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
