Sirened · HackerTrans

Sirened

no profile record

comments

3 jaar geledendiscuss

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.

3 jaar geledendiscuss

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).

3 jaar geledendiscuss

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.

3 jaar geledendiscuss

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.

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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

4 jaar geledendiscuss

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

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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....

4 jaar geledendiscuss

> 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.

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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.

4 jaar geledendiscuss

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 :)

4 jaar geledendiscuss

> 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

4 jaar geledendiscuss

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