ericseppanen

This is so true.

The idea that a program can approach some optimal bug-free state, never to be modified or refactored again, doesn't resemble any project I've ever encountered.

"we model a scenario where the original code is memory-safe; the ported code is memory-safe; and we consider memory safety and undefined behavior that may arise across the FFI layer between the two pieces of code."

I may be stating the obvious, but that's a bit of a strawman. Yes, writing good FFI code is hard; yes it could result in security/soundness issues; yes, we could use better tools in this space.

But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards, even accounting for the potential problems at the FFI boundary.

If I could remove tens of thousands of lines of hard-to-analyze C code, and replace it with tens of thousands of lines of safe Rust, paired with a few hundred lines of hard-to-analyze FFI adapters, that sounds like a pretty good tradeoff to me. I now know exactly where to focus my attention, and I can have confidence that the situation will only improve with time: better tooling may allow me to improve the dangerous FFI layer, and in the meantime I can recklessly improve the safe Rust module without fear of introducing new memory unsafety bugs, unsound behavior, or data races.

This article is plagiarized from the Rust Book: https://doc.rust-lang.org/stable/book/ch15-01-box.html

I have no firsthand information, but reading https://github.com/solokeys/solo

"Solo Hacker can be converted to a secure version, but normal Solo cannot be converted to a Hacker version."

I don't think this is true in the general case. Most Solokeys come in a "locked" form-- they will only accept firmware updates that are signed by the manufacturer. You can buy a "hacker" variant that is unlocked (meant for those that want to tinker with the firmware), but if you were to use one of those you're giving up security against someone loading malicious firmware onto your device.

This is probably the right tradeoff for most users. Solokeys has done a great job of providing continuous support for all of their products, and their software stack has been open source since the beginning. That (combined with the low price) makes them my first choice for a hardware security token.

I can confirm that on Sonic (resold AT&T) VDSL I am seeing this exact corruption.

Nice find! I had been wondering why I had been seeing odd TLS failure messages recently.

For those that enjoy stories about the early days of electric guitar, I recommend picking up the book "The Birth of Loud: Leo Fender, Les Paul, and the Guitar-Pioneering Rivalry That Shaped Rock 'n' Roll" by Ian S. Port. It's a great story about the first electric guitars and their creators.

A Solo key is $20.

https://solokeys.com/

https://quoteinvestigator.com/2017/03/23/same/

Not Einstein. It's a quote from a 1981 Narcotics Anonymous pamphlet.

Print it on a shirt, and you have the thing William Gibson dreamed up in "Zero History":

"What’s that?" she asked.

"The ugliest T-shirt in the world," he said… "So ugly that digital cameras forget they’ve seen it."

Useful reading:

https://blog.netspi.com/stealing-unencrypted-ssh-agent-keys-...

https://blog.ropnop.com/extracting-ssh-private-keys-from-win...

It's interesting that their ssh-agent runs as a service under an Administrator account. I'd guess this is an attempt to better protect the private key against theft during a local compromise (i.e. unlocked computer left running on your desk).

I haven't seen this done on Linux. Has this trick been implemented on other systems?

regarding "development job... putting me outside the income level":

I faced the same situation; after being rejected, all I had to do was file some extra paperwork ("special circumstances") saying that I'd left my job and no longer had any income.

The time investment to prove or disprove this statement is more than I'm willing to give. I'd prefer to spend my time working with projects whose maintainers aren't hostile to my privacy.

"Each Bitwarden installation requires a unique installation id and installation key."

Sorry, it doesn't count as open source if everyone needs your permission to run it.

Is it legitimate to have a CEO add their name to a patent? My impression is that the "inventor(s)" have to be the people who actually came up with the idea.

Wasn't 212b02125f3 ("x86, fpu: enable eagerfpu by default for xsaveopt") sufficient protection for everyone on a modern CPU?

It's common to be able to run a remote debugger via JTAG, allowing the system to run normally, set breakpoints, examine memory, etc.

Even though it's run over the same wires, it's a separate protocol from the hardware JTAG probe you describe.

Look at Stanford Shopping Center in the satellite view sometime: a bunch of rectangles surrounded by an ocean of surface parking.

It's much more like a conventional mall than a downtown: It's effectively walled off from the rest of the neighbordood. You're expected to go there by driving your car, and it's isolated by its massive parking lots so nobody would consider walking in or out a pleasant experience.

This is a loophole that exists, yes.

10b5-1 plans set up by the company will sometimes have a rule that no changes are allowed for 30 days, which solves the problem. Not sure how widespread this practice is.

Bresenham's algorithm is very useful when building software that uses stepper motors to follow a particular path (e.g. robotics, plotters, 3d printers, CNC machine). It's especially nice if you're trying to use a wimpy CPU like an Arduino.

Note that this (and not raster display) was actually the problem Bresenham was describing in the 1965 paper.

Amusingly, the stock firmware for the Makeblock XY Plotter kit did not use Bresenham's algorithm-- and has horrible artifacts due to crazy rounding errors. Reimplementing Bresenham on a plotter does feel a bit like a trip to the past.

I agree the earlier paper shares the same misconceptions.

I don't agree that the authors of the present paper are exempt from criticism for this reason.

That's not how SSDs work. You would never be exposed to uninitialized flash pages; they are unlinked from the logical address space until after the block gets erased and programmed with fresh data. Wear leveling doesn't change that process at all.

Drives that lack cryptographic scrambling are not rare. Search a few vendors' sites and you'll find some that don't support "self-encrypting" capabilities.

Are you claiming that a random-bit-flipping attack such as targeted read disturb can cause corrupted data to be returned even through data scrambling, a first-level LDPC check and a final CRC check on the output?

From your paper: "We assume that the victim system runs a filesystem on top of MLC NAND flash-based SSD."

It seems very naive to be surprised that people would assume this is an attack on SSDs.

I don't think we can assume that all impractical attacks will eventually become feasable.

There are some things that are not just hard, but computationally infeasable. Triggering random bit errors and expecting to pass both the LDPC error correction as well as the extra checksum probably falls in this category.

I'm afraid I don't follow your suggestion that triggering SSD GC could somehow result in some other attack. This is simply the firmware automatically repairing the damage you were attempting to inflict. I don't see an additional attack vector here.

Since flash is already an unreliable media, hardware & firmware already works very hard to conceal and silently repair any errors before they accumulate to a data corruption scenario. This is very different from a rowhammer-type attack because there is an active CPU that already works to prevent this type of damage when it occurs naturally (or due to a naive workload that reads hot locations often).

Good modern SSDs do this. Cheap SSDs use only a non-cryptographic scrambler.

The full paper is here: https://www.usenix.org/system/files/conference/woot17/woot17...

I am unconvinced. They have not demonstrated an attack on any real-world SSD; instead they have attacked their own FPGA-based design.

The attack assumes that you can control or predict the physical location of data on an SSD, which is unlikely on a system that is doing other I/O.

But worst of all, the "attack" assumes that if you can target the right physical block/pages in flash, you can somehow hit that location with sufficient read-disturb that the result will decode successfully, AND pass ECC checks, meaning the resulting bad data will be returned to the host system.

I am highly skeptical that this could ever work on a real SSD. The combination of BCH/LDPC error-correction codes combined with a final checksum should make "random bit flipping" impossible to leverage.

Oh, and there's one more thing: SSD firmware keeps counters, to ensure that read disturb can't corrupt data. Any read pattern that hammers a particular location will trigger garbage collection or data rewrite to a fresh location.

Leaded avgas is only used in piston-engine propeller planes. Jet fuel doesn't contain lead additives.

So still not great, but a bit of googling shows that leaded avgas is less than 2% of total civilian aviation fuel in the U.S.: https://www.faa.gov/data_research/aviation/aerospace_forecas...

In the first chart, the units for the Y axis appear to be "giga-nanoseconds".

That's... interesting.