[HN Gopher] Intel gets worse, but Power11 might get better
___________________________________________________________________
Intel gets worse, but Power11 might get better
Author : classichasclass
Score : 102 points
Date : 2022-02-27 17:52 UTC (5 hours ago)
(HTM) web link (www.talospace.com)
(TXT) w3m dump (www.talospace.com)
| theandrewbailey wrote:
| > (wars, pestilence, <s>locusts</s> and inflation
| notwithstanding)
|
| I wouldn't be so quick to discount locusts. There was a big swarm
| of them not long ago. The world is growing crazier by the year.
|
| https://www.npr.org/sections/goatsandsoda/2020/06/14/8760024...
| jtbayly wrote:
| Big Locust swarms are not a new thing. It would be a crazier
| world if they completely stopped.
| calvin_ wrote:
| RCS dying on the hill of DDR training blobs seems a bit
| ridiculous to me when the system is much better elsewhere. RYF in
| action!
| wmf wrote:
| I'm calling BS on all this.
|
| 1. Today we have FSP blobs but in the future we're going to have
| (menacing voice) Scalable FSP blobs. I consider Coreboot people
| to be unreliable narrators since Coreboot is feature-poor and
| isn't free from blobs anyway.
|
| 2. Pluton is going to be required for Windows so Intel, AMD, and
| Qualcomm will all have it. Resistance is futile. (It is really
| dumb that MS is FUDding themselves by not documenting Pluton.)
|
| 3. AFAIK Power10 was mostly finished before the pandemic. The
| switch from GloFo to Samsung and IBM's lack of experience with
| the Samsung process is more likely the cause of the third-party
| IP. Even if it was fully open the price/performance would still
| suck like all Power generations.
| oneplane wrote:
| Since Windows is going to be irrelevant anyway (run everything
| in a browser, stream everything 'heavy', now the local OS is
| just a 'viewer'), and most 'connected' users on the planet are
| using a phone and whole generations grow up only ever using a
| phone for media/games/productivity and never touching a
| laptop/pc, all this will do is make Windows a niche.
|
| Coreboot might not be perfect, but until there is enough
| powerful hardware (like ARM and RISC-V that isn't just multi-
| core but also has enough single-threaded performance) it's not
| like you're going to be able to run free and libre firmware on
| reasonable hardware (and no, pre-CSME hardware and pre-FSP
| hardware is not reasonable, it's just old at this point).
|
| I hope POWER and ARM and later on RISC-V are getting powerful
| enough to not have to trust a CSME or FSP in the long run, but
| I doubt it. Even just having a PAVP DRM is something that is
| pushed by various corporate legal departments so hard that all
| the hardware that ends up in consumer land is going to be
| hobbled one way or another.
|
| I'm afraid we'll end up in a world where you can get that libre
| and free stack on high performance hardware, but won't get
| access to all the IP, including IP cores for embedded FPGAs and
| IP like streaming media including audio, video and games.
| no_time wrote:
| >I'm afraid we'll end up in a world where you can get that
| libre and free stack on high performance hardware, but won't
| get access to all the IP, including IP cores for embedded
| FPGAs and IP like streaming media including audio, video and
| games.
|
| Exactly. Also what worries me is that all it takes is one
| significant terrorist event to be organized over a libre
| software stack to get all this treachery in computing to
| become law too.
| tyingq wrote:
| I think there's also a change in the server market where there's
| going to be (already is?) two pillars.
|
| So cloud vendors can pressure Intel/AMD into exclusive features,
| or turning off features they don't like, etc. Where
| Dell/HP/others increasingly lose that kind of leverage.
|
| Basically less of the vendor leverage bubbling down to normal end
| user owners of hardware.
| HstryrsrBttn wrote:
| At the end of the day: who cares that IBM wasn't able for
| whatever reason to supply a open CPU?
|
| If they fail to reliable provide that: sadly shows how weak that
| platform is
|
| Without any commitment to a future openness that can rapidly
| become an expensive cul-de-sac for anyone willing to develop for
| it.
| mbarbar wrote:
| >And if simple humanpower really was the reason IBM took
| shortcuts
|
| Is this referring to the closed blobs on Power10? Is there
| anywhere to read more?
|
| And is there any indication Power11 won't suffer the same?
| Someday POWER9 won't cut it for performance...
| monocasa wrote:
| The blobs on POWER10 as I remember were firmware for the memory
| sticks themselves since it used OMI to talk to the DIMMs, and
| IBM had to get third party OMI<->DDRX controllers. I see why
| they could have reason to believe that situation could change.
| superkuh wrote:
| Power11 is good, but doesn't it also use a novel serial RAM
| interface with closed proprietary firmware? This is less in the
| way than proprietary mobo firmware, but for purists, or those
| with extraordinary needs, it may still be an issue.
| ChuckNorris89 wrote:
| _> By the way, don't expect AMD to act any better. Remember that
| they're the company bringing you Pluton: quoted from the article,
| "Pluton will also prevent people from running software that has
| been modified without the permission of developers." It wouldn't
| be surprising to see AMD's Platform Security Processor pick up
| additional lock-in capabilities to reinforce this and other
| vendor controls._
|
| So the title should be Intel _and_ AMD are getting worse.
| loeg wrote:
| The whole thing is wild speculation.
| agumonkey wrote:
| I'll be so happy to drop advanced processors and go back to
| esp32 / risc-v based machines running my tiny OS and my tiny
| lisp repl
| mjg59 wrote:
| I've seen literally zero evidence that the assertion that
| Pluton will prevent you running modified software is true.
| based2 wrote:
| https://arstechnica.com/information-technology/2022/01/pluto...
| ohazi wrote:
| All of this complexity that's being added to lock a system down,
| purportedly in the name of "security" is actually being done for
| control by the vendor, at the expense of control by the user.
| Microsoft wants an enforceable walled garden just like Apple's.
|
| The increased attack surface that all this brings, implemented in
| a way that's opaque and non-removable, makes me incredibly
| nervous. You think cars and IoT devices are insecure? We're going
| to end up with that level of danger baked into every PC on the
| planet.
| Animats wrote:
| _You think cars and IoT devices are insecure? We 're going to
| end up with that level of danger baked into every PC on the
| planet._
|
| Tolerance for that among business customers may have just
| decreased substantially due to the current war.
| slaymaker1907 wrote:
| I thought this was initially FUD, but this in particular sounds
| bad. TPMs really do enhance security since it massively
| increases the security for even weak passwords (which 90-95% of
| them are). However, any security feature should be zero cost
| such that if you don't use it/want it, it doesn't restrict what
| you can do.
|
| Secure Boot at least can be disabled most of the time and that
| is one of the most locked down features.
|
| Random tangent: I really wish we had a better way to customize
| code signing and verification. For very sensitive environments,
| you should be able to only trust certain certs/roots for
| particular binaries. I'd like to enforce that for some
| particular python script, it has been signed by one of *my* CI
| servers. Obviously this is possible, but I think you would need
| to roll your own code.
| salawat wrote:
| Secure boot can only be disabled on x86/_64 systems. It is
| decreed that ARM systems not be user deactivatable.
| my123 wrote:
| This only applies to the (dead) Windows RT and Windows
| Phone/10 Mobile platforms.
|
| Windows on Arm64 devices are regular Windows desktop
| devices, just running on a different CPU architecture. As
| such, they share the same security policies.
|
| You can disable UEFI Secure Boot just fine on a Surface Pro
| X, and use custom keys there too. This also applies for
| devices from other OEMs.
| oneplane wrote:
| Let's make that a bit more specific:
|
| Microsoft wants OEMs that manufacture Windows on ARM
| devices to not allow a user to disable secure boot and not
| allow a user to add CAs or trust individual certificates.
| In essence, they want secure boot to not be subvertible.
|
| This is both good and bad: for the generic end-user, not
| being able to 'accidentally' disable root-of-trust via
| secure boot and not being able to have 'tech savvy nephews'
| try to 'help' them (and not overseeing the long term
| consequences) is a net win. It's going to be pretty hard to
| rootkit a system that has a secured root-of-trust. On the
| other hand, the device is now worthless the second the OEM,
| ODM or Microsoft decides they don't want to support it.
| They also completely control all features, so even if it
| would be hardware-capable of doing something you simply
| aren't going to be able to do it.
|
| There is a third aspect and that is that it is very hard to
| inspect the device as a researcher. Knowing that closed
| chassis debugging is a point of vulnerability, it would be
| great if it was still possible to boot a research OS and
| check the device. At this point, you can only do that with
| reverse-engineered drivers and a shim loader and hoping the
| CA in the firmware is up-to-date enough to contain a trust
| relation for the intermediate CA used to sign the shim
| certificate...
| littlecranky67 wrote:
| Please refer only to iOS as a walled garden. I can easily
| install Windows and Linux (natively) on my Macbooks, and this
| is not more cumbersome as on a regular PC (disabling Secure
| Boot). With the Apple Silicon its not that easy, but mostly
| because there are just not mature-enough drivers (Linux) or no
| interest by the manufacturer (Windows). macOS is also not very
| locked-down - yes you might need to disable some security
| feature and reboot to install certain kernel modules, but this
| is nothing out of the ordinary. I can still run kernel-level
| code without jailbreaking/rooting the hardware on Macintoshs.
| kavalg wrote:
| True, but you can't deny that Microsoft has moved a lot into
| the direction of walled garden / cloud based recently. I
| don't have the feeling that I own my PC as much as I did in
| the past (e.g. Windows 7).
| comex wrote:
| > I can still run kernel-level code without
| jailbreaking/rooting the hardware on Macintoshs.
|
| Only if you're willing to accept the loss of Apple Pay via
| Touch ID as well as the entire iOS-apps-on-Mac feature. It's
| been years since Apple allowed you to run kernel-level code
| without losing features.
| littlecranky67 wrote:
| > iOS-apps-on-Mac feature
|
| Can you elaborate what you mean here? Maybe I missed
| something, but Apple does not provide any iOS-apps-on-Mac
| feature? Except of course for/through their development
| tools, but no Appstore thingy or alike.
| amake wrote:
| Yes, you missed something.
|
| https://machow2.com/run-ios-apps-mac/
|
| Edit: In case you prefer a first-party source:
|
| https://developer.apple.com/documentation/apple-
| silicon/runn...
| littlecranky67 wrote:
| No, I didn't. The first link is a 3rd party software
| (iMazing) and the second is a developer guide how to
| develop an App in a way that it will also run on macOS
| without recompilation. Also note, that just because that
| software exists that checks if the the system is run
| outside of secure mode and then refuses to run, that
| doesn't make the system a "walled garden". There is a
| whole class of Software that has been doing this for
| ages, it's called Anti-Cheat Software and mostly home to
| Windows.
| userbinator wrote:
| The ISA is really irrelevant for these discussions on freedom.
| Once it gets popular for long enough, companies will start
| putting in these hostile features. x86, RISC-V, ARM, POWER,
| whatever. They all started out without the "security". I could
| just as easily imagine an alternative world where "Power11 gets
| worse, but Intel might get better" or any other combination.
|
| Related: https://news.ycombinator.com/item?id=29273829
___________________________________________________________________
(page generated 2022-02-27 23:00 UTC)