The Raspberry PI PICO 2, now has extra RISC-V cores

[SpacedCowboy]

That happens when you start to play with off the shelf silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..) 

I think that'a a bit harsh. Raspberry Pi asked the *vendor* to modify the pad logic, they didn't do it themselves - which meaning could be inferred by your comment. If anyone should be able to do it correctly, it's the people who created the IP in the first place.

[radiolistener]

You're right, but on the other hand.  Don't forget that this MCU, and many/most other MCUs, can (due to faulty code or failure), over-write their flash based firmware/software, which for something out in the field (e.g. a product released to customers), would essentially destroy the device.

Yes, thats true. But it's easy to recover it with SWD.
While OTP writing is unrecoverable action and will need to replace MCU or even entire device.

[iMo]

That happens when you start to play with off the shelf silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..) 

I think that'a a bit harsh. Raspberry Pi asked the *vendor* to modify the pad logic, they didn't do it themselves - which meaning could be inferred by your comment. If anyone should be able to do it correctly, it's the people who created the IP in the first place.

Ok, I am correcting my sentence herewith:

That happens when the silicon library vendor starts to play with his silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..) 

[radiolistener]

Do you let others run code on your microcontroller?

Yes, anyone who use for example C compiler uses it's libraries and startup code. If you use some third party modules, they also can be vulnerable and allows to execute some code on your MCU.
These days it's hard to write entire code with no using third party libraries and fully isolate MCU code from any possible intervention.

And if your MCU has some communication with internet, it can be hacked with some kind of buffer overflow and execute hackers code on your MCU.

For example see Broadpwn attack, which allows for remote code execution on your smartphone or tablet with no need physical access to it, it is possible if it uses Broadcom’s BCM43xx family WiFi chipset and don't have patch...


So, just imagine that your expensive device may unexpectedly stops to work and when you try to analyze what is going on all what you can see is that the chip is dead due to OTP bit write and you even don't have chance to survive it.

[MK14]

Yes, thats true. But it's easy to recover it with SWD.
While OTP writing is unrecoverable action and will need to replace MCU or even entire device.

Once a product is sold to customers, SWD very likely, wouldn't help the end user, and the MCU may use other methods, anyway.

As already said (emphasis added by me):

Ability to persistently lock up the device and prevent any further access even after an erase is a new feature that is being introduced in most new devices, since customers demand that..

Some customers, want it that way, for their applications.

[tszaboo]

Do you let others run code on your microcontroller?

Yes, anyone who use for example C compiler uses it's libraries and startup code. If you use some third party modules, they also can be vulnerable and allows to execute some code on your MCU.
These days it's hard to write entire code with no using third party libraries and fully isolate MCU code from any possible intervention.

And if your MCU has some communication with internet, it can be hacked with some kind of buffer overflow and execute hackers code on your MCU.

For example see Broadpwn attack, which allows for remote code execution on your smartphone or tablet with no need physical access to it, it is possible if it uses Broadcom’s BCM43xx family WiFi chipset and don't have patch...


So, just imagine that your expensive device may unexpectedly stops to work and when you try to analyze what is going on all what you can see is that the chip is dead due to OTP bit write and you even don't have chance to survive it.

You can brick something if you call block erase on the bootloader. It's recoverable in theory, but impossible to do in practice.
So anything with a flash is already vulnerable with your strange world view.

[radiolistener]

The programming procedure is pretty complicated, it is hard to invoke it by error.

Once your firmware or bootloader has OTP write unlock/write procedure for factory configuration, it can be executed with unexpected state and data... It can be random error, due to some power or EMI condition or can be due to hackers attack...

You can brick something if you call block erase on the bootloader. It's recoverable in theory, but impossible to do in practice.
So anything with a flash is already vulnerable with your strange world view.

Good MCU has bootloader code in a factory written OTP memory which don't allow to erase/write with no physical intervention into the chip die... So you can't brick it. Even if you disable SWD, it can be bypassed and all firmware restored.

[ataradov]

You can accidentally erase part of the firmware in the flash.

Short story here is that it is not a real issue. It is only an issue if you want to complain about something . Most new devices contain OTP memories and this is not going to stop.

EMI may happen, but this is not an MCU issue. It is on the equipment manufacturer to define the level of EMI compliance, design the equipment accordingly, and then test that compliance.

By the same token, you can complain that RP2350 can't survive direct mains connection to the pins. What if a user has exposed wiring and it accidentally touches the pins? You would have to replace the MCU or throw away the device.

[radiolistener]

Short story here is that it is not a real issue. It is only an issue if you want to complain about something . Most new devices contain OTP memories and this is not going to stop.

Yes, if we see at Broadpwn exploit, millions users have tablet, smartphone or other gadget with Broadcom’s BCM43xx WiFi chip. But not all of them were hacked with Broadpwn exploit despite the fact that they all were vulnerable for it before patch. And many of these who were hacked, even don't know about it, so they don't complain.

The same applies to OTP programmable features available for writing after factory settings. Not all users will lose their devices because of this. Even those who do, won't know exactly what happened. They will just see a dead device and will need to spend more money on a new one. I can understand manufacturers who want more bricked devices because it increases demand for new devices. But this approach is definitely not good for the user and certainly not fair. It can be seen as the manufacturer cheating.

[MK14]

Yes, if we see at Broadpwn exploit, millions users have tablet, smartphone or other gadget with Broadcom’s BCM43xx WiFi chip.

No.
That is completely off-topic.

This thread is about a new embedded MCU, not something which runs a fairly big OS, such as Android, with Wi-Fi.

[radiolistener]

This thread is about a new embedded MCU, not something which runs a fairly big OS, such as Android, with Wi-Fi.

Broadpwn exploit is not about big OS. It's about the smallest deeply embedded ARM Cortex-R4 MCU (armv7-R) with about 900k firmware running on WiFi chip. It has even less resources than RP2350. I mention it as an example that hackers can execute any code on your MCU even if its protected.

So, OTP-configurable MCU features that can be written after the chip leaves the factory are bad for the user. This is because the user can't write-protect these bits and is forced to accept the risk of losing their device at any time without the possibility of recovery by completely rewriting the firmware and data from backup.

[MK14]

Broadpwn exploit is not about big OS. It's about small Cortex MCU with about 900k firmware running on WiFi chip. It has even less resources than RP2350. I mention it as an example that hackers can execute any code on your MCU even if its protected.

So, OTP configurable MCU features which can be written after chip leave factory is a bad thing for the user. Because user can't write protect these bits and is enforced to accept the risk that he may lose his device at any time without the possibility of recovery by completely rewriting the firmware and data.

Let me check my understanding then.

So my project or product (hypothetical), is a sealed electric toothbrush, with an RP2350 for brains, no Wi-Fi/Blutooth or USB sockets.  No OS whatsoever, all handcrafted C code.

It PWMs the motor for up to 2 minutes, when its single button is pressed, and turns a green LED on, while running.  If the battery is low, it changes the LED colour to red.

How exactly, does the hacker, thousands of miles away, change the OTP?

[radiolistener]

So my project or product (hypothetical), is a sealed electric toothbrush, with an RP2350 for brains, no Wi-Fi/Blutooth or USB sockets.  No OS whatsoever, all handcrafted C code.

electric toothbrush don't needs so powerful MCU, it's obviously too expensive and too powerful for this task. The projects where RP2350 can be used is more complicated and may use communication modules.

How exactly, does the hacker, thousands of miles away, change the OTP?

Even with electric toothbrush example you might accidentally write something in OTP when you play with MCU during development and lose it... This is the main risk that I see for myself as for developer.

[MK14]

electric toothbrush don't needs so powerful MCU, it's obviously too expensive and too powerful for this task.

It uses, a very complicated, 4 phase, ultrasonic cleaning pattern, which gets around all pre-existing and currently active patents.  Needing the full power of all 3 PIO units.

I'm planning to call it the Hyperphetical-SuperClean-2350, with OTP unit for increased reliability and cleaning power.

Even with electric toothbrush example you might accidentally write something in OTP when you play with MCU during development and lose it... This is the main risk that I see for myself as for developer.

But I might also accidentally destroy the prototype, with static electricity, by accidentally setting the bench power supply to silly high voltages, or be so frustrated with someone on a forum, that I throw the only prototype, hard against a wall, smashing it to pieces.

Yes, the prototype electric toothbrush, could be run over by a bus, with a big advert on the side of the bus that says "Vote NO to OTP".

But life is full of risks, without going wildly overboard, with worrying about things, which are extremely unlikely to happen.

[tszaboo]

electric toothbrush don't needs so powerful MCU, it's obviously too expensive and too powerful for this task.

It uses, a very complicated, 4 phase, ultrasonic cleaning pattern, which gets around all pre-existing and currently active patents.  Needing the full power of all 3 PIO units.

I'm planning to call it the Hyperphetical-SuperClean-2350, with OTP unit for increased reliability and cleaning power.

Even with electric toothbrush example you might accidentally write something in OTP when you play with MCU during development and lose it... This is the main risk that I see for myself as for developer.

But I might also accidentally destroy the prototype, with static electricity, by accidentally setting the bench power supply to silly high voltages, or be so frustrated with someone on a forum, that I throw the only prototype, hard against a wall, smashing it to pieces.

Yes, the prototype electric toothbrush, could be run over by a bus, with a big advert on the side of the bus that says "Vote NO to OTP".

But life is full of risks, without going wildly overboard, with worrying about things, which are extremely unlikely to happen.

I have a toothbrush with OLED display and Bluetooth.
It's not even expensive, cheaper than my dentist visits.

[MK14]

I have a toothbrush with OLED display and Bluetooth.
It's not even expensive, cheaper than my dentist visits.

If my post hadn't been a hypothetical (joke), to illustrate why the OTP is acceptable.  It probably would have had Bluetooth, wireless charging and other features.  But I left them out from my hypothetical example, as the other poster, might have used them as a mechanism to allow hackers, to change its OTP, in order to damage it.

There is a tiny bit of danger/risk, by having OTP disabling features in the RP2350.  But like with lots of things in life, things are an overall balance of risks and features.

Overall, I suspect the OTP is (part of the system, that provides) a very big boost to the security of the device, if needed, in some applications, for some customers.

[ataradov]

Also, if you are so afraid of OTP and don't use it in your application, just program it yourself to whatever value you like. Then nobody else would be able to change that for you.

[tszaboo]

There is a tiny bit of danger/risk, by having OTP disabling features in the RP2350.

I agree. I find it ridiculous how we are discussing that having OTP is a danger. Also OTP in the bootloader is somehow OK, but not somewhere else.
And you can just reflash PCI-Express network cards now. But we should give radiolistener a break, it's stressful to live in that country now.

[radiolistener]

I have a toothbrush with OLED display and Bluetooth.
It's not even expensive, cheaper than my dentist visits.

OMG, be careful, someone may hack your toothbrush from internet... 

[langwadt]

..I'm planning to call it the Hyperphetical-SuperClean-2350, with OTP unit for increased reliability and cleaning power.

with OTP so copycats won't be selling toothbrushes running verbatim copies of your firmware next week

[MK14]

with OTP so copycats won't be selling toothbrushes running verbatim copies of your firmware next week

Exactly!

Apparently, that was one of the big complaints about the previous RP2040, lack of firmware security, especially with an external flash chip.

OTP is useful for writing one-time production serial-number/batch-number/security-codes/date etc.  In the knowledge that would be hackers, can't easily change it, like they could if it was simply in flash somewhere.

EDIT:  I'm speculating here.  But, if your secure code runs on the Arm M33 cores.  Disabling the RISC-V processors, on production units, permanently via the OTP.  May make it more secure, as access to the RISC-V mode, could be an avenue for hackers to get round some of the security features (maybe?, speculation, as I said earlier).

In the same way, on a secure server.  Unnecessary services, IP-ports and things, may be disabled, and other things, to try and make the server more robust against attackers, trying to hack into it.  E.g. Disabling external (non-local) SSH access, if it is NOT required.

[rteodor]

Tamper resistant systems are always controversial. It is by our human nature how we judge them: on one side are societal safety benefits (e.g. safety in automotive/avionics/medical/industrial, economic righteousness in meters) on the other side is the potential for abuse (in various ways either by manufacturers with bad market manners or by hackers with destructive intent).
Different people look at at such systems from one or the other end depending on their cultural background.

Without discussing the exact implementation on RP2350 with datasheet in front, the discussion will undoubtedly drift towards the "forever question": who benefits from using tamper resistant systems? And both sides will remain frustrated as such answer is not to be found now but in each particular future use of it.

At this point it seems obvious that RP2350 is intended to be sold to the bigger market. Be that from one or the other side of the spectrum as described above. For now Broadcom wants to up the game for this device. Some will find this a hair rising, tooth sharpening bad sign, others will see it as a big and needed improvement. Again, the answer is not here and definitively not available now.

[brucehoult]

My pico2 will arrive next week, will try out your suggestions.

Mine arrived today (29th), in (very) rural far north New Zealand. Ordered from Pimoroni (UK) on the 17th, shipped on the 20th.

The same mail contained a 16 GB RAM Sipeed Lichee Pi 3A (8 core SpacemiT K1, with 256 bit RVV 1.0 vectors).

Hard to know which to play with first.

[bob1033]

Looks like the GPIO latch-up issue can happen even without pullups/pulldowns enabled
https://github.com/raspberrypi/pico-feedback/issues/401

[MK14]

Looks like the GPIO latch-up issue can happen even without pullups/pulldowns enabled
https://github.com/raspberrypi/pico-feedback/issues/401

If that is true, I'd be very disappointed with the teams, testing and validation performance.  As that would be such a fundamental datasheet specification.

I.e. This part of their datasheet specification (Page 1323):

Pin Input
Leakage
Current
IIN 1 μA

Reading the supplied link, it seems as low as a 9k Ohms pull-down resistor (with 4k7 seeming to be the initial value, which reliably work as a pull-down, but best to wait until an official 'fix' is announced), is needed to defeat the potential latch-up.

This seems pretty fundamental and bad, on the face of it.

EDIT:  I.e. An MCU with many of its pins having unreliable inputs (when somewhat weakly driven).

EDIT2: It is good that there can be workarounds, but in my initial opinion, that does really need to be fixed.  But it would probably cost something like (based on the IC processes process node of 40nm and my recent/quick research on the costs, perhaps a few days ago) $850,000 just for the mask(s), and perhaps millions more in practice, for the overall cost.