__init

Intel x86 cores have had Last Branch Records (LBRs) and Branch Trace Store (BTS) since at least Merom in 2006 [1][2]. Nowadays, there's Processor Trace (PT) or Precise Event-Based Sampling (PEBS) which can provide even more information. PT in particular is almost purpose-built to enable this kind of trace reconstruction.

[1] https://stackoverflow.com/questions/14670586/what-is-the-ove...

[2] The MSRs for LBRs (MSR_LASTBRANCH_*_{TO,FROM}_IP) and BTS (IA32_DS_AREA) are described in Volume 4, Section 2.2 of the SDM: "MSRS IN THE INTEL® CORE™ 2 PROCESSOR FAMILY". Core 2 was launched in 2006.

I work remotely on a small-ish research team. Almost all of my immediate colleagues are in the US or Western Europe. Most (all?) of the folks on P- and E-Core Engineering that I work with are full employees (i.e. not contractors) in the US or Israel. I'm not sure I'd know if they were H1Bs, but they're generally very knowledgeable and hardworking. From my perspective, there's little outsourcing on the core businesses (pun fully intended).

As far as comp goes, mine is competitive with Bay Area FAANG.

No; in fact, we're doing more of our core development in the US than at some previous points in our history.

(I work at Intel, but this is just my personal observation.)

At Berkeley, course numbers >100 are upper-division, and those <100 are lower-division, introductory classes. Especially in the CS department, the upper-division courses are far from introductory. 61B is the the second in the 61A-B-C series, which is required for all CS majors. (A fourth lower-division class, CS 70 ("Discrete Mathematics and Probability"), is also required, but is independent of the 61 series.)

X11 forwarding for Cadence's chip layout tooling is practically unusable nowadays! Sub-1 FPS, even on a reasonable 1 Gbps pipe with only 3-4 ms ping. I had to use NoMachine when I was doing that work -- proprietary tooling that does the "simpler" image/video streaming.

(Disclaimer: I work at Intel, but not on server products. Opinions are my own.)

There's a lot more that goes into a server platform than just the cores, for instance: the BIOS code, the BMC support, the maturity of the motherboard designs, etc. These are all areas where Intel seems to still have an edge -- but I'm also very excited about our upcoming server architectures on the core/compute side.

Further optimization are certainly possible, especially as the hardware improves and gains additional capabilities. With regards to your suggestion, this is essentially what already happens, thanks to the magic of out-of-order cores.

Check out angr [1], a symbolic execution engine, and claripy [2], its frontend to SMT solvers like z3. Depending on your background, I probably wouldn't describe angr as "for newbies," but claripy is a very clean SMT interface!

[1] https://angr.io

[2] https://api.angr.io/claripy.html

Most assemblers for Intel syntax will let you write:

    add eax, [4]

if you desire. Indeed, many disassemblers will follow suit in unambiguous cases. IDA, for example, does this.

Another approach with which I've had success is to use something like PCBite's probes [1] to stab the little bits of solder sticking out the sides of the WSON package. PCBite's probes are excellent; they're sharp enough bite into the solder and hold themselves in place. (Those stalks aren't stiff; they support themselves by digging in.) PCBite is an all-around great product and definitely worth the somewhat-steep-for-a-hobbyist price tag, in my opinion.

[1] https://sensepeek.com/pcbite-20

This is one of my favorite episodes. I always thought the thin veiling helped to demonstrate the absurdity of both situations -- perhaps it was even done intentionally for that reason.

Erm, I'm not sure if you're being sarcastic, but they certainly are not giving these away to youtubers. This is a >$1 million instrument that isn't even very useful for hobbyist electronics. The ones they give away are from their new EDU line that does around 100 MHz sampling.

They made _vacuum tubes_ survive 20,000g during WWII [1]. Modern military applications have guidance computers packed into individual bullets [2]!

[1] https://en.wikipedia.org/wiki/Proximity_fuze#Improvement_in_...

[2] https://en.wikipedia.org/wiki/Smart_bullet

More specifically, it's a system on a _package_. A TLB lives on the _die_, though, with one in each core.

> Real-world IPC is something like 3x (!) that of Intel right now - obviously it also clocks lower

That's the problem, though -- if you clock yourself much lower, of course you can get higher IPC; you can pack more into your critical paths.

Now, certainly Apple has some interesting and significant innovations over Intel here, but quoting IPC figures like that is highly misleading.

Great to hear that Intel is finally competitive in this space again. If process improvements are coming on time (and they are, if Pat is to be believed), perhaps Intel can finally compete in low-power, high-perf versus M1.

It generally goes the other way around -- programmers and compilers settle on a few idiomatic ways to do something, and new cores are built to execute those quickly. Because RISC-V is RISC, it seems likely that those few ways would be less idiomatic and more 'the only real way to do x', which would aid in the applicability of the fusions.

Oh no, you're absolutely right. My sleep-deprived brain has confused the names -- thanks for the heads up. I'll edit my post.

(Edited because I transposed "mutex" and "semaphore" in my mind.)

A mutex is a lock -- if multiple users attempt to access a resource simultaneously, they each attempt to acquire the lock serially, and those not first are excluded (blocked) until the current holder releases the lock.

Mutexes are typically implemented with semaphores:

First a more developer-oriented explanation (because I imagine that's what you really want):

A semaphore locks a shared resource by implementing two operations, "up" and "down". First, the semaphore is initialized to some positive integer, which represents how many concurrent "users" (typically threads) can use that resource. Then, each time a user wants to take advantage of that resource, it "down"s the semaphore , which atomically subtracts one from the current value -- but the key is that the semaphore's value can _never_ be negative, so if the value is currently zero, "down"ing a semaphore implies blocking until it's non-zero again. "Up"ing is just what you'd imagine: atomically increment the semaphore value, and unblock someone waiting, if necessary.

Semaphores are generally seen as a fundamental primitive (one reason being that locks/mutexes can be implemented trivially as a semaphore initialized to one), but they also have broad use as a general synchronization mechanism between threads.

For a true ELI5 of semaphores (I enjoy writing these):

Imagine everyone in class needs to write something, but there are only three pencils available, so you devise a system (a system of mutual exclusion, per se) for everyone to follow while the pencils are used: First, you note how many pencils are available -- three. Then, each time someone asks you for one, (which we call "down"ing the semaphore) you subtract one from the number in your head and give them a pencil. But if that number is zero, you don't have any pencils left, so you ask the person to wait. When someone returns and is done with their pencil, you hand it off to someone waiting, or, if nobody is waiting, you add one to that number in your head and take the pencil back ("up"ing the semaphore). It's important that you decide to only handle one request at a time (atomicity) -- if you tried to do too many things at once, you might lose track of your pencil count and accidentally promise more pencils than you have.

Thank you! It means a lot to me to be able to share what I learned. I don't know much of anything about the AMD side of things -- I'm just a poor college student and my investment in Intel platforms already hurt enough! Here's a brain dump about Intel, though:

Unfortunately we (the public) know very little about Yellow and Red. (Most of the time it's just called "Red" and "Red Unlock", because Red is a superset of Yellow and most conceivable exploits that could elevate to Yellow would also elevate to Red.)

[1] is a great place to start. It's a tiny bit out of date now (DAL was deprecated a while ago in favor of . . . IPC, I think it's called?). Check out Mark Ermolov's (one of the author's) Twitter [2] for some interesting developments -- he has Red unlock on a Goldmont Atom core via a cool exploit that he published (that has since been patched), leading to microcode (!) readout. (On a side note, I strongly suspect that he has some form of inside information -- there have been times where he knows some facet of the chipset internals that I can't find _any_ reference to online. I don't mean to diminish his work though; it's very cool stuff.)

Another good place to learn is the leak from last summer, referred to as "Ex-confidential lake." It doesn't contain anything damning, but skimming through it, especially the boot/bringup stuff, will help familiarize you with the terminology and also serves as a good reference if you have to dig through a compiled BIOS -- the leak contains the FSP source.

[4], a BlackHat talk, and [5], Intel's response/analysis, are super interesting. You'll definitely have to read them over a few times!

[6] is another great talk from Ermolov that also discusses Red unlock.

Finally, one of my favorite "tricks" is to just google for "<term> "Intel Confidential" filetype:pdf". You'll turn up a surprising amount of internal info that way.

In short, you need to do _a lot_ of research. I spent nearly an entire month just searching the internet for more information. A fun, endless mystery to solve!

(P.S. I'm not sure if you realize this, but it confused me initially: Chipset == Platform Controller Hub (PCH) != Management Engine (ME). The chipset/PCH is the whole piece of silicon that runs the system, whereas the ME is only the small processor core inside of there that performs some higher level operations such as booting and maintaining a root of trust. The PCH has a lot of cool stuff outside the ME!)

(P.P.S. If you're looking for something a bit easier to get started on, but also interesting and impactful, there's a lot of undocumented stuff going on in the PCRs -- the Platform Configuration Registers. It's partially documented in part 2 of the chipset datasheets, but there are a lot of fields that are readable/writable without any description. I wrote some very basic tools relating to it here [7] and here [8]. If you do something interesting with it, I'd love to hear: shoot me an email at my github username at gmail.)

[1]: https://conference.hitb.org/hitbsecconf2017ams/materials/D2T...

[2]: https://twitter.com/_markel___

[3]: https://web.archive.org/web/20190924162111/http://support.pr...

[4]: https://i.blackhat.com/USA-19/Wednesday/us-19-Hasarfaty-Behi...

[5]: https://www.intel.com/content/dam/www/public/us/en/security-...

[6]: https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Goryachy...

[7]: https://github.com/pcgrosen/pcredit

[8]: https://github.com/pcgrosen/pychipset/blob/master/chipset/pc...

Oh boy. Yes, I spent nearly a year trying to work with the Direct Connect Interface (DCI), Intel's implementation of this. It's a long, complicated, difficult, and frustrating process.

The short version is that, unless you have a corporate contract with Intel, there is so much randomness involved that the time and effort necessary to get it working are probably not worth it.

The main challenge is finding a compatible motherboard. There are three main factors that need to align for a given board to work:

1. The CPU XDP (Extended Debug Probe, includes JTAG) lines need to be routed to the chipset. Because you're actually talking to the chipset via DCI (it's the one that manages the USB ports), if they aren't, you'll only be able to access the chipset in your debugging session (i.e. you'll have no access to the typical debugging stuff that you're probably after), which, without Intel's keys to unlock Yellow and Red mode, isn't super interesting (though I would like to look into it more . . .). It's extremely difficult to guarantee a given board has these routed before getting your hands on it; I wasted some money on a few that didn't. Your best bet is if you can find a schematic buried somewhere on the internet, although even then, this is a part of the board that's likely to change between revisions without notice.

2. You'll want the BIOS to "support" enabling DCI -- In quote marks because I've never encountered one that will just let you do it through the GUI. Instead, most of the time you'll wind up modifying a non-volatile UEFI configuration bank for something called Intermediate Forms Representation (IFR), which is a format that Intel's Firmware Support Package (FSP) uses to store the BIOS configuration options. (Most BIOS GUIs are just skins on top of this.) There are a few options you need to flip in here, so you'll need to use an IFR extractor on your particular BIOS to recover the offsets and such for the appropriate options; once you have them, you'll use something like RU.efi to actually twiddle the bits. It's worth noting that not every BIOS uses this approach. I can't recall who it was, but there was at least one vendor whose BIOS didn't contain any IFR. In that case, you'll likely need to patch the BIOS directly -- an enormously complicated task, worthy of another post. I developed a successful patch once, which would have worked were it not for the third factor . . .

3. The chipset must be configured to serve DCI over a particular USB port. This is the factor I know the least about. There were a few boards I found that were _very_ finicky about which ports they would serve. Obviously, at the bare minimum, you have to connect to a port served _directly_ by the chipset, but it seems that there are factors even beyond that. Perhaps they are configurable in firmware, or maybe they are programmed in eFuses in the chipset -- I'm not sure. In any case, be sure to try all of the available ports, including USB-C. There was one board where I got everything else working, but none of the ports let me in -- absolutely infuriating.

All in all, I evaluated several dozen boards (looking for schematics, downloading and reversing BIOSes) and purchased eight; of those, two worked. The first was a Dell Precision 5520, and the second was a Asus TUF Z370 Plus Gaming. I couldn't get a 8th Gen Intel NUC working (it was behaving as though the CPU wasn't connected, which is odd considering the chipset and CPU are integrated onto one die).

Once you have a board, you'll need Intel System Debugger. (This was previously packaged with Intel's free version of System Studio, but I've heard rumblings that, as of just recently, this is no longer the case.) This part is pretty straight forward -- the documentation should have you covered.

This was definitely one of my favorite projects, but if you're looking for a simple debugging solution, this ain't it.

Wow, really great stuff! I wrote something similar for my high school a few years ago (back when I was less experienced with programming -- ack!). I used a library called JSCPP to interpret the C++ directly in the browser.

It included analogRead() and Serial functionality; maybe it can give you some ideas regarding the UI.

Here's the source: https://github.com/dpengineering/giffer-reborn

And you can try it here: https://dpengineering.github.io/giffer-reborn/

It sounds like he's defending _a_ caste system, but probably not the one you're thinking of.

Originally, "the device is bricked" meant that the device was about as useful as a brick, i.e. it had no useful functionality left couldn't be recovered at all. However, as the parent points out, it's been increasingly misused.

I'm really surprised to hear that. ST has always been one of my favorite manufacturers. I find their datasheets to be clear and well laid out, though I will note that I'm usually more interested in the hardware side than the software side. Their chips and boards are also high quality and convenient, e.g. GPIOs are often five-volt tolerant, Nucleo boards come with well-made breakout headers and several peripherals (at seemingly impossibly low cost), chips have wide supply voltages, etc. I can't say I know anything about their errata (I've never run into any), but even if the situation is as bad as you say, that's quite a harsh condemnation, especially considering how widely-used and successful they are in industry. Do you have other complaints?

Looks like those are already called "palprimes" [0].

[0] https://en.wikipedia.org/wiki/Palindromic_prime

As I understand it, the main issue is that the power output of the batter decreases as it degrades, not just its total capacity. Apple claims that the throttling is needed in order to prevent the processor from automatically shutting off because it can't draw as much power as it requires -- not just to prevent the battery from draining faster.

Unfortunately, hardware vendors are jumping on the DRM train, too, with things like Qualcomm's Secure Execution Environment [1], and Intel's Secure Enclave [2].

[1] https://www.qualcomm.com/media/documents/files/snapdragon-st... (PDF)

[2] https://software.intel.com/en-us/sgx