hansendc

"On x86-64, there are two CPU settings which control the kernel’s ability to access memory."

There are a couple more than two, even in 2021.

Memory Protection Keys come to mind, as do the NPT/EPT tables when virtualization is in play. SEV and SGX also have their own ways of preventing the kernel from writing to memory. The CPU also has range registers that protect certain special physical address ranges, like the TDX module's range. You can't write there either.

That's all that comes to mind at the moment. It's definitely a fun question!

Here's an implementation that one of the OpenStreetmap applications uses:

https://josm.openstreetmap.de/browser/josm/trunk/src/org/ope...

It used to use a linear list of points, but it was VERY slow to draw, so I hacked this in to the code base a few years ago.

The AVX disable is only when you use "gather_data_sampling=force". The default is to leave AVX alone and proclaim the system to be vulnerable.

From https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... :

Specifying "gather_data_sampling=force" will use the microcode mitigation when available or disable AVX on affected systems where the microcode hasn't been updated to include the mitigation.

Disclaimer: I work on Linux at Intel. I probably wrote or tweaked the documentation and changelogs that are confusing folks.

Uh... Did I miss the patches that add a pre-zeroed page pool to Linux? Wouldn't be the first time I missed something like that getting added, but 6.3-rc5 definitely zeroes _some_ pages at allocation time, and I don't see any indiciation of it consulting a prezeroed page pool: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible.

I'll also add a [2]:

[2] There's no way to do it in the page tables. But, if you have Protection Keys for Userspace (PKU), you can get it ... kinda. You can have a PROT_READ|PROT_EXEC mapping, assign it a pkey, then set PKEY_DISABLE_ACCESS in the PKRU register for that key. In fact, if you have a PKU CPU and you do an unadorned mmap(PROT_EXEC), the kernel will allocate you a pkey and do this under the covers FOR you. Anyone who can execute WRPKRU can easily undo this protection, but it's better than nothing.

There honestly isn't that much "tech" to speak of here. We were literally talking about "immutable" mappings last week in Linux land: https://lore.kernel.org/all/b4f0dca5-1d15-67f7-4600-9a0a91e9...

That said, this would be great to see in OpenBSD (or any other OS).

There's at least one extremely well documented example of a killer whale that played extensively with boats: https://en.wikipedia.org/wiki/Luna_(orca)

Granted, this was a lonely little fellow. But, he knew perfectly well what he was doing and repeatedly approached boats, despite the noise. He died after colliding with a tugboat prop.

They actually leave lots of evidence. A transient eating a seal is messy business and there are lots of seal bits and chunks left over. Eva Saulitis describes the aftermath in several cases in her book (https://www.penguinrandomhouse.com/books/219235/into-great-s...). IIRC, fishing the evidence out of the water is one of the primary ways they study killer whale diets.

From: https://arstechnica.com/gadgets/2020/10/in-a-first-researche...

"In a statement, Intel officials wrote: ... we do not rely on obfuscation of information behind red unlock as a security measure."

(BTW, I work on Linux at Intel, I'm not posting this in any official capacity)

Actually, its primary design goal is to make address sanitizers faster. Right now, all the code that touches a sanitizer-tagged address must be recompiled to understand how to place and remove the tag. These address-bit-ignore approaches can (ideally) allow you to just modify the memory allocator to hand out tagged addresses. Those addresses can then be passed around to code that doesn't even know it's handling a tagged address. It doesn't need to be modified. You don't need to recompile the world. Even when the sanitizer is on, you also don't need to be constantly stripping tags out of pointers before dereferencing them.

By an "AMD push" do you mean Intel should post a superior implementation a year before AMD does? ;)

https://lore.kernel.org/lkml/20210205151631.43511-1-kirill.s...

BTW, MPX was clearly not the right thing. Nobody really wanted it. The world would be a better place if these address-bit-ignoring things (ARM TBI, AMD UAI, Intel LAM) had been implemented years ago instead all the effort spent on MPX.

Believe me, I know. I put a lot of blood, sweat and tears into MPX for Linux.

Disclaimer: If you didn't figure it out by now, I work on Linux at Intel.

It's not just drivers. It's really about ensuring that the folks that maintain the kernel have a way to test the code they maintain. The reasons that we (the kernel maintainers) have for this requirement are varied. But, for me, it's really nice to have at least one open source implementation that can test the kernel code. Without that, the kernel code can bit rot too easily.

Even better is if an open source implementation is in the kernel tree, like in tools/testing/selftests. That makes it even less likely that the kernel code gets broken.

Disclaimer: I work on Linux at Intel, although not on drivers like this Habana one.

Yes, it's been a pretty close relationship for a long, long time.

What does Intel get out of this? I'm really hoping that Intel gets help improving the kernel from a talented bunch of kernel developers who have experience working closely with paying customers. Intel has tons of kernel developers, but few of us are very directly customer-facing.

I also hope the Linutronix folks can spend less time on "castle maintenance" and more time on kernel maintenance. https://www.phoronix.com/scan.php?page=news_item&px=PREEMPT_...

(BTW, I work on Intel at Linux).

I hope so too! But, I was trying to think of if I've ever seen the Linutronix folks working on the Intel graphics code. I don't think I have:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

For very selfish reasons, I'm hoping that this acquisition will give the Linutronix folks even more of an opportunity to contribute to the core kernel and especially arch/x86.

Disclaimer: I work on Linux at Intel.

"It may do the wrong thing at the worst time" -- each FSD Beta announcement email.

So, basically, I need to somehow predict that FSD will do the wrong thing and react myself, _before_ the worst time, because the worst time is when it's already too late.

Don't confuse prediction and anticipation. Prediction requires that you know what's going to happen. Anticipation is getting ready for something that might happen. Anticipation is a normal part of defensive driving every day, not prediction.

Let's go back to defensive driving 101: defensive driving allows mistakes to be made. It allows bad things to occur and still recover from them safely. Bad things happen because of mistakes are made by humans in the car, humans outside of the car and also by the computer in the car. The change here is that you the computer is being given much more latitude to make mistakes. It does NOT grant the computer the ability to remove defensive margins from driving.

If you drive (regardless of FSD) with no defensive driving margins, you immediately enter "too late" territory whenever a mistake is made.

I personally have a tendency to match the speed of the cars around me. IMNHO, most cars speed through school zones. I use cruise control as a tool to prevent me from accidentally matching the speed of the cars around me and breaking the school zone speed limit.

Where does Tesla provide a list of such limitations for it's customers,

One specific place is first sentence of the FSD Beta welcome email:

"Full Self-Driving is in limited early access Beta and must be used with additional caution. It may do the wrong thing at the worst time, so you must always keep your hands on the wheel and pay extra attention to the road. Do not become complacent."

That's been my experience with it. Right now, the beta doesn't reduce my workload, it increases it. When I want to "just drive", I turn the beta off.

That said, Tesla can and should do more. They need to better frame the capabilities of the system, staring with the silly marketing names.

I think the main point is to know the limitations of the technology and to deploy it appropriately. For instance, I don't rely on old-school cruise control to stop for small children, either, even though I engage it in school zones.

This isn't limited to "Tesla-tech". The same rules apply to ALL technology.

I sure hope it stays around in servers for a long time. Some of us at Intel are actively working on expanding the existing kernel support: https://lore.kernel.org/lkml/cover.1638381245.git.reinette.c...

Intel's equivalent of SEV-ES and SEV-SNP is called TDX: https://www.intel.com/content/www/us/en/developer/articles/t... . While you could probably put both under the "confidential computing" umbrella, they do really different things well. As far as I know, SGX and TDX will both be around on the same hardware.

Also, just to be explicit about it: I work on Linux at Intel, including on SGX.

The Y's overall visibility is objectively better than my old sedan. It's also really hard to have that really aerodynamic shape and good rear visibility. The Y's visibility reminds me of a Prius in a lot of ways.

I've never thought once that the rear visibility was a problem on the freeway.

They turned my radar off when I got the FSD beta. It's hard to tell what is from losing radar versus getting FSD itself, but I think I liked the radar better. It seemed to perform better and have less phantom braking.

The rear visibility felt weird when I test drove it for sure, coming from a normal sedan. But, over a year in to ownership, it never feels tiny when driving it. All the cameras and sensors make it a MILLION times better to maneuver in small spaces than my old car. It was more a matter of getting used to something different (and I'd argue objectively better) rather than an overall downside.

As for the headrest, I've never thought about it once myself.

"the meltdown patch in the kernel thats disabled by default"

I'm not sure to what you are referring to here.

I was one of the people who worked on the Linux PTI implementation that mitigated Meltdown. My memory is not perfect, but I honestly don't know what you're referring to.

While there are ways to disable mitigation against many of the side-channel issues, this is not one of them. I believe this one is mitigated by the "sbb;and" sequence here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

There is no way to enable or disable this particular mitigation. That's probably because it's an extremely cheap mitigation.

Disclaimer: I work on Linux at Intel.

While I'm sure there are folks that would appreciate the mitigation provided by that package, I'm not sure it provides any mitigation to this _specific_ exploit.

The in-kernel Spectre-v1 mitigations, like:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

are cheap and ubiquitous. You don't have to turn them on, and they're so cheap you can't even turn them off if you wanted.

Disclaimer: I work on Linux at Intel.

- To what extend is this fixed by the mitigations which the kernel provides [0] for the Intel bugs? What do I have to add to my kernel command line?

The key part of this post is "In my lab, on a vulnerable Fedora" which means that the author is using an old, known-vulnerable version of Fedora on which to do their testing.

You don't have to do anything other than be running a reasonably modern version of the kernel that gets updates from -stable or from your distro.

BTW, this is a Spectre-v1-style exploit. These are EXTREMELY widespread across lots of processors with conditional branch speculation. It's (relatively) unrelated to the family of things like MDS or Spectre-v2 where microcode updates were issued.

Disclaimer: I work on Linux at Intel, occasionally on mitigation for this stuff.

Physical addresses are just your RAM bytes numbered 1 through whatever.

Not really. There are lots of holes in the physical address map. Look at /proc/iomem. Look at all of the gunk in there at addresses lower than the amount of RAM you have. Look at the highest “System RAM” address. It will be higher than the amount of actual physical RAM that you have.

Yes, this is probably it. More specifically, any 128MB areas in the physical address space that do not have "System RAM" will not get a memoryN directory. You can view all the "System RAM" areas in /proc/iomem (if root, otherwise they're all 0's).

The most relevant kernel code is here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

I am one of the original authors listed at the top of that file.

MSRs can do anything, really. They're also not universally "registers" in any meaningful way. Basically, instead of adding new instructions for everything, CPU designers just add a new MSR. Its kinda like how the kernel assigns a new major/minor for every new device driver instead of a new syscall.

MSRs can also be added by microcode update as we saw with MSR_IA32_SPEC_CTRL, which was used to mitigate Spectre (among other things).

Disclaimer: I work on Linux at Intel, and I was one of the ones posting in that LKML thread quoted in the article.