Hugo Landau

Yeah, the security part wasn't baked into the hardware. It relied on the OS (it ran a virtualization layer of sorts) to enforce it via traps if it set those traps. From https://www.devever.net/~hl/ppcas > As such, they can principally be viewed as providing a performance enhancement for the IBM i operating system, which uses these instructions to keep track of pointer validity. It is the IBM i OS which enforces security invariants, for example by always following every pointer LQ with a TXER.

> My main question is: Is there any method or configuration that can ensure that even on my self-hosted VPS, the provider cannot access my data? Short answer: No, you cannot. Long answer: It depends on the resources they plan to allocate on the task. This article provides an excellent deep dive into the topic, based on an fairly recent incident involving an XMPP server in Germany: https://www.devever.net/~hl/xmpp-incident

Had to reverse engineer a real mode PCI option ROM once... that was extremely unpleasant [1]. And then of course there's "Unreal Mode". Moreover Intel is just this week actually finally proposing removing real mode. [2] I'm a bit worried for what this means for emulation of old 16-bit Windows and DOS software under Wine (one of the great ironies that Wine can still run Win16 programs on an x64 host OS when Windows can't) - though I suspect the performance requirements of such software is so low by modern standards that emulating such programs wouldn't pose any challenge. [1] https://www.devever.net/~hl/ortega [2] https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

Great read, though even more interesting is this gem buried in the footer about the inappropriate use of XML: https://www.devever.net/~hl/xml

This author has some great stuff, minutiae of internet history I would have never thought to care about all made quite interesting! Another good read: https://www.devever.net/~hl/gatekeeper

I liked this summary: XML is almost always misused [1] The gist is that XML is best used for markup, because it inherits assumptions from the "document" metaphor that are not needed and are sometimes unhelpful for data interchange. An example of this is hashmaps & sets--they intentionally leave "order" or "sequence" out of their representation, but documents as a form of data interchange force you to keep thinking about it. [1] https://www.devever.net/~hl/xml

I believe because the original AS/400 hardware used a proprietary CPU (Called IPMI ?) and proprietary RAM that had extra space for tag bits. When the AS/400 was moved to POWER processors, IBM added extensions for OS/400 called PowerPC AS[0], and uses some "magic" to store a tag bit in the ECC bits of standard RAM. Also, "Fortress Rochester" by Frank Soltis (the follow up to Inside the AS/400) gives a detailed look at the differences compared to other systems. [0] https://www.devever.net/~hl/ppcas

"Where Christianity has left a moral and religious vacuum in the wake of its collapse, we are now seeing the construction of a new social and moral orthodoxy to fill this void — in short, a new religion. It's not hard to see why: religious orthodoxy brings with it the highly intoxicating and addictive frameworks of unambiguously delineated good and evil, right and wrong, us versus them, and the equally addictive sense of moral righteousness that follows from it. In short, many people have a psychological dependence on religion; they need such a thing."[0] [0] The Rise of Newchurch (https://www.devever.net/~hl/newchurch)

Here's a fantastic article about the various misuses of XML that I greatly enjoyed: https://www.devever.net/~hl/xml

> In hindsight, how would you have used the documentation of the Raspberry Pi architecture to determine whether UASP is supported? Doesn't really depend on the Pi hardware at all, it depends on the kernel driver (kernel must be new enough) and the USB storage device (does it implement UASP in addition to legacy bulk-only-transport?). https://www.devever.net/~hl/usbuas has a great explanation of the nitty-gritty details.

I am reminded of this: https://www.devever.net/~hl/nexuses "[...] because nobody programs in C++ — everyone programs in their own unique subset of the language. If you are told a program is written in C++, that leaves the following questions: Does it use, or eschew, exceptions? Does it use, or eschew, C++ RTTI? Does it use operator overloading? Does it use, or eschew, the STL? Does it use, or eschew, C++11/C++14/etc. features? Does it use templates? Does it use virtual functions? Does it use multiple or virtual inheritance? Does it use static objects with constructors?"

The thing with cloud and with anything related to it, anything that connects to the internet somehow... is that, unless it's open source and the servers decentralized, you are always trusting SOMEONE. Sure, Apple might make their best to ensure nobody – but them – have access to your data... but Apple controls all the end points. It controls the updates your iPhone receives, it controls the servers where this happens. Like, they are so many opportunities for them to find what you are doing. It reminds me of this article "Web-based cryptography is always snake oil" https://www.devever.net/~hl/webcrypto And to be fair, this doesn't apply only to this case. Even the data you have stored locally, Apple could access it if they wanted, they sure have power to do it if they so wish or were ordered by the government. They might have done it already and just didn't told anyone for obvious reasons. So, I would argue the best you could say is that it's private in the sense that only Apples knows/can know what you are doing rather than a larger number of entities . Which, you could argue it's a win when the alternatives will leak your data to many more parts... But still far away from being this unbreakable cryptography that it's portrayed it to be.

Why was POWER9 open? https://www.devever.net/~hl/backstage-cast > For Intel and AMD, the demarcation point between them and their customer is the CPU, so if they want to keep secrets and maintain a stable interface between them and their customers, they're effectively pushed to do it at the CPU boundary. With IBM, this historically hasn't been the case; traditionally, IBM has only sold servers containing their own CPUs, not the CPUs alone. This means that traditionally, the only customer for IBM CPUs has been IBM — which means there's far less motivation for IBM to lock things down. Moreover, IBM Power servers have traditionally shipped with a proprietary hypervisor (known as PowerVM) built into the firmware. On these servers, all OSes run under this hypervisor, and you can't run an OS directly on the bare metal. This means that the natural interface between IBM and its customers has naturally fallen at the hypervisor—OS interface, not at the CPU.. > When IBM suddenly decided to open up their POWER CPUs for use by third parties, they made available a platform which for its entire lifespan up until that point, hadn't evolved under the same pressures as the existing x86 CPU market, but instead in an environment in which there was really no natural motive for them to lock things down at the CPU level. Which is almost certainly why IBM POWER CPUs seem to so greatly lack any “curtains” — the curtain had always been shipped with the hypervisor, not the CPU. Why did POWER10…

I choose not to engage in proprietary newletter programs, but do read a lot via RSS. Here are some that I consider insightful and/or interesting, above average quality, have limited or no commercialization/monetization, and have a chance of being interesting to someone else: OldHouseGuy Blog: https://www.oldhouseguy.com/ Has great taste regarding old buildings Syonyk/Sevarg/Russell Graves: https://www.sevarg.net/ Some combination of /homesteading/off-grid/tech passion/tech skepticism/ The Long Now Blog - makes me think different things Early Retirement Now - in depth financial writings regarding saving money more than the common person. Tynan.com - eclectic person Hugo Landau: https://www.devever.net/~hl/ - Thoughtful insights on tech and adjacent topics. Casey Handmer - Crazy dreams about space and carbon scripting.com - Old guy shouting at clouds, old-school Internet guy building stuff. I just read it for variety.

The imagined use-case for Pushup is the same niche that Rails, Django, and Flask apps occupy, which is a wide range but broadly I would describe as page-oriented, HTML-first, server-side frontends. I started Pushup because I asked myself, I like programming in Go and think (like you) it's great for web backends - but what is holding it back from being a great full-stack web dev language or environment? net/http is a great building block, and html/template is solid, but I felt more was needed. Like opinionated project directory structure, for one. But also the world has changed since 2006 when Rails and Django debuted. Obviously, we live in a world in which React and the SPA is seemingly dominant, but projects like htmx have recently shown that you can achieve modern UI/UX in the browser on a server-side app, which less JavaScript. BTW, more and more JavaScript frameworks, like Remix, are (re-)discovering the value of SSR. I was also motivated to give an old-school mod_php feel of, just add a file and you automatically get a URL route. That's a nice developer experience but also good for long-term project maintenance. Finally I was struck by this essay[1] about the demise of the "mildly dynamic" site. There is a wide diversity of types of sites and apps, from quick experiments and prototypes, small-to-medium sites of many kinds. But also since it's Go, I think it could scale up on performance to large-scale sites, and as a static binary, be nicely suited to edge apps like…

It would be interesting to throw this URL as far up the internal chain as possible... and see what happens. :P I'm curious myself, and there are a lot of other people who wouldn't mind knowing too. Fast AND trustworthy turnkey silicon is both a completely untapped hole in tech at the moment and something that's desperately needed in this climate of NDA'd garbage-quality security systems (see https://www.devever.net/~hl/smartcards for one of thousands of examples) and increasingly locked down chipsets. I'm not sure what else is out there, but I recently learned of RISC-V (http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in… ); I'll admit I was impressed to learn a free (open design) CPU has just broken the GHz barrier (http://riscv.org/download.html#tab_rocket_core), but this chip and ISA are still in the early prototyping stages, although the spec seems complete. On the other hand, x86 is a widely (!) used, well-known ISA with a lot of legacy software running on it, and VIA already have proven CPUs and chipsets and motherboards. I only know about VIA as "the low-power alternative CPU company," so I have no idea what it's position or stance on secure applications is, but it could well net itself some unique contracts by investing in security. One of the big problems in this space (or at least what's being made into a problem by the major chip vendors) is secure bootstrapping: I can verify the entire boot device (a 128MB boot image could…

You can mitigate this with DNSSEC, CAA records and account pinning. See: https://www.devever.net/~hl/xmpp-incident

Well https://www.devever.net/~hl/xmpp-incident It's a problem. But it has technical rather than political solutions.

According to this: https://www.devever.net/~hl/ppcas the POWER approach is not a true hardware capability architecture (“nothing about these ISA extensions provides any kind of security invariant against a party which can generate arbitrary machine code”). It's just something that helps software to store one bit per 128 bits of data on the side (plus some other weirdness about load-with-offset instructions). (SPARC ADI is similar, machine code is still trusted.)

Remember, that German government made an attempt to secretely wiretap Jabber.ru XMPP node without any legal basis: https://www.devever.net/~hl/xmpp-incident

I always wondered how secure AS/400 actually is. The original implementation might have checked tag bits in hardware (I don't know), but the current (PowerPC) implementation relies on the compiler generating a "check tag bits" every time a pointer is dereferenced [1]. So it seems that any arbitrary code execution vulnerability would be absolutely devastating. And the "SLIC" is not a small microkernel -- it also contains the compilers, the database and other system components. It'd be hard to believe there would no exploitable bugs in there. [1] https://www.devever.net/~hl/ppcas

From a different direction, I'd suggest https://www.devever.net/~hl/kvm

No, the problem with attributes is that people consistently misuse them. So many things about XML break down when you make everything a self closing tag with 50 attributes. So many programmers just seem to say, "oh, it's shorter text so it must be inherently better" or "oh it's one-to-one so I should strictly avoid anything resembling a heirarchy." Like I think this guy is mostly correct in identifying bad XML: https://www.devever.net/~hl/xml Though I don't necessarily agree with the "data format" framing. This idea that markup languages are not data formats seems confused. > They don't. You absolutely don't need a schema. If you declare a schema, it should exist. If not, no problem? I agree that they should not. However, I have used many tools that puke when presented with XML fragments or XML with no schema.

This schtick is just that, a schtick thats only as strong as whoever is fighting against it... https://www.devever.net/~hl/webcrypto

The article's insistence on differentiation between "web sites" and "web applications" and a further article linked in the footnotes about the "HTML5 coup"[0] suggests the author doesn't consider functionality added by javascript to be valid for web sites, which they define as purely documents, only web applications. This seems to be a common viewpoint on HN, from what I've observed. [0]https://www.devever.net/~hl/xhtml2

Author here. This is finally being given as a talk by me tomorrow at 37C3. I've wanted to give this as a talk for many years at CCC, but CCC's long hiatus got in the way. This will be my first time at CCC. If anyone attending 37C3 wants to talk more about this, or anything else, or about open source firmware/owner control in general, don't hesitate to get in touch with me in person or online. I don't have access to my usual email when traveling for security reasons, so use my travel email: https://www.devever.net/~hl/contact I'll also set up a DECT phone at the event (4526/HUGO). Comments and questions welcome!

So why now? Almost 2 years after the invasion. My guess is that Hetzner got tired helping intelligence services bug their customers: https://www.devever.net/~hl/xmpp-incident

Uh. Hetzner and Linode just got caught doing it. https://notes.valdikss.org.ru/jabber.ru-mitm/ https://www.devever.net/~hl/xmpp-incident

This article does a good job summing things up: https://www.devever.net/~hl/nosecuresmartphone > Modern smartphones have a CPU chip, and a baseband chip which handles radio network communications (GSM/UMTS/LTE/etc.) This chip is connected to the CPU via DMA. Thus, unless an IOMMU is used, the baseband has full access to main memory, and can compromise it arbitrarily. > It can be safely assumed that this baseband is highly insecure. It is closed source and probably not audited at all. The problem is less that there are identified issues, and more that the variety of hardware and vulnerability of the implementation is suspicious.

Nice comprehensive and prompt response! https://www.devever.net/~hl/xmpp-incident advises "Add support for enforcing the presence of CT proofs (known as Signed Certificate Timestamps (SCTs)) in TLS certificates, and enable this support by default.". Does Snikket do this?