Messages

1

General OpenPOWER Discussion / Re: Announcement from Raptor / Solid Silicon Corp

« on: October 22, 2023, 07:26:01 pm »

S1 is now confirmed a POWER9.

Since POWER9 is ISA 3.0, and the announcement said ISA 3.1, how is this possible?

2

General OpenPOWER Discussion / Re: Announcement from Raptor / Solid Silicon Corp

« on: October 21, 2023, 10:52:12 pm »

I want to believe in this as much as anybody else here, but the only way this adds up -- and it's still quite a stretch -- is if this chip really is a Power10, possibly with very minor metal-mask-only changes (like the spectre-fix stepping of Power9), and Raptor somehow miraculously talked IBM into this but couldn't convince them to license the "Power10" trademark.  Like I said, quite a stretch.

I'd love to believe that somebody other than IBM is doing an owner-controlled, independently-developed PowerISA 3.2 chip on a leading-edge node.  But that's way into "flying pigs in snowy hell" territory.  It's eight figures just for the maskset on anything newer than Power9's GloFo14 process.  What sort of investor gave that kind of cash to a company which did not seem to exist until this announcement surfaced? (and can I have some? )  Not to mention the lead times!  If this was an independent design with any chance of shipping by end of 2024, there would be physical MPW samples already.

I'd love to be totally wrong about all of this.

Even if it is a "white label Power10", there are still a lot of questions.  What's the story with the memory controller?  I saw some comment somewhere suggesting maybe putting a serial-to-parallel (OMI-to-DDR) fanout chip (the heatsinked chip in this photo) inside the same package as the CPU die, along with an immutable ROM for its firmware.  But that too seems improbable... those fanout chips are designed to drive really short traces on the same PCB (this is a big part of the power savings they claim).  The odds that they would be able to drive big long traces passing across a DIMM slot and cardedge seem slim.  None of the other customers buying those chips need that capability (if they did, they wouldn't be fooling around with OMI in the first place).

3

General OpenPOWER Discussion / Re: external oscillator in v1.01 boards - which problems does it aim to resolve?

« on: September 25, 2022, 04:10:32 pm »

The oscillator is mentioned in this commit

From that commit:

<pre>
-   // Implement nasty ring oscillator for fallback use when main system clock is offline
-   // Thanks to Clifford Wolf for the idea and basic code!
</pre>

Wow, I'm surprised they have to use a LUT-based ring oscillator here.  All the Xilinx and Altera FPGAs I've ever dealt with had an internal "hard" (not made of LUTs) ring oscillator that could be routed into the fabric.  Still not great, but more predictable than LUTs.  Don't the Lattice ICE chips have this?  Can't the PLLs be used for this (use the slowest setting, ignore the lock signal)?

Anyways, if your board has the external oscillator you should definitely use it.

4

General CPU Discussion / Re: Ultravisor state and/or FlexVer as a substitute for confidential/trustworthy rem

« on: September 09, 2022, 03:57:06 am »

Why would you do otherwise?

Allow the ultravisor to trap if it chooses to (or not, if it chooses to).  The fact that the choice is taken away for this one particular device function is extremely weird.

RDRAND on recent (Ivy Bridge at least) x86_64 is the same way.

No; on x86_64 the hypervisor can trap-and-emulate RDRAND if it chooses to do so: https://patchwork.kernel.org/project/kvm/patch/20170821192640.30817-1-jmattson@google.com/

Since it's a source of entropy, virtualizing it would potentially compromise the cryptographic security of the guest.

Ultravisors can always compromise the security of their guests.

5

General CPU Discussion / Re: Ultravisor state and/or FlexVer as a substitute for confidential/trustworthy rem

« on: September 08, 2022, 02:50:49 pm »

I always found very weird that the rev 2.3 ~~hypervisor~~ (edit: ultravisor) can't virtualize the hardware random number generator.

In other words, unprivileged code always has direct access to the HWRNG, and the OS/hypervisor/ultravisor can't do anything to change that.

So very strange.

6

Firmware / Re: network card to reduce attack surface?

« on: August 19, 2022, 12:23:14 pm »

In this case, there is no checking that the requested MAC is different from the host MAC, and so I will add that in a future release, as it's a very good point.

Stuff like this is my big-picture concern.

The ASPEED BMC has its fingers in a lot of pies.  Removing it from the trusted computing base is much less error prone than trying to plug all the different holes in it.  We're not even sure we know about all the holes.

It's great that we now have control firwmware-level control of the BCM5719!  Back when I bought my Talos2s that was not the case, and it annoyed me, a lot.  This is an awesome development, but it doesn't solve all the problems that come from assuming the ASPEED BMC is trustworthy.

7

Firmware / Re: network card to reduce attack surface?

« on: August 19, 2022, 03:57:11 am »

The general threat model for the Talos II and blackbird is that the BMC is in control of the host, and not the other way around, ado so this is how things are designed. The BMC can always compromise the host.

This is a weak threat model that some people choose to adopt for convenience's sake.  If this were the most general threat model, the SEEPROM and many other features would be pointless.

the BMC can still take control of this by replacing the host image.

In a properly secured system this is at worst a denial-of-service attack.  See https://wiki.raptorcs.com/wiki/Secure_Boot_with_your_own_keys

Technically speaking, the only way that the BMC can take control of the network controller is by loading a custom host OS image,

Take a look at the Talos2 schematics: T2P9D01, v3.8, page 96.  The NCSI management interface for the ethernet chip goes to the BMC.  This is essentially the management interface for the tiny switch inside the BCM5719.  It can select the filtering criteria (vlan, mac address, etc) for which packets get passed to the BMC.  Or it can set no filtering at all in order to let the BMC sniff all traffic.

Think about it: both "tcpdump" and "ip link set dev address $MAC_ADDRESS" work on the BMC.  You can sniff traffic and inject packets on either ethernet port from the BMC, without "loading a custom host OS image".

8

Firmware / Re: network card to reduce attack surface?

« on: August 16, 2022, 03:57:45 pm »

so to clarify, the BMC on the blackbird is isolated and not accessible if one has network access on the other two ethernet ports. correct?

I'm not sure about the Blackbird, but please note that this is most definitely not true for Talos2.

The Talos2 BMC is connected directly to the management interface of the two-port ethernet chip, and there is nothing you can do to prevent an attacker with control of the BMC from having total control over both network adapters.

All of my Talos2 machines use separate PCIe cards for networking as a result of this unfortunate situation.  Hopefully Arctic Tern will eventually allow me to re-pinstrap the BMC and hold its reset pin in the asserted state so I can go back to using the on-motherboard ethernet ports.

9

Talos II / Re: Secure Mode?

« on: July 29, 2022, 04:06:15 pm »

To expand a bit... various schemes for "secure boot" usually involve a "master public key" in one-time programmable memory (usually called eFUSE) which can be written to only once.  It is extremely difficult and usually impossible to obtain chips which for which these fuses haven't already been written -- even if they're written with all zeroes.

POWER9 has a much better approach: there is a tiny 64kbyte flash die inside the CPU package which holds two copies of the master signing key, as well as two copies of the earliest instructions executed by the CPU (other chips call this the MASKROM).  You can rewrite these!  But they are write-protected by default, so that malware can't replace them.

Installing the "secure mode disable" jumper un-write-protects the keys so you can change them.  You should remove the jumper to re-write-protect the keys afterwards.

The early Chromebooks implemented a similar scheme using the write-protect pin on their CPU's bootloader flash chip, and also the Embedded Controller's flash chip.  The EC flash implemented the "two copies" scheme as well.  POWER9 has it built in to the CPU.

10

Talos II / Re: Secure Mode?

« on: July 29, 2022, 03:58:18 pm »

Yes!  Right here: https://wiki.raptorcs.com/wiki/Secure_Boot_with_your_own_keys

11

General OpenPOWER Discussion / Re: Arctic Tern user manual posted

« on: July 29, 2022, 01:11:44 pm »

Same here. But for me it's way too expensive for only speeding up the boot process.

I agree.  But I think it's better to think of Arctic Tern as a dev board rather than the final "make the boot fast" commercial product.

Although the software/gateware may not currently support it, the Arctic Tern was clearly designed with a lot of other neat features in mind (*).  It's priced with margins appropriate for a low-volume development board.

I can definitely see a future stripped-down bare bones "just speed up the boot process" version consisting of just the AT1MB1, the FSI adapter, and a $10 adapter PCB.  The expensive component on the AT1MB1 is $73 if you buy a whole tray of them.  Note also that DigiKey is sold out of *all variations* of that chip, so Raptor likely needs to cover their entire NRE out of whatever allocation they were able to get from Lattice -- I wouldn't be surprised if this was as small as 100 chips.

Anyways, I ordered one, since I want to use it for development purposes.  I'm totally okay with the pricing for that purpose.  OpenBMC is an nice piece of software, but we shouldn't be forced to use something that is so heavyweight.  I'd like to help with the task of offering a leaner option.

(*) I have some wild speculation on why there are two module slots... especially if they can run from a common clock.

12

General OpenPOWER Discussion / Re: News?

« on: July 28, 2022, 09:34:55 pm »

>>This all solely due to IBM's poor decision to close parts of the POWER10 platform, it's quite sad.

seem to be related to non-IBM components very possible IBM is not allowed to make the source code available.

And you think they didn't know that when they made the decision to use those components?

13

General OpenPOWER Discussion / Arctic Tern user manual posted

« on: July 28, 2022, 12:56:30 am »

https://wiki.raptorcs.com/w/index.php?title=File:Arctic_Tern_Users_Guide_Version_1.00.pdf

takemymoney.jpeg (literally... I would've bought a Lattice Versa back when that was the dev platform, if they hadn't become unobtanium...)

Way to go RaptorCS!  This thing fixes my only serious gripe with the Talos II platform.  And the way it fixes it -- using an FPGA, which is totally impractical to backdoor on a large scale -- is total genius.

14

General OpenPOWER Discussion / Re: News?

« on: June 14, 2022, 12:20:09 am »

I fear that the effort to merge the Firefox powerpc64le JIT support will hit similar nontechnical roadblocks.

I don't think so, insofar as I have unofficial OKs once I get it to a point I'm happy with it.

Very glad to hear that!

15

General OpenPOWER Discussion / Re: News?

« on: June 12, 2022, 08:43:54 pm »

including the potential existence of a third party agreement that would prohibit it.

I'm quite sure one exists, although less sure that it is the entire explanation for the situation.

One of the major concessions to get Hollywood to stop insisting on browser plugins (Flash and Silverlight) was the browser vendors agreeing to never allow their brands to be placed on a piece of software that didn't support EME, as a condition of receiving CDM licenses (widevine, etc).  Unfortunately User-Agent has made brands and trademarks part of protocols, but that's another story....

Anyways, this licensing condition is the reason for weird situations like:

• Builds of Firefox that make no changes other than disabling EME being forced to use a different name.
• Firefox suddenly and silently flag ignoring the --disable-eme flag since September 8th, 2017 -- so the only way to truly disable EME is to patch the source code like Tor-Browser does.  This gives Mozilla a toehold to claim that what you're compiling "isn't Firefox" and politely ask you to not use their trademark.
• (I speculate) Google dragging its feet on powerpc64le.  Having to get Widevine working on powerpc64le and then maintain it is a burden for them, which is a factor in their decision.

You might have better traction asking the QT folks to integrate the patches into QTwebengine.  They support widevine but don't distribute the binary themselves, which strongly implies that they are not allowed to do so.  The only reason they wouldn't be allowed to do this is lack of a licensing agreement.  If they don't have a licensing agreement then they aren't subject to the "everywhere or nowhere" requirement.

I fear that the effort to merge the Firefox powerpc64le JIT support will hit similar nontechnical roadblocks.  I hope I'm wrong about that.