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
> >
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
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
{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,
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
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
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 *
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
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,
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
> >
>
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
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
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
___
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
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
>
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
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
> 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
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
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
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
> 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
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
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,
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"
> 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
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
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
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
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
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
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
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
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?
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|
35 matches
Mail list logo
