strstr

You are probably saying this as a troll, but I’ll bite. I mean, sure Rust would have helped.

Technically, the borrow checker and bounds checks wouldn’t have done it here (I’m aware I’m being obtuse by not just linking the bug).

Having cleaner types and abstractions would almost certainly have solved the problem though. Normal C++ would have worked as well as Rust.

This isn't wrong per se, but rather, it lacks concrete recommendations for what should be done differently.

I would love to see Linux thoroughly and meaningfully tested. For some parts it's just... hard. (If anyone wants to get their start writing kernel code, have a crack at writing some self-tests for a component that looks complicated. The relevant maintainer will probably be excited to see literally anyone writing tests.)

For this particular bug, the cheapest spot to catch the issue would have been code review. In a normal code base, the next cheapest would have been unit testing, though, in this situation, that may not have caught it given that the underlying bug required someone to break the contract of a function (one part of Linux broke the contract of another. Why did it not BUG_ON for that...).

Eliminating the class of issue required fairly invasive forms of introspection on VMs running a custom module. Sure, we did that... eventually.

Finding it originally required stumbling on a distro of Linux that accidentally manifested the corruption visibly (about once per 50ish 30 minute integration test runs, which is pretty frequently in the scheme of corruption bugs).

Being an upstream maintainer is incredibly under-appreciated. It’s an unfathomably hard, and somewhat thankless, job (at least if you do it well). A friend of mine was in a cab with Ted Ts’o at a conference and he was reviewing patches on his phone to keep up with the workload (or maybe he was bored who knows).

Despite incredible effort from maintainers, getting necessary changes into Linux can take forever. In the subsystem I depend on (and occasionally contribute to directly) it’s kinda assumed it will take at least a year (probably two) for any substantial project to get merged. This continuously disappoints PMs and Leadership. A lot of people, understandably, chafe against this lack of agility.

OTOH, I’ve been on the other side of kernel bugs. Most recently, a memory arithmetic bug was causing corruption, and took my team at least an engineer year to track down. This makes me quite sympathetic to maintainers demands for quality.

I’ve also been on the other side of the calibration discussions where Open Source work goes under appreciated. The irony never stops (“They won’t merge our patches!” “Are you having your engineers review theirs?”). That and the raw pipeline issues for maintainers (it takes a lot of experience to be a maintainer, which implies spending a lot of a bright engineer’s time on reviewing and contributing upstream to things unrelated to immediate priorities).

People only pull out slower tools for valuable, forgery worthy cards.

If someone is buying 1000 $1000 dollar cards, it’s still worth it lol.

Even cheap forgeries cost money to produce, so I wouldn’t expect a lot of low value cards to be forged. If you sort out the valuable cards and do random sampling, you can probably catch the most problematic cases.

If you are willing to pull out a loupe you don’t really need ML. You can just look at the rosette patterns.

For Mtg cards, the green dot test is very easy to learn, and I’m not familiar with any fakes that pass it.

(Edit: arguably you have to worry about rebacking with the green dot test, but rebacking is typically pretty fishy looking.)

When it comes to playing the game between friends outside official tournaments, you are basically correct (though some use cost as a power level limiter).

When it comes to trading, you don’t want to accidentally pay a premium for something you won’t be able to resell. Lots of players view trading as, more or less, leasing cards. Valuable cards typically have fairly stable prices (though there are notable exceptions). Buy for a dollar sell for somewhere between 0.75 and 1.25.

Seems clickbaity: the selected dates are pretty weird. If you just maintain 1x long, you end up down ~5% overall. Obviously, there's hefty volatility in the days they selected, but I'm surprised that the vol averages out down given that the last decade was quite positive on average.

I’m not sure anyone involved in this space seriously believed in the physical attack resistance TDX/SNP. At least not yet. The attack surface is just so vast.

This reads like yet another overhyped named vulnerability.

These tools are a fence. The fence started out pretty short with AMD’s original SEV and has been getting taller since.

Taking the software operators out of the trust boundary is still (comparatively) viable despite this type of attack. And, if the cloud provider sends you attestations proving your workload is in their Real Deal data center with actual guards, cameras, and compliance operations, I’d expect this specific attack to be irrelevant.

——————

Only had a quick skim at the paper. Looks like they are mucking with the DDR sticks to make aliasing possible, which lets them circumvent integrity protection.

I thought circumventing integrity was already possible-ish with rowhammer and SNP? SNP doesn’t store integrity bits anywhere so it can’t even pretend to catch changes in dram.

For CPU bound work loads, pretty low, but not low enough that it's free (~5%).

For devices (especially latency sensitive workloads), it's quite bad. Device accesses have to be bounce-buffered. You can't do anything vaguely zero copy, since the device can't DMA to or from the VM. Future hardware support will mitigate that (mutually attested VM/Device interactions), but no real world devices support it yet.

The polymer chains are quite long after manufacturing for teflon pans. They are largely “safe”. Don’t use metal utensils with them and don’t overheat them. That said, I personally minimize my use of teflon pans (mostly just use them for eggs since I hate cleaning eggs off)

Even if PFAS were as bad as lead (which it is not), teflon pans are probably more analogous to leaded glassware than, say, lead in gasoline or paint. Waterproof outerwear is probably analogous to leaded paint (more likely to leach and plausibly prone to contact mouths accidentally).

I’ve heard the lifespan thing before and never understood it. It’s still 86 degrees wide.

You could also sharpen just one edge of each ski (opposite edges across the pair), then put the skis on random feet. Then see if they can tell which edges are sharp! Most of a typical skier’s weight is supported by the inside edge of the downhill ski while carving.

Youth racers tend to ski with one set of edges on the inside for training, and the other edges inside for racing (under the theory that the inside edges take more of a beating. Who knows if that is accurate). If you ever see youth racers on slalom skis (which are chiral, since they have tips that deflect ski gates), you’ll often notice that the skis are on the “wrong” foot.

Tuners look at me so strangely when I ask for 0°/4° lol. I can’t imagine dealing with coaches.

Thanks for the correction. I had just never heard of 5° degrees as a base bevel. Not sure why you seem defensive. Isn’t 0.5° (or lower) the factory tune for slalom skis? Might only be a thing for U16+.

Unless you do your own tuning (or are willing to light money on fire) it’s hard to A/B test ski waxing/edge tuning. I kinda suspect this alleged olympic tuner didn’t cross compare, or just doesn’t ski in ways where you’d notice (he might just like skid turns through packed powder). Or he just uses backcountry noodles on groomed snow, and can’t tell since he’s using skis that won’t let him.

Going from dull edges (even “well maintained” ones) to freshly sharpened is quite noticeable on icy days. I use 0°/4° and like the responsiveness and grip.

From my long past race days (when I had to maintain several pairs simultaneously), I could tell that the wax design temp mattered deeply, though mostly >25f vs lower temp. High temp waxes are down right sticky in cold snow (and vice versa). But cold waxes are largely fine for middle temps (~10-20f or whatever). The (horrifying) fluoro stuff was also very effective, though probably banned by now if anyone is sane. I wasn’t able to tell the difference beyond the temp though, unless the skis were damaged. Though, I mostly just don’t wax these days since I’m not trying to eek out extra speed.

Base bevel (the angle trimmed off the metal edge from the side that sits on the snow) matters and is largely ignored by skiers/snowboarders, since tuners are cautious, and skiers don’t know to ask. It determines how responsive the skis are (going from 0° to 1° means you need to tilt your leg an extra degree). You can only decrease it (or clean it up) by flattening the entire base and then sharpening, which requires specialized equipment.

Edge bevel matters, but allegedly has diminishing returns. It (allegedly) gives a bit of extra grippyness. I’ve never quite understood why it matters, since it seems like it just narrows the metal very slightly. From my A/B testing, the freshness of the sharpening seems to matter more than the edge angle, but I’ve also never set it below 2°.

Do you mean .5 or 5 for the base bevel? 5 is quite far off the snow.

What does this have to do with the article?

This really kills my desire to trust startups and YC. Hopefully paulg makes some kind of statement or commitment on non-disparagement and the like.

Corporations aren’t the government.

There are a few categories of usage for enclaves (well, more broadly, Trusted Execution Environments):

1) Clouds (you mostly trust the provider, but maybe not fully. And you want to make sure they don’t have anything up their sleeves. Consider the FBI vs Apple encryption dispute)

2) Intra-corporation stuff as a mitigation against hacked users, malicious insiders, and malware (think crypto oracles for terminating SSL, requiring bootchain attestation before giving corporate credentials)

3) The more icky category: Places where you distrust your own customer (DRM, and probably eventually, game anticheat)

The userspace code being more privileged than kernel code has never really been true. Maybe arguably true for SGX, but even then, all you get is the ability to prove you were initialized in the “right” way. All the other TEEs have a kernel mode component (they are typically ways of running attestable VMs).

The framing is a lot narrower, and pretty clear if you’ve ever played overwatch. In that context a lot of people claim they want to get better, but don’t even grab for the lowest hanging fruit.

Sounds like a genuinely frustrating experience.

Bit confused about why nested virt has anything to do with their problems given that they aren’t using virt inside the VMs. Softlocks are a generic indication of a lack of forward progress.

Same confusion with the MMIO instructions comment. If that’s about instruction emulation, not sure why it matters where it happens? It’s both slow and bound for userspace anyway. If it’s supposed to be fast it should basically never be exiting the guest, let alone be emulated.

Sounds like the author is a bit frustrated and (understandably) grasping at whatever straws they can for that most recent incident.

Game trusts the local clock. You can change the datetime. I did this to try older puzzles.

That’s a defeatist attitude. Why ever try to make progress on security if this is how you feel?

It’s like saying Microsoft never should have tried to make Windows more secure than it was in the XP days.

Desktop replacement is a VM. Physical desktops stopped allowing VMs by default as an L1TF mitigation.

Is attending a prestigious college an outcome or an opportunity?

> The DIF is funded mainly through quarterly assessments on insured banks.

https://www.fdic.gov/resources/deposit-insurance/deposit-ins...

Nothing in this video is super groundbreaking if you’ve taken a typical physics class that includes some E&M.

That said, the demonstrations are pretty compelling and well executed. I particularly liked the use of an IR camera to visualize the resistive power loss in the maze. Super cool.

Gives me some strong cat asking to be let out energy ala [0].

[0] https://pbfcomics.com/comics/sir-leopold/