twtw

They could drop graphics support on Linux with no significant losses to their hpc/ml market.

The real-world progression of software run over time on processors doesn't always match the assumption in amdahl's law. Frequently people want to solve harder/bigger problems in the same time, not just the same problem in less time. See, for example, how slack has taken over doing what IRC could do, just with much higher resource requirements.

For that, see https://en.m.wikipedia.org/wiki/Gustafson%27s_law.

The ebpf is not the exploit. The ebpf was used in the proof of concept to generate a gadget in the victim process (in this case the kernel). Similar code patterns already existed in the kernel, the authors just used ebpf to make their own so they didn't have to hunt one down.

If you don't believe me, perhaps the document making its way into the kernel source (and the review comments) will make things clear: https://lkml.org/lkml/2018/12/21/577

If you are still not convinced, take a look at these patches merged into Linux to mitigate a vulnerability you are arguing doesn't exist: https://lkml.org/lkml/2018/1/5/769

Spectre V1 can be exploited by simply passing parameters to code that runs in another process. It does not require that the attacker can run code in the victim process.

cuBLAS does GEMM.

> But it only affect,as a first approximation, processes that try to execute code with different trust domains in the same address space

This is wrong, even as an approximation. This comment, as well as your other comments on this thread, indicate that you misunderstand spectre v1. Some of the initial proofs of concept of spectre v1 demonstrated the attack with both victim and attacker in the same process, but that is not necessary, and the original materials disclosing spectre make that clear.

The paper [1] describes spectre v1 as a technique in which "conditional branch misprediction can be exploited by an attacker to read arbitrary memory from another context, e.g., another process" [emphasis mine]. The others go on to describe a proof of concept in which a vulnerable code sequence is inserted in the kernel via ebpf, but the attacker is in user space: "we use the eBPF code only for the specu- latively executed code. We use native code in user space to acquire the covert channel information."

It's not clear whether spectre v1 style attacks within a single process can be prevented by hardware, but spectre v1 attacks in which an attacker process manipulates a vulnerable gadget in a victim process certainly can be.

Running untrusted code in the same process as trusted code has always been dodgy, and now will probably need speculation barriers at bounds checks. But the most worrying part of spectre v1 is how it can be used to bypass process (and user/kernel) isolation, and that can and should be fixed.

[1]: https://spectreattack.com/spectre.pdf

What you are describing here is high cost, because you have to take care of coherence when the line is committed to the cache, which in your scenario would not be speculative. That would require notifying the other cores and potentially refetching if another core has written to the line between your prefetch and commit.

A more practical solution is probably to have protection boundaries within the cache, like http://people.csail.mit.edu/vlk/dawg-micro18.pdf.

Sure, I get it. Perhaps I phrased my response poorly.

This comment:

> What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code

is an argument that doubting if statements should be acceptable, and that the assumption that only B has architecturally visible side effects when A is true is not sound. I disagree strongly with that.

You should be able to rely on software checks for some things. Going forward, the solution is not to rewrite software to not depend on software mechanisms (e.g. bounds checks) for protection (unclear what would be used instead...) but to fix the hardware so these software mechanisms work.

What needs to "die" is not "belief that you can rely on just software," but hardware that violates fundamental guarantees.

It sounds like we agree on this, I just wanted to make my point clear since I see now that my original comment was not clear.

FWIW, this is essentially the argument Torvalds made when Intel tried to add feature flags for non-broken speculation.

Given the phrase "Intel funded" 'childintime is probably confused and thinks AMD Zen is not vulnerable.

> What needs to die is the belief that you can rely on just software (i.e. memory safety) for isolation between trusted and untrusted code[1].

I don't understand how you came to this conclusion. How does spectre indicate that you can't rely on software for isolation?

> meltdown bypasses hardware protection, but that's Intel specific

It's not Intel specific. Certain ARM and POWER architectures are also vulnerable.

Spectre bypasses hardware protections too, just in a more subtle way.

That's very unlikely. 16 GB of HBM2 alone probably costs AMD around $300, and HBM2 prices are unlikely to fall soon (they've actually been trending up, if what I've read is to be believed).

I'm sorta surprised that the specs are so similar to the MI50. Seems like this might cannibalize the sales of MI50 for applications that don't use fp64 (i.e. all ML/DL uses).

> and then tried to hide it to the fullest extent possible

I haven't seen any evidence of this. It's definitely not supported by this NYTimes article.

Do you have a source?

> have dozens of seconds to respond

12 minutes, in this case.

It's not really possible to not know that you are dealing with a runaway stabilizer. MCAS (and every other automatic system to adjust trim) causes large physical wheels at the side of the pilot's knee to spin.

For reference, here is the runaway stabilizer memory item (the "checklist") for 737:

1. Control column ............................. Hold firmly

2. Autopilot (if engaged) ..................... Disengage

3. IF the runaway stops:

------------------------ [done]

4. IF the runaway continues:

STAB TRIM CUTOUT switches (both) ...... CUTOUT

IF the runaway continues:

Stabilizer trim wheel ............ Grasp and hold

EDIT:

It's #4 that's of interest here. People saying that the interface changed are saying that it's fine if pilots stop after #1, even when dealing with runaway stabilizer for 12 minutes.

And yet the pilots of the previous flight flipped the cutout switches.

EDIT: ... Presumably because it's literally the second thing on the list of things to do in the case of a runaway stabilizer.

The point is that their response may have worked for this particular fault, but would not have worked in general. There is a reason that there are more procedures than "pull back on the stick" - pilots do not know what the fault is.

> they developed an unconscious/intuitive mental model of the plane

If the plane has a fault, it's frequently not going to behave like their unconscious model says it should. In the happy case, rely on your intuition. In the unhappy case, when things are working as they should, follow the emergency procedure.

Sorr, but this is a little like saying "follow standard procedure to put the landing gear down. If that procedure doesn't work, repeat your intuitive action over and over until hopefully the landing gear goes down." No - follow the emergency procedure in place for landing gear fails to descend.

> not communicated to them for cost-cutting reasons

Take it up with the FAA and the airlines?

> Pilot trained this situation and plane did X and now does Y - you don't really see the problem? - now pilot has extra burden to quickly determine if something else is wrong as plane behaves differently than pilot was trained to.

The pilots did not train for a specific root cause of a fault. They trained for a symptom (uncommanded nose down), and the procedure for that situation was unchanged.

> extra burden to quickly determine if something else is wrong

This isn't an extra burden. Pilots aren't doing root cause analysis for failures while they are responding to them. They are trained to try actions in a specific order until something works. It's not like the checklist used to have one action on it and now it has two - the solution in this case was a standard action on the standard checklist.

Pilots do not look around, say "ah, electrical short in elevator actuator" or "ah, bad angle of attack sensor" and then take a single action.

I do not think this is a good analogy.

Firstly, there is no single equivalent to "slamming on the brakes" for uncommanded nose-down. This could be caused by a variety of faults, and pilots are trained to respond in a fashion that will be effective for even those in which the first thing to try doesn't work. There is a standard procedure in place to use in this type of situation - arguing that the pilots should only be expected to do one thing with increasing desperation is essentially arguing that they will not be able to respond to a whole host of emergencies causing uncommanded nose-down.

Second,

> Information from the flight data recorder shows that the plane’s nose was pitched down more than two dozen times during the brief flight, resisting efforts by the pilots to keep it flying level ... The standard checklist for dealing with that sort of emergency on the previous version of the 737 focuses on flipping the stabilizer trim cutout switches and using the manual wheels to adjust the stabilizers. [emph mine]

your argument essentially hinges on the assumption that pulling hard back on the stick is a sufficient solution for all the problems that may happen with a plane with the exception of a fault with MCAS (the new system). I don't think that is accurate. Even prior to the the 737 max! It sounds there were a lot of things that would require further action that pulling back on the stick.

> and additional regulation is going to be needed to make sure this doesn't happen in the future.

Given that the FAA made the decision that it was fine to not retrain the pilots, sounds like there's going to have to be someone to regulate the regulator.

In addition to the resources other have mentioned, I've found this http://pages.cs.wisc.edu/~remzi/OSTEP/ valuable.

I can't tell if that's saying that it didn't completely fail, or that it completely succeeded.

Like the author?

https://news.ycombinator.com/item?id=19070587

In my experience, writing "scary" software like a compiler, an OS, a kernel driver, etc is more about bravery/daring than raw skill or intellect. There are quite a few people that know C and C++ in high school, so it seems reasonable that at least some of them would have someone (IRL or online) nudge them in the direction of an OS and tell them "it's not as hard as you think, if you dare to try."

I don't say this to diminish the accomplishment here, but to encourage others to try it too.

I thought it was fairly clear 'q3k was referring to the 64 bit ISA introduced in amd64, not all the legacy stuff either kept around in some form for compatibility (x87, encodings) or stuff that isn't part of long mode (BCD, segmentation, real mode).

> Took me a while, but I got 97% efficiency with single core DGEMM.

In my experience, it's pretty widely accepted that VLIW (and EPIC) can achieve high performance and efficiency on highly regular tasks such as GEMM and FFT. That's why VLIW has been and continues to be popular for DSPs. The struggle for VLIW is general purpose code that doesn't necessarily have that same kind of regularity.

I don't think "Silicon Valley" is the descriptor you are looking for here.

Intel and HP (where the people "supporting and incrementally enhancing" itanium hw & sw work) are very much Silicon Valley companies.

> I pay $3000 for a one bedroom

> If I could move, I would.

If you don't mind, why can't you move? Caring for family members?

> Russian officials have raced to portray the United States as the nation at fault.

> They charge that American missile defense interceptors in Eastern Europe could be easily refashioned into offensive weapons, and that the rise of armed drones, which had not been invented when the treaty was signed, now threaten to provide Washington with similar intermediate-range ability without violating the precise wording of the treaty.

From https://www.nytimes.com/2019/02/01/us/politics/trump-inf-nuc...

That's in the article.