Hacker News Reader

Comment by bjackman | Hacker News Reader

I work in CPU security and it's the same with microarchitecture. You wanna know if a machine is vulnerable to a certain issue?

- The technical experts (including Intel engineers) will say something like "it affects Blizzard Creek and Windy Bluff models'

- Intel's technical docs will say "if CPUID leaf 0x3aa asserts bit 63 then the CPU is affected". (There is no database for this you can only find it out by actually booting one up).

- The spec sheet for the hardware calls it a "Xeon Osmiridium X36667-IA"

Absolutely none of these forms of naming have any way to correlate between them. They also have different names for the same shit depending on whether it's a consumer or server chip.

Meanwhile, AMD's part numbers contain a digit that increments with each year but is off-by-one with regard to the "Zen" brand version.

Usually I just ask the LLM and accept that it's wrong 20% of the time.

View on HN

> - Intel's technical docs will say "if CPUID leaf 0x3aa asserts bit 63 then the CPU is affected". (There is no database for this you can only find it out by actually booting one up).

I’m doing some OS work at the moment and running into this. I’m really surprised there’s no caniuse.com for cpu features. I’m planning on requiring support for all the features that have been in every cpu that shipped in the last 10+ years. But it’s basically impossible to figure that out. Especially across Intel and amd. Can I assume apic? Iommu stuff? Is acpi 2 actually available on all CPUs or do I need to have to have support for the old version as well? It’s very annoying.

Even more fun is that some of those (IOMMU and ACPI version) depend on motherboard/firmware support. Inevitably there is some bargain-bin board for each processor generation that doesn’t support anything that isn’t literally required for the CPU/chipset to POST. For userspace CPU features the new x86_64-v3/v4 profiles that Clang/LLVM support are good Schelling points, but they don’t cover e.g. page table features.

Windows has specific platform requirements they spell out for each version - those are generally your best bet on x86. ARM devs have it way worse so I guess we shouldn’t complain.

At least on ARM you can get trms or data sheets that cover all of the features of a specific processor and also the markings on the chip that differentiate it from models within the same family.

I’m pretty sure the number of people at Intel who can tell you offhandedly the answer to your questions about only Intel processors is approximately zero give or take couple. Digging would be required.

If you were willing to accept only the relatively high power variants it’d be easier.

I'd be happy to support the low power variants as well, but without spending a bunch of money, I have no idea what features they have and what they're missing. Its very annoying.

For anyone not familiar with caniuse, its indispensable for modern web development. Say you want to put images on a web page. You've heard of webp. Can you use it?

https://caniuse.com/webp

At a glance you see the answer. 95% of global web users use a web browser with webp support. Its available in all the major browsers, and has been for several years. You can query basically any browser feature like this to see its support status.

That initial percentage is a little misleading. It includes everything that caniuse isn't sure about. Really it should be something like 97.5±2.5 but the issue's been stalled for years.

Even the absolute most basic features that have been well supported for 30 years, like the HTML "div" element, cap out at 96%. Change the drop-down from "all users" to "all tracked" and you'll get a more representative answer.

> I’m planning on requiring support for all the features that have been in every cpu that shipped in the last 10+ years. But it’s basically impossible to figure that out.

The easiest thing would probably to specify the need for "x86-64-v3":

* https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...

RHEL9 mandated "x86-64-v2", and v3 is being considered for RHEL10:

> The x86-64-v3 level has been implemented first in Intel’s Haswell CPU generation (2013). AMD implemented x86-64-v3 support with the Excavator microarchitecture (2015). Intel’s Atom product line added x86-64-v3 support with the Gracemont microarchitecture (2021), but Intel has continued to release Atom CPUs without AVX support after that (Parker Ridge in 2022, and an Elkhart Lake variant in 2023).

* https://developers.redhat.com/articles/2024/01/02/exploring-...

> The easiest thing would probably to specify the need for "x86-64-v3"

AFAIK, that only specifies the user-space-visible instruction set extensions, not the presence and version of operating-system-level features like APIC or IOMMU.

RHEL10 has been released and does require x86-64-v3.

https://access.redhat.com/solutions/7066628

Even defining "shipped in the last 10 years" is tricky - because does that mean released or final shipment from the factory or ?

You're often better picking a subset of CPU features you want to use and then sampling to see if it excludes something important.

> then sampling to see if it excludes something important.

But how? That’s the question.

This is unfortunately the same for GPUs. The graphics APIs expose capability bits or extensions indicating what features the hardware and driver supports, but the graphics vendors don't always publish documentation on what generations of their hardware support various features, so your program is expected to dynamically adapt to arbitrary combinations of features. This is no longer as bad as it used to be due to consolidation in the graphics market, but people still have to build ad-hoc crowd sourced databases of GPU caps bits.

It's also not monotonic, on both CPU and GPU sides features can go away later because either due to a hardware bug or the vendor lost interest in supporting it.

CPU Monkey had some neat info like whether a CPU had AV1 hwdec/hwenc, then they redesigned their site and that info is gone for some reason. I think it was a year or less between finding their site and them ruining it.

https://web.archive.org/web/20250616224354/https://www.cpu-m...

https://www.cpu-monkey.com/en/cpu-amd_ryzen_7_pro_8840u

A nice reminder to stick any page you find useful in the wayback machine and/or save a local copy.

I feel like it's a cultural thing with the designers. Ceragon were the exact same when I used to do microwave links. Happy to provide demo kit, happy to provide sales support, happy to actually come up and go through their product range.

But if you want any deep and complex technical info out of them, like oh maybe how to configure it to fit UK/EU regulatory domain RF rules? Haha no chance.

We ended up hiring a guy fluent in Hebrew just to talk to their support guys.

Super nice kit, but I guess no-one was prepared to pay for an interface layer between the developers and the outside world.

I have three Ubuntu servers and the naming pisses me off so much. Why can't they just stick with their YY.MM. naming scheme everywhere. Instead, they mostly use code names and I never know what codename I am currently using and what is the latest code name. When I have to upgrade or find a specific Python ppa for whatever OS I am running, I need to research 30 minutes to correlate all these dumb codenames to the actual version numbers.

Same with Intel.

STOP USING CODENAMES. USE NUMBERS!

As an Apple user, the macOS code names stopped being cute once they ran out of felines, and now I can't remember which of Sonoma or Sequoia was first.

Android have done this right: when they used codenames they did them in alphabetical order, and at version 10 they just stopped being clever and went to numbers.

Ubuntu has alphabetical order too, but that's only useful if you want to know if "noble" is newer than "jammy", and useless if you know you have 24.04 but have no idea what its codename is and

Android also sucks for developers because they have the public facing numbers and then API versions which are different and not always scaling linearly (sometimes there is something like "Android 8.1" or "Android 12L" with a newer API), and as developers you always deal with the API numbers (you specify minimum API version, not the minimum "OS version" your code runs in your code), and have to map that back to version numbers the users and managers know to present it to them when you're upping the minimum requirements...

> Ubuntu has alphabetical order too, but that's only useful if you want to know if "noble" is newer than "jammy"

Well, it was until they looped.

Xenial Xerus is older than Questing Quokka. As someone out of the Ubuntu loop for a very long time, I wouldn't know what either of those mean anyway and would have guessed the age wrong.

Yes, I agree, codenames are stupid, they are not funny or clever.

I want a version number that I can compare to other versions, to be able to easily see which one is newer or older, to know what I can or should install.

I don't want to figure out and remember your product's clever nicknames.

They can't. They used to, until they tried to patent 586...

Trademark.

Protip, if you have access to the computer: `lsb_release -a` should list both release and codename. This command is not specific to Ubuntu.

Finding the latest release and codename is indeed a research task. I use Wikipedia[1] for that, but I feel like this should be more readily available from the system itself. Perhaps it is, and I just don't know how?

[1] https://en.wikipedia.org/wiki/Ubuntu#Releases

> Protip, if you have access to the computer: `lsb_release -a` should list both release and codename. This command is not specific to Ubuntu.

I typically prefer

  cat /etc/os-release

which seems to be a little more portable / likely to work out of the box on many distros.

That's only if the distro is recent enough; sooner or later, you'll encounter a box running a distro version from before /etc/os-release became the standard, and you'll have to look for the older distro-specific files like /etc/debian_version.

> you'll encounter a box running a distro version from before /etc/os-release became the standard

Do those boxes really still exist? Debian, which isn't really known to be the pinacle of bleeding edge, has had /etc/os-release since Debian 7, released in May 2013. RHEL 7, the oldest Red Hat still in extended support, also has it.

> the oldest Red Hat still in extended support, also has it.

You would be alarmed to know how long the long tail is. Are you going to run into many pre-RHEL 7 boxes? No. Depending on where you are in the industry, are you likely to run into some ancient RHEL boxes, perhaps even actual Red Hat (not Enterprise) Linux? Yeah, it happens.

> Do those boxes really still exist?

Yes, they do. You'll be surprised by how many places use out-of-support operating systems and software (which were well within their support windows when installed, they have just never been upgraded). After all, if it's working, why change it? (We have a saying here in Brazil "em time que está ganhando não se mexe", which can be loosely translated as "don't change a (soccer) team which is winning".)

Try cat /etc/os-release. The codenames are probably there. I know they are for Debian.

Thank you! I was just about to kvetch about how difficult it was to map (eg) "Trixie" == "13" because /etc/debian_version didn't have it... I always ended up having to search the internet for it which seemed especially dumb for Debian!

Same problem I have with Debian.

At least Fedora just uses a version number!

I like to think that Buster, Bullseye, and Bookworm was a ploy to make people more dependent on the version number.

I work with Debian daily and I still couldn't tell you what order those go in. but Debian 12, Debian 13, etc.. is perfectly easy to remember and search for.

Debian is trying hard to switch to numbers. It's the user base that is resisting the change.

Maybe they should stop synlinking the new versions after 14, because AFAIK, they already tried everything else.

Yeah if they just stopped using a release name that'd probably do it, although communities can be surprisingly stubborn on some things.

> AMD's part numbers contain a digit that increments with each year

Aha, but which digit? Sure, that's easy for server, HEDT and desktop (it's the first one) but if you look at their line of laptop chips then it all breaks down.

Lol no, for servers (Epyc) it is the last digit. Why? Who knows, to make it more confusing I guess.

I admit it took me until the 4th gen Epyc to realize this. I laughed out loud at myself/the numbering scheme.

Well yeah Epyc is little endian

Oh, the Xeons are with the vX vs vY nonsense, where the same number but a different version is an entirely different CPU (like the 2620 v1 and v2 are different microarchitecture generations and core counts). But, not to leave AMD out, they do things like the Ryzen 7000 series which are Zen 4 except for the models that are Zen 2 (!). (yes if you read the middle digits there's some indication but that's not that helpful for normal customers).

That's been the case with hardware at several companies I was at.

I was convinced that the process was encouraged by folks who used it as a sort of weird gatekeeping by folks who only used the magic code names.

Even better I worked at a place where they swapped code names between two products at one time... it wasn't without any reason, but it mean that a lot of product documentation suddenly conflicted.

I eventually only refereed to exact part numbers and model numbers and refused to play the code name game. This turned into an amusing situation where some managers who only used code names were suddenly silent as they clearly didn't know the product / part to code name convention.

You can correlate microarchitecture to product SKUs using the Intel site that the article links. AMD has a similar site with similar functionality (except that AFAIK it won't let you easily get a list of products with a given uarch). These both have their faults, but I'd certainly pick them over an LLM.

But you're correct that for anything buried in the guts of CPUID, your life is pain. And Intel's product branding has been a disaster for years.

> You can correlate microarchitecture to product SKUs using the Intel site that the article links.

Intel removed most things older than SB late 2024 (a few xeons remain but afaik anything consumer was wiped with no warning). It’s virtually guaranteed that Intel will remove more stuff in the future.

Also technically the code names are only for unreleased products so on ark it’ll say “products formerly Ice Lake” but the intel will continue to calm them Ice Lake.

These have been my go-to for a while now:

https://en.wikipedia.org/wiki/List_of_Intel_Core_processors

https://en.wikipedia.org/wiki/List_of_Intel_Xeon_processors

It doesn't have the CPUID but it's a pretty good mapping of model numbers to code names and on top of that has the rest of the specs.

I hear you.

Coincidentally, if anyone knows how to figure out which Intel CPUs actually support 5-level paging / the CPUID flag known as la57, please tell me.

> Absolutely none of these forms of naming have any way to correlate between them.

I've found that -- as of a ~decade ago, at least, ark.intel.com had a really good way to cross-reference among codenames / SKUs / part numbers / feature set/specs. I've never seen errata there but they might be. Also, I haven't used it in a long time so it could've gotten worse.

Intel do have a website where you can look up SKUs. If you wait long enough and exploit certain bugs in the JS you can get it to give you a bunch of CSV files.

Now the only issue you have is that there is no consistent schema between those files so it's not really any use.

> Meanwhile, AMD's part numbers contain a digit that increments with each year but is off-by-one with regard to the "Zen" brand version.

Under https://en.wikipedia.org/wiki/Ryzen#Mobile_6 Ryzen 7000 series you could get zen2, zen3, zen3+, zen4

I've also found the same thing a decade ago, apparently lots of features(e.g. specific instruction, igpu) are broadly advertised as belonging to specific arch, but pentium/celeron(or for premium stuff non-xeon) models often lack them entirely and the only way to detect is lscpu/feature bits/digging in UEFI settings.

>"it affects Blizzard Creek and Windy Bluff models'

"Products formerly Blizzard Creek"

WTF does that even mean?

Intel doesn't like to officially use codenames for products once they have shipped, but those codenames are used widely to delineate different families (even by them!), so they compromise with the awkward "products formerly x" wording. Have done for a long time.

I wouldn't mind them coming up with better codenames anyway. "Some lower-end SKUs branded as Raptor Lake are based on Alder Lake, with Golden Cove P-cores and Alder Lake-equivalent cache and memory configurations." How can anyone memorize this endless churn of lakes, coves and monts? They could've at least named them in the alphabetical order.

AMD does this subterfuge as well. Put Zen 2 cores from 2019 (!) in some new chip packaging and sell it as Ryzen 10 / 100. Suddenly these chips seem as fresh as Zen 5.

It's fraud, plain and simple.

The entire point of code names is that you can delay coming up with a marketing name. If the end user sees the code name then what is even the point? Using the code name in external communication is really really dumb. They need to decide if it should be printed on the box or if it's only for internal use, and don't do anything in between.

The problem, especially at Intel, but also at AMD, is that they sell very different CPUs under approximately identical names.

In a very distant past, AMD was publishing what the CPUID instruction will return for each CPU model that they were selling. Now this is no longer true, so you have to either buy a CPU to discover what it really is, or to hope that a charitable soul who has bought such a CPU will publish on the Internet the result.

Without having access to the CPUID information, the next best is to find on the Intel Ark site, whether the CPU model you see listed by some shop is described for instance as belonging to 'Products formerly Arrow Lake S", as that will at least identify the product microarchitecture.

This is still not foolproof, because the products listed as "formerly ..." may still be packaged in several variants and they may have various features disabled during production, so you can still have surprises when you test them for the first time.

So they should put it on the box. In small font on the back if necessary, but make it an official part of the spec sheet - don't pretend it's irrelevant.

Product lines are in design and development for years, two years is lightning fast, code names can be found for things five or more years before they were released, so everyone who works with them knows them better (much better) than the retail names.

It means Intel M14 and M15 base designs. Except they don't use numbers.

AMD distributed a decoding wheel for their laptop chip naming this year.

Do you just have banks of old CPUs from every generation to test against?

Nope. Recently I had to use my company card to buy an ancient mini-PC from eBay just so I could get access to a certain Skylake model

  - sSpec S0ABC                   = "Blizzard Creek" Xeon type 8 version 5 grade 6 getConfig(HT=off, NX=off, ECC=on, VT-x=off, VT-d=on)=4X Stepping B0  
  - "Blizzard Creek" Xeon type 8 -> V3 of Socket FCBGA12345 -> chipset "Pleiades Mounds"   
  - CPUID leaf 0x3aa              = Model specific feature set checks for "Blizzard Creek" and "Windy Bluff(aka Blizzard Creek V2)"  
  - asserts bit 63                = that buggy VT-d circuit is not off  
  - "Xeon Osmiridium X36667-IA"   = marketing name to confuse specifically you(but also IA-36-667 = (S0ABC|S9DFG|S9QWE|QA45P))

disclaimer: above is all made up and I don't work at any of relevant companies

Reply on news.ycombinator.com