Sirened

There's definitely a funky curve of what you can and cannot comfortably do on an iPad. If you're pinned to IDEs and need lots of local graphical tools to support development, an iPad is unusable. If you already have to run all your work remotely since the tools are too heavy even for a laptop (like me with EDA tools), it turns out that the iPad makes for a great little client. I use mine a lot with iSH. I can do work locally in vim and then submit jobs to the compute cluster, it's the exact same workflow I'd use on a laptop.

Much of transient execution research over the years has been invalidated or was complete bogus to begin with. It was extremely easy to get a paper into a conference for a while (and frankly still is) just by throwing in the right words because most people don't really understand the issue well enough to tell what techniques are real and practical or just totally non-functional.

You have to stop the leak into side channels in the first place, it's simply not practical to try to prevent secrets from escaping out of side channels. This is, unfortunately, the much harder problem with much worse performance implications (and indeed the reason why Spectre v1 is still almost entirely unmitigated).

It's not that simple. The problem is not just branches but often the intersection of memory and branches. For example, a really powerful technique for amplification is this:

ldr x2, [x2]

cbnz x2, skip

/* bunch of slow operations */

ldr x1, [x1]

add x1, x1, CACHE_STRIDE

ldr x1, [x1]

add x1, x1, CACHE_STRIDE

ldr x1, [x1]

add x1, x1, CACHE_STRIDE

ldr x1, [x1]

add x1, x1, CACHE_STRIDE

skip:

Here, if the branch condition is predicted not taken and ldr x2 misses in the cache, the CPU will speculatively execute long enough to launch the four other loads. If x2 is in the cache, the branch condition will resolve before we execute the loads. This gives us a 4x signal amplification using absolutely no external timing, just exploiting the fact that misses lead to longer speculative windows.

After repeating this procedure enough times and amplifying your signal, you can then direct measure how long it takes to load all these amplified lines (no mispredicted branches required!). Simply start the clock, load each line one by one in a for loop, and then stop the clock.

As I mentioned earlier, unless your plan is to treat every hit as a miss to DRAM, you can't hide this information.

The current sentiment for spectre mitigations is that once information has leaked into side channels you can't do anything to stop attackers from extracting it. There are simply too many ways to expose uarch state (and caches are not the only side channels!). Instead, your best and only bet is to prevent important information from leaking in the first place.

This is an idea many have had before but it doesn't quite work. When you do this, you tend to lose all the performance gained from speculative execution. It's essentially data-independent-timing as applied to loads and stores, so you have to treat all hits as if they were misses to DRAM, which is not particularly appealing from a performance standpoint.

This is not to mention the fact that you can use transient execution itself (without any side channels) to amplify a single cache line being present/not present into >100ms of latency difference. Unless your plan is to burn 100ms of compute time to hide such an issue (nobody is going to buy your core in that case), you can't solve this problem like this.

Modeling programs as circuits also makes them significantly easier to formally verify too! These sorts of synthesis tools are really cool, though writing traditional software in them is extremely painful.

It's a joke about people moving to Linux not because it's gotten any better but because Windows has been getting worse

My favorite is when the codebase is so deeply buried in macros and headers that send you on a wild goose chase to find any actual code that it becomes much easier to just dump the binary in ida/binja. The source code can lie but at least the compiled binary directly does what it says

My sad related factoid to this is that suicide overtook car accidents as the leading cause of death of teenagers in Colorado. This is because although suicide is a worsening problem, crash safety and driver education have improved much faster than the suicide rate has been rising, causing them to flip for the first time.

RISC is not about the number of instructions but rather what the instructions do. The famous example of CISC gone to its logical extreme is the VAX's polynomial multiply instruction, which ended up being almost a full program in a single instruction. RISC tends to go the other way, focusing on things that are easy for hardware to do and leaving anything else to software.

What sort of wiki are you envisioning here? There is some decent tooling and docs around generating SoCs [1] but, as the article mentions, the most difficult part is not creating a single RISCV core but rather creating a very high performance interconnect. This is still an open and rich research area, so you're best source of information is likely to just be google scholar.

But, for what it's worth, there do seem to be some practical considerations why your idea of a hugely parallel computer would not meaningfully rival the M1 (or any other modern processor). The issue that everyone has struggled with for decades now is that lots of tasks are simply very difficult to parallelize. Hardware people would love to be able to just give software N times more cores and make it go N times faster, but that's not how it works. The most famous enunciation of this is Amdahl's Law [2]. So, for most programs people use today, 1024 tiny slow cores may very well be significantly worse than the eight fast, wide cores you can get on an M1.

[1] https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/in...

[2] https://en.wikipedia.org/wiki/Amdahl's_law

It is fairly different from a systems programming perspective. The base instructions (I) are essentially everything you'd expect when writing any kind of regular program and it feels very normal and natural for anyone who has ever written assembly, but once you start needing fancier things like exceptions you'll see a lot of new RISCV specific design choices. This is sort of to be expected, x86 has a different exception architecture from ARMv8A. It's just different, not necessarily less capable. Odds are whatever RISCV MCUs come on the market will eventually be supported with the same SDKs you know and love, but they will have a different implementation for all the system specific functions.

For all those learning (or even those who've learned :P), my favorite cheatsheet that I always pull up while writing ARMv8-A assembly is this one [1] from the University of Washington. ARMv8-A has a lot of fairly complex instructions and sometimes it's hard to remember all the odds and ends.

[1] https://courses.cs.washington.edu/courses/cse469/19wi/arm64....

that argument can be used to stop the inclusion of any new large functionality in the kernel.

Sure, it could be, but there are shades of gray. Arguing that adding a full fat SMB server to the kernel is not the same thing as suggesting that file systems should be 100% in user space. You and I both know that the threat posed by introducing a large amount of remotely reachable code is not at all the same as that posed by a new kernel filesystem.

The last few decades of arguing about micro vs monolithic have surely convinced everyone that there is a time and a place for both. Yes, embedding the server in the kernel gives us lower latency by eliding a context switch (a few hundred cycles) but this comes at a pretty high cost that we're going to be paying for years to come.

Call me overly dramatic, but ever since the NSO group stuff went public I've been a lot more risk averse when it comes to introducing remote attack surface because we know that these bugs are being used to kill people. Making kernel compromise harder means possibly saving someone's life. Do I think someone is going to die over a ksmbd bug? Probably not. Would I want to be the one that checked in a huge remotely accessible blob of code? No, so I think carefully about what code I put where to minimize the risk.

The criticism isn't that anyone expects bug free code, rather that introducing new remotely accessible attack surface to the kernel in 2022 when we know it's likely unsafe is silly. Building an SMB server in the kernel because "well, NFS was secure eventually" overlooks the fact that NFS shouldn't be in the kernel either.

Have you actually benchmarked a context switch on modern hardware? A full switch (including register spilling and page table swap) can be had in <150 cycles on even cheap, older Arm A-series cores like the Cortex A72. We're not still living in a world where a context switch forces you to flush the TLB, you literally just have to pay the cost for the trap, spill, page table swap, unspill, and return. This cost is even lower of modern ARM processors which support speculative exceptions where you can perform the entire context switch speculatively.

Most exploited UAFs don't happen in common execution paths. They're often caused by weird races and error conditions that nobody considered to even happen. It's why things like production ASan is a lot less valuable than people would imagine: most reasonably well tested software doesn't exhibit memory corruption when used normally. So, sure, your suggested technique could be a cool way to try and catch bugs that appear under normal execution but it won't put that much of a dent in the total number of bugs.

OpenBSD is somewhat controversial in that a variety of its security claims don't make sense or work out in practice. As a whole, however, they do meaningful work so it's still worth donating.

Most cryptographic algorithms worth their salt have a pseudo code implementation on Wikipedia too. Just save the article along with the encrypted payload, bam future proofed :)

There's a video on YouTube where a hobby scientist takes a cup of water and doses it with an incredibly potent poison

Cody'sLab Drinking Cyanide <https://www.youtube.com/watch?v=i6hOVhQQ9h>. Apparently it was removed because YouTube Trust and Safety didn't believe in dilutions lol

Do you know what they did on holidays? Did they just never close for any reason whatsoever?

It is still mortifying to have a photo of you sitting on the toilet with your shorts down even if your face is blurred out. Yes, the damage has already done and this made the article even more compelling, but I don't think it was necessary or appropriate.

Do you truly believe someone would see the headline "How did Roomba-recorded photos end up on Facebook?" and not ask themselves "wait...is MY Roomba recording photos that might end up on Facebook???". This is clearly clickbait-y, the question is intentionally vague to encourage people to read more. A less clickbaity and more clear question would be "how did photos from research Roombas end up on Facebook?" but that's spoiling the story's punchline, now isn't it.

It's not as if we've just had a decade of such unthinkable business strategies. Google is still, for the vast majority of people, free (as in $0 per month) service which gives them free email, document editing, and file storage.

Especially seeing as you can outright have a full, tiny VPS 24/7 for $2.50/mo or $30/yr from Vultr. I suppose there's a value add in terms of not necessarily needing to setup your own install, but if that's something you're comfortable with I don't quite see the point.

Take your choice of other random SBCs off Aliexpress for $30-40. They all run Linux well enough for headless, short cronjobs.

I don't see how it's satirical. If you need a job to run, you need to handle the case of transient node failures. K8S helps alleviate this issue by allowing the job to be launched on any of a choice of nodes. Sure, cron is fine if you're just looking to rotate logs on the local machine, but if you want to reset your nuclear watchdog timer, you may want something more reliable :)

remind me of a couple of different crumby """anti-cross-site-scripting""" filters you used to be able to find. They claimed that they'd remove dangerous input so that it would never hit your backend. They did this by deleting any harmful looking input, which had the fun consequence of turning this invalid input:

     <script<script></script>>alert("hax")</script<script></script>>

     <script>alert("hax")</script>

I think the titular question is more rhetorical than actually attempting to give you a count. Lots of people do really think that there is one "computer" in their laptop when in fact the question of what a computer even is poses a way more difficult question. I loved the note on the MMU because it, aside from being a hilarious conference talk, poses the question of where we can even draw the line because clearly if the MMU can implement full programs than surely it's wrong to draw the line at the borders of a core on a SoC. Modern hardware is really funky and cool, and this article provides a good introduction to the chaos.

One of the key points he makes is that this is now an entrenched problem. SoC designers looked to Linux and asked "hey, can you drive the power management stuff?" and got no real help and so instead just built it out of the purview of the AP clusters altogether. Hardware is essentially implementing an abstract interface that is convenient for Linux to use and hiding everything else that's too difficult to add.

The solution, and one that he specifically calls out, is that operating systems people need to work with hardware people to build better hardware and software together to build new computers. We got into this situation because everyone was just solving problems with the tools they readily had available to them. This is obviously easier said than done, but it does make now a very interesting time to work at one of those handful of large companies which produces their own custom SoCs and operating systems (I believe it's Apple, Google, and Microsoft) since you really have to take both operating systems and hardware forward simultaneously to solve the underlying issue.

A favorite related to talk is Roscoe's keynote titled "It's Time for Operating Systems to Rediscover Hardware" [1] in which he discusses some of the outcomes/consequences of kernels (like Linux) largely sticking their heads in the sand on the issue of these massively heterogeneous SoCs.

[1] https://www.youtube.com/watch?v=36myc8wQhLo