hansendc

29 ms·

31.
by hansendc 7y ago
As mentioned elsewhere, Intel uses "Work Weeks" for everything. It might be great for manufacturing where a wafer takes a specific number of days to make it through the fab, but it inflicts horrible pain on the folks who have to
32.
by hansendc 7y ago
The good news: There's a new MSR which lets you do this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The less good news: as far as I can tell, Intel did not commit to h
33.
by hansendc 7y ago
On Linux, most (maybe even all) of the data structures that must grow with memory size can be carved out of the memory being added. The main culprit is 'struct page' which typically needs 64b of metadata for each 4k physical page
34.
by hansendc 7y ago
This solution didn't introduce it. The concepts being used have existed in Linux for quite some time. Here's a patch of mine that added (some of) it from 2005: https://git.kernel.org/pub/scm/linux/k
35.
by hansendc 7y ago
mem= doesn't control the amount of RAM. It actually just specifies the largest physical address the kernel should try to use. The first 4GB of physical memory typically has some non-RAM things in it like the part of the physical addr
36.
by hansendc 7y ago
I think you may be confusing some of the aspects of hot-add with hot-remove. Memory which you want to later remove should be onlined as "movable" and it has some content limitations. But, not all hot-added memory must be onlined
37.
by hansendc 7y ago
If you think employing open-source maintainers gives a company "control" over a project, you haven't met many maintainers. In any case, IBM is very respectful of the health of the open source projects on which it depends. Wh
38.
by hansendc 7y ago
Ex-IBMer here... I'd really suggest finding one of your colleagues that's seen IBM's track record with acquisitions and pick their brain a bit. They'll have much more relevant information for you than your old CEO.
39.
by hansendc 7y ago
It would have made more sense to call this on "RAMbo First Bleed". Next year it can be "RAMbo First Bleed Part II".
40.
by hansendc 8y ago
Disclaimer: I work on Linux at Intel. FWIW, I don't think PR had anything to do with this. Without arguing the merits of embargoes, the goal of them is to give the good guys a head start before the bad guys. But, if you tell too many
41.
by hansendc 8y ago
Disclaimer: I work on Linux at Intel. I'll give you an engineer's perspective, and specifically about Meltdown since that's what I worked on. I posted the first Meltdown mitigations in late October, publicly claiming to mitig
42.
by hansendc 8y ago
Disclaimer: I work on Linux at Intel. I'm biased, of course. But, I think things are much better now. We have ways of having relatively "normal" conversations about these things where a broad set of community folks are in
43.
by hansendc 8y ago
Disclaimer: I work on Linux at Intel. Future hardware will be mitigated against side-channel issues. There's a nice table showing how things are mitigated on future processors here: https://www.tomshardware.com/news&#x
44.
by hansendc 8y ago
I worked on the Meltdown mitigations, at Intel, during the embargo. I still work on Linux at Intel. Intel told quite a few members of the Linux community about this well before late December. Some got told because they work for traditiona
45.
by hansendc 8y ago
Response from Intel that includes a new version of the license is here: https://twitter.com/imadsousou/status/1032680311753072640 Disclaimer: I work at Intel
46.
by hansendc 8y ago
That commit disables the lazy mode by default on processors supporting the XSAVEOPT instruction. But, it's possible to override that default with the eagerfpu= kernel command-line option, or that a hypervisor has masked out support fo
47.
by hansendc 8y ago
The processor has XSAVE (the mechanism that we use to save/restore FPU state and more these days) optimizations internal to the processor that keep it from having to fully reload the FPU state. OSes like Linux have not been doing laz
48.
by hansendc 9y ago
Disclaimer: I work on software (Linux) at Intel. There are certainly non-JIT-related mitigations out there. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
49.
by hansendc 9y ago
Disclaimer: I work on software (Linux) at Intel. Spectre variant 1 is arguably a software problem. It's not about consuming "bad" data that was placed by an adversary like variant 2, or allowing a rogue data cache loads like
50.
by hansendc 9y ago
I think you are confusing the TLB and processor data caches. PCIDs exist for virtual addresses and are implemented in the TLB, not the processor caches. The processor caches are physically indexed, not virtually indexed. So, does the pro
51.
by hansendc 9y ago
Sharing an address space is nice. Programs pass lots of pointers into the kernel (think read()/write()). For the kernel to get at that data, if the kernel and userspace share an address space you can just use the pointer. If users
52.
by hansendc 9y ago
I work on the Linux KPTI/KAISER code (and work at Intel). The high-level description, along with the set of hardware things that get mapped into both kernel/app page tables are basically identical. Creating that list of things
53.
by hansendc 9y ago
Yes, I was referring to the Linux kernel: it does barely uses recursion and has small stack sizes compared to normal applications.
54.
by hansendc 9y ago
Disclaimer: I put a big chunk of that paper together. That definitely was not the intent! Getting retpoline to the place it is today took a ton of work from a ton of people, including the awesome folks at Google like Paul Turner, and count
55.
by hansendc 9y ago
Disclaimer: I put a big chunk of that paper together. You ask how it can be guaranteed with "general code". The first thing to remember is that retpoline is not for "general code". Linux, for instance, does not support
56.
by hansendc 9y ago
Meltdown mitigations do not flush the TLB when changing from kernel to/from user when the PCID feature is in place. That's basically everywhere from Haswell on (for Linux and Windows), and in some places as early as Nehalem (>
57.
by hansendc 9y ago
This arch/x86/events/intel/ds.c fix is unlikely to have rendered too many things unbootable. I missed ds.c entirely when doing the original implementation. I can't fault the nice folks at Canonical for mis-merging