Previously when their Yubikey 4's were found to be suceptible to the ROCA vulnerability [0], they issued replacements [1] for any customers who had affected devices. I had a few of those devices and they were replaced for free.
I guess that's a disadvantage of having a non-upgradable firmware. They can't fix these devices that are already out in the field.
As I understand it, the ROCA vulnerability is "the secrets generated by a YubiKey may be susceptible to classic cryptographic breaks", something along the level of "the cipher is inherently weak."
This vulnerability, meanwhile, appears to be in the class of "if someone has physical access to your hardware token, and has access to some specialized (expensive) hardware to do side-channel analysis, they might be able to do side-channel on your hardware token." But if someone has physical access to the hardware token... I mean, at that point, most people would consider it compromised anyways and wouldn't expect security guarantees from that point.
When I initially watched the demo video, I was wondering how the devices might locate each other. I thought it was using ultra wide band (UWB) like iPhones but now I see it’s just GPS. I’m not sure how many of these events are indoors vs outdoors, but it definitely won’t work indoors. Wonder how they might try to make it work indoors if there’s no additional hardware onboard.
A device can't locate other devices via GPS (GNSS apparently, which includes GPS and other systems); it can only locate itself. GNSS is only a receiver; there's no way to transmit unless you have a satellite. [0]
Having located itself, the device has to transmit its location to other Totem Compasses via other means. It says it uses 2.4 GHz spectrum and some stripped down, low-latency protocol (why does low-latency matter here?).
[0] I can setup a local cellular transmitter; has anyone tried setting up a GPS transmitter and hack it to send other useful information besides PNT? Yes, I know you can send misleading PNT info; I'm talking about doing something useful.
I think the Luckfox Pico series is the lowest cost ARM-based board you can buy (that runs Linux) at the moment. Even the Pi Zero is $10. Prior to this, it was a board based on the Allwinner F1C100, but I don't think anyone made and sold a dev board except for a DIY business card [0].
Doesn't look like it, but the author uses the Go SSH agent library [1] which _does_ have some example code there and looks pretty straightforward, based on what was described in the post.
It is indeed very straightforward. I did a quick check and I use this exact library for my "coarse-grained Debian diff" program, `meikkalainen` [1], and I was able to get it up and working mostly how I wanted within the same morning I started it. Very straightforward, even for a guy who doesn't spend a lot of time in the Goverse.
I remember when Dell was the first to introduce [1] these Compression Attached Memory Modules in their laptops in an attempt to move away from soldered-on RAM. Glad this is now being more widely adopted and standardized.
> The first iteration, known as CAMM, was an in-house project at Dell, with the first DDR5-equipped CAMM modules installed in Dell Precision 7000 series laptops. And thankfully, after doing the initial R&D to make the tech a reality, Dell didn’t gatekeep. Their engineers believed that the project had such a good chance at becoming the next widespread memory standard that instead of keeping it proprietary, they went the other way and opened it up for standardization.
Trying to make it a standard is one of the least surprising things about it. You want accessories/components in your product to be as commodity as possible to drive costs down.
It's pretty easy to apply seccomp to a process using systemd by adding SystemCallFilter= in its unit file. There's a reasonable set of permitted syscalls for general system processes, aptly called `@system-service`, but you can tweak that to suit your needs [1]. I generally use this, among other settings, to further lock down system services [2].
Interestingly the Pi 5 has moved most I/O like Ethernet, USB, MIPI and GPIO into a custom I/O controller chip called the RP1. It talks to the main CPU over 4-lane PCIe. They also have a custom PMIC (Dialog DA9091) with a built-in RTC and support for external backup battery. Everything else seems pretty standard.
> Interestingly the Pi 5 has moved most I/O like Ethernet, USB, MIPI and GPIO into a custom I/O controller chip called the RP1.
For cost-saving reasons, the I/O is located in the RP1 Southbridge (which has a larger process size) instead of the SoC. I had the opportunity to preview the Pi5 and have provided a detailed breakdown of the RP1's components [1]. In summary, what I/O functionalities does the RP1 manage? Essentially, it handles almost all of them.
I'm impressed to see this paragraph in the README:
> System76 customers may request board schematics for their system by sending an email to firmware@system76.com with the subject line "Schematics for model", where model is one of the supported models listed above.
> Please include the serial number of your system for verification.
This means that you can actually troubleshoot and repair the board yourself, if you're so inclined.
That's awesome. I've emailed other manufacturers asking for documentation and the best I got was an unrelated user help page. If I remember correctly, some of their laptops are based on Clevo parts. I wonder why they can release documentation but Clevo can't.
Previously when their Yubikey 4's were found to be suceptible to the ROCA vulnerability [0], they issued replacements [1] for any customers who had affected devices. I had a few of those devices and they were replaced for free.
I guess that's a disadvantage of having a non-upgradable firmware. They can't fix these devices that are already out in the field.
[0] https://en.wikipedia.org/wiki/ROCA_vulnerability
[1] https://support.yubico.com/hc/en-us/articles/360021803580-In...