hansendc
Joined 8 years ago
Karma
363
Submissions
58
Member since
Jan 7
Recent submissions
Comment · 8 months ago
Comment · 8 months ago
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.
Comment · 3 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.
Comment · 3 years ago
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...
Comment · 4 years ago
> 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.
Comment · 4 years ago
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).
Comment · 4 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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)
Comment · 4 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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).
Comment · 4 years ago
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.
Comment · 4 years ago
"It may do the wrong thing at the worst time" -- each FSD Beta announcement email.
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!