PaX [comrade/them]

  • 1 Post
  • 9 Comments
Joined 2 years ago
cake
Cake day: July 15th, 2022

help-circle

  • Oh I had never heard of that vendor! I’ll have to check them out. I’ve been looking at AliExpress on and off but it’s really hard to find stuff unless you know exactly what you want.

    There’s some nice designs in China that seem impossible to get in the West. Would love to check out some of Loongson’s offerings or something like that. There’s also a line of Russian microprocessors called “Elbrus” that have a very interesting VLIW architecture. But that’s definitely impossible to get now with the sanctions.

    I guess neither of those would be suitable for a portable device anyway lol. Maybe I’ll just deal with it and get some cheap widely available ARM stuff.


  • the part where it’s running windows not so much but it’s a better kb layout for sure

    Yeahh lol they shipped with Windows CE. The cool thing is most of these have Linux or NetBSD ports!

    The ppp is growing on me, especially since suspend and camera and shit work now but it is still janky (mine tried to melt a pogo pin ) and the battery life is atrocious yeah (though not bad with the keyboard’s 6000mAh!!). It may end up being a bridge for me that leads to not having a smartphone at all though lol.

    Yeah I’m so glad they fixed the suspend. That really made the difference with it being usable or not. Sorry to hear about your pogo pin. One of my sim card holder pins broke off but I managed to shim it with a piece of tin foil lol. One of my other problems with hardware like this is that it’s so easy to break ;w;

    Honestly I don’t mind the boot-up, tow-boot with built in jump drive is nice, and once its in linux I don’t have to care.

    I just meant that the de facto standard for bringing up ARM machines is U-boot… which I hate dealing with. I just wish we had Open Firmware (IEEE 1275) everywhere rather than UEFI or U-boot tbh. Tow-boot is at least simple for the end user.

    For me it’s just a matter of something that actually works tho, I don’t have nearly the time to build my own shit with custom chips on an architecture with even less support than aarch64. I’m already putting a lot into getting shit to work on mobile linux ARM

    Oh of course, I just like hacking on hardware lol. I really dislike how PINE64 has taken such a hands-off approach with their hardware. It took years for the PPP to even get to this mildly-usable point. If I ever complete my hardware I’m gonna port the software it needs personally. Probably Plan 9 and NetBSD. (Linux is a mess all of its own…)





  • Well Linux is using rdrand in place of the fTPM one so … from firmware to hardware.

    That depends on your distribution’s setting of the CONFIG_RANDOM_TRUST_CPU compile-time configuration option and the random.trust_cpu sysctl setting. I’m not sure what the major distributions are doing with that at the moment.

    Then again even if you generate random numbers using pure software, is your CPU or firmware FOSS and without bugs (cough … Debian OpenSSL maintainers, cough …)? If not, and you assume you can’t trust the firmware and hardware - all your random numbers are belong to us.

    Like you said, it is impossible to be completely safe. But using proprietary cryptographic hardware/firmware, the inner workings of which are known only to Intel, introduces a lot of risk. Especially when we know the NSA spends hundreds of millions of dollars on bribing companies to introduce backdoors into their products. At least when it’s an open source cryptographic library they have to go to great lengths to create subtle bugs or broken algorithms that no one notices.

    Our CPUs are certainly backdoored too, beyond RDRAND. But it’s way more complicated to compromise any arbitrary cryptographic algorithm running on the CPU with a backdoor than making a flawed hardware RNG. Any individual operation making up a cryptographic algorithm can be verified to have executed properly according to the specification of the instruction set. It would be very obvious, for example, if XORing two 0s produced a 1, that something is very wrong. So a backdoor like this would have to only activate in very specific circumstances and it would be very obvious, limiting its use to specific targets. But a black box that produces random numbers is very, very difficult to verify.

    Ultimately, the real solution is the dissolution of the American security state and the computer monopolies.

    If I’m fucked, they’re fucked.

    Not if they’re the only ones who know about the backdoors.

    Edit: I started writing that before your edit about the “Ken Thompson hack”. An element of any good backdoor would include obfuscation of its existence, of course. The issue is it is impossible to predict every possible permutation of operations that would result in discovery of the backdoor and account for them. Maybe if you had a sentient AI dynamically rewriting its own code… anyway, backdoors in tooling like compilers is very concerning. But I’m not too concerned about a Ken Thompson type attack there just because of how widely they’re used, how many different environments they run in, and how scrutinized the outputted code is.



  • No, by running a relay or exit node you are opting in to routing traffic that could contain CSAM. This is a problem with all anonymous unmoderated distributed systems like Tor. With Freenet, for example, you’re even opting in to storing it (pieces of it in encrypted form that can’t be accessed without the content hash key).

    Privacy is good but so is censorship (moderation). The censorship just needs to be implemented by an accountable group of people that share the same interests of the users. Tor is trying to solve a problem that can only be solved through social struggle with institutions of power.