Generally, yes. Journals expect that the research is new. With most research labs (at least in CS) making their work freely available on the internet, the major value of publication is peer review. In my area, double-blind review is the norm, meaning the reviewers and authors don't know who the other is. Thus it's not clear to the reviewers if the prior research is even yours.
The expectation is you cite the previous work to clearly indicate it is not new, and that your submission for review is mostly about new research. In some situations overlap is okay, e.g. there's a conference version and then a journal version with additional results. In that case you disclose in writing what the delta is to the editor (who knows your identity while the reviewers do not). This also means in the paper you have to treat the prior work as if it is by a different group to maintain double-blind review.
The point is to make it clear what is new research. Trying to get credit for the same research multiple times, and boost citation count, is dishonest to the expectations of the community. It's also a waste of time for reviewers (who volunteer) to review same research over and over again after deciding it's acceptable. Think of it like a OSS maintainer getting pull requests for trivial changes to the code just to boost the green squares on someone's GitHub profile. It's a drain on everyone else and doesn't benefit the project.
Not only that, they use the gravitational potential of the falls to store massive amounts of energy when there's a surplus. Way cheaper to hold or even pump the water back up to the reservoir at the top than build lithium batteries. So yeah, as a local, can confirm they turn Niagara Falls (partially) off at night. Thanks to the Falls and several nuclear plants on Lake Ontario, Upstate NY and Southern Ontario have some of the lowest carbon electricity in the countries. Quebec is even better with basically all of their power coming from hydro.
This book in particular is primarily about error correcting codes.
Take a message we want to communicate and add some additional data that allows recovering the message even if part of it is corrupted. The hard part is choosing what additional data to include to recover from enough corruption with small overhead and in a reasonable runtime.
These are used everywhere from WiFi to hard drives to QR codes to RAM chips -- the ECC in ECC RAM being "error correcting code" and now partially mandatory with DDR5.
It's the essence of coding theory, not necessarily what's essential for all CS students to know.
One of the authors is at my university and teaches from this book. It's a math heavy upper-undergrad elective course. A couple percent of our students take it, usually in their final year of a 4 year computer science program.
The couple students I know who've taken it did enjoy it. They were also people who liked proof based mathematics in general.
WebUSB requires the device to opt in via it's USB descriptors. Otherwise any USB device with firmware updates would have this problem.
Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.
The devices are sold as programmable. The supplier loads their own code and has complete control over it. This is an advertised feature. Espressif also releases code that makes it into a Bluetooth adapter with a standard interface. Anyone in the supply chain can change the firmware without these commands. The concern is these commands were undocumented and exposed over an interface usually accessible by applications. The host drvier probably didn't expect this interface could make permanent changes.
ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.
Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. "Backdoor" isn't wrong, but it is misleading. The threat here is persistence from context that wasn't expected to have this capability.
Because it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.
Oh, and from the perspective of open hardware, these alarmist headlines are a real disservice. The natural reaction to debugging interfaces and firmware updates being "backdoors" and "security vulnerabilities" is to lock it all down.
Espressif has been an almost unique level of open for this space. They've contributed to open source Rust toolchains for their chips. They've even publicly encouraged reverse engineering of their modem stack because it contains licensed code they can't release. I hate to see bad and damaging publicity be the reward for being just a little bit open.
Agreed. This is pretty common and no worse than a firmware update. The potential catch is in-band debugging may not require the same privileges on the host you'd expect from a firmware update. So conceivably your userspace (or worse WebBLE, not sure) program could add some malicious payload that's persistent in the adapter. Tracking beacon that persists through a drive replacement is scary, but not an RCE
I think the title is a bit misleading. If I'm reading correctly, the "backdoor" allows a computer to peek and poke memory and other low-level functions of its own USB Bluetooth adapter. I don't this this is usable over the air?
Undocumented debugging commands like this are common. I've worked with at least two chips, a WiFi adapter and a GPS receiver, that had similar functions. Neither was documented, but found by reverse engineering the chip firmware or vendor drivers. It's not exactly an impactful issue on its own. Anything that allows unsigned firmware is equally vulnerable.
If I'm misunderstanding and this is usable from anything other than the host, that would be a very different story.
Section 2.4 gives a concrete example, though there are some asterisks. The example is one where a compiler rewrites something like `while (...) x++;` to put `x` in a register: `int reg = x; while (...) reg++; x = reg`. The author reports this is an optimization GCC was observed doing, and means you can have a read-writeback even when the while condition is false to begin with. If this optimization appears interleaved with identical writes then you have problems.
Agreed with the sentiment that this isn't that bad. As far as chip errata go, it's definitely unusually broad impact. So yeah, it's an abnormally bad bug. But for your average Pi Pico user, they still will never notice. The only possible thing I could imagine your average micropython tinkerer needs to know is "use pullups not pulldowns with buttons on the Pi Pico 2". Everything the entry level hobbyist is likely to encounter is a sufficiently strong drive to avoid the issue. Capacitive touch buttons might not work without external components, but I don't know.
Bigger picture, RPi is doing their third ever chip fab. The errata (silicon bug) list for the prior RP2040 is shorter than some I've seen from companies five times their age.[1] This issue isn't a logic error and wasn't going to be found by digital simulation. This is analog weirdness. Their documentation, including of errata, is among the best I (moderately experienced hobbyist) have ever encountered for a microcontroller. RPi is doing an excellent job and this is a but a hiccup. Maybe it's concerning for industrial customers, but as a hobbyist I'm still excited for my Pico 2 to arrive.
[1] Favorite errata warstory: Radio chip will lock up and need to be power cycled if a received packet has a particular corrupt length field, one bit flip away from one we used. Official solution: don't allow packet corruption. Turns out radios don't work like that.
After this was published, RPi concluded the problem was a leakage current and updated the datasheet [1]. Roughly, a tiny trickle of electricity, about 100 microamps, flows out via the pin when it shouldn't. This can raise the voltage to around 2V unless you provide a path to drain it away.
I've ordered one and am confident for anything I'd do it's not an issue. Usually any input I have is connected directly to the output of something else and that provides the path for the leakage current. If that isn't true, e.g. a button, then I'm using a pull-up and thus also not affected. Certain analog measurements could be affected, but again not if they have a low impedance (i.e. strong) source. The current is around 100 microamps so it's not stressing the source much.
It's unfortunate that this is happening in the chip that so massively improved the low power sleep states. Designs needing wake from sleep on pin change with an active high / inactive high-z signal are not going to be good. That requires a strong external pulldown and will be constantly burning those 100ish microamps. That doesn't sound like much, but it's a lot of power for being asleep.
Still I'm very excited for the improved CPU performance and even more RAM. Once mine arrives I'm going to see how much faster it can do some fixed point DSP than the RP2040.
The "chip rate" of GPS L1 C/A (the main one) is 1023 kchips/sec. So you end up with a signal that is over 1 MHz wide to encode 50 bits/sec. Nyquist-Shannon theorem says* you thus need over 1 Msamp/sec (using complex numbers), probably more like 2 Msps because of Doppler, to capture that. GPS is pretty forgiving and 4 bits/sample is plenty (2 bits is usable), but that would still be 1 MB/s of high entropy data. Note the system linked in the parent comment only records in 12 ms bursts. That captures enough info to find position offline, but only if you add in the historical orbit information that normally takes 30 sec to download off of the GPS signal. Streaming 1 MBps of data is doable, but I think would draw much more power than solving on device. Just recording to an SD card is far less.
* The Nyquist-Shannon theorem actually says the converse, but for anything you'll encounter outside the recesses of a math department, it's still the optimal solution.
All of them I am aware of do hardware decoding of the signal and do the linear algebra to find their location in software. Speaking mostly based on the cheap ublox chips and partially open source navspark chips I've dealt with.
The problem is the signal processing part of GPS is quite computationally difficult. I think it was around 10ish years ago it even became possible to do the full real-time decoding on a laptop. At startup, you need to find the GPS signals. This means searching for all 32 possible satellite code patterns across the range of possible Doppler shifts. During testing, this was what took most of the startup (cold start) time. You need roughly 4-6 of them to get a position, so this has to be done in parallel. Once you've found the satellite it takes another 30 seconds to get the satellite position. GPS signals are very slow at 50 bits/sec.
By comparison, actually solving for location is a simple linear algebra problem with 4 unknowns (lat, long, alt, time; but in a more convenient coordinate system). You only do this a few times per second. The hardware does the higher rate signal phase estimation. For example the navspark is a single core SPARC microcontroller running at 100MHz with 200 kB of RAM. That's enough to do 50 solutions per second, though they reduced that to 10 Hz to make space for a user program too.
A ton of work goes into caching strategies to narrow down that initial search space. Modern chips will let you load in exactly which satellites to expect overhead (e.g. based on position and orbit info from cell network). There is a whole other caching strategy based on a approximate "almanac" in the GPS signal for offline devices. With all of that known before the receiver turns on, you can get a solution in a couple seconds.
It's true that the bigger question is "what is the impact of a collision?". For many of them, the answer is probably nothing. In an industry where 1 in 10,000 makes people uncomfortable though, I think it's enough be to be potential headache. Increasing density of LEO would make that worse. It doesn't need to be a runaway effect to be economically or especially politically problematic.
Proactively deorbiting at EoL is definitely the correct move, but requires enough runway to continue short term operations. I can absolutely picture this being used as political leverage.
This is concerning to me, but not quite for the reason the article suggests. SpaceX is doing the right thing here by maneuvering and using Very Low Earth Orbits to cap the amount of time a failed satellite can stay up before falling. What if the maneuvers stop though? Say they run into financial issues and cease operations.
25,000 1-in-100,000 collision probability events in 6 months is actually pretty high. Without actively controlling the satellites to avoid you get:
1 - (1 - 10^-5)^(50e3) = 0.39...
chance of collision per year.
SpaceX says Starlink satellites should deorbit in about 5 years if they don't keep actively boosting their orbits. That still means a 90% chance of a collision before deorbit if they stop maneuvering. Those debris would be in low orbits and also decay quickly. You could still to some real damage to any of your neighbors in that time though.
From a regulatory perspective, I sincerely hope the FCC and others are thinking about what contingency plans need to be in place if SpaceX became financially unstable. They've basically guaranteed themselves a government bailout at this point. The UK did that to OneWeb for purely economic reasons. If SpaceX goes under, they're taking LEO with them.
They moved away from SWIG and to PyBind11. As they mention, this is going to be an annoying transition for my custom out-of-tree modules. Overall though, I'm excited for the changes.
Lots of new GUI blocks in this release. I'm especially glad to see the new eye diagram.
Also the ability to load non-WAV audio files will be nice. OGG/Vorbis and FLAC are now supported. Plus a slew of minor conveniences such as a freq shift block and scaling options in the IShort to Complex block (useful for loading recorded samples from hardware).
The expectation is you cite the previous work to clearly indicate it is not new, and that your submission for review is mostly about new research. In some situations overlap is okay, e.g. there's a conference version and then a journal version with additional results. In that case you disclose in writing what the delta is to the editor (who knows your identity while the reviewers do not). This also means in the paper you have to treat the prior work as if it is by a different group to maintain double-blind review.
The point is to make it clear what is new research. Trying to get credit for the same research multiple times, and boost citation count, is dishonest to the expectations of the community. It's also a waste of time for reviewers (who volunteer) to review same research over and over again after deciding it's acceptable. Think of it like a OSS maintainer getting pull requests for trivial changes to the code just to boost the green squares on someone's GitHub profile. It's a drain on everyone else and doesn't benefit the project.