Announcement

Collapse
No announcement yet.

Intel Software Defined Silicon Planned For Integration In Linux 5.18

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by birdie View Post
    At the same time if it's controlled by software, "OMG, THE WORLD IS ENDING INTEL ARE BAD, I'VE BOUGHT IT ALL". Sorry, that's asinine.
    Dear birdie... please don't start...

    Comment


    • #32
      Originally posted by coder View Post
      Newsflash: a lot of CPUs are being sold with perfectly working cores or features that are disabled. This is only different in that it lets you enable them.
      This was true around 15 years ago when there was far fewer SKU's and people figured out how to enable those cores but nowadays this doesn't really happening because of how binning is done. There are a lot more SKU product lines so much so that there is a pretty much an SKU for whatever chip ends up being produced.

      Comment


      • #33
        Originally posted by coder View Post
        That sucks. I figured I'd buy a car with a smaller battery to save some weight, thereby increasing energy efficiency. Because I never drive more than 100 miles per day, unexpectedly. And for a long trip, I figure I could always get a rental or keep my existing gas car. Ideally, I'd be able to add and remove batteries as-needed.

        But, you're saying that I don't save any weight or any environmental impact. Huh.
        You do...Tesla does...in regards to their operations not having as much waste or having to toss out old batteries when people upgrade from low to high capacity. That's why they did that. They very quickly realized they were XKCD Standardizing their batteries which causes unnecessary waste. People upgrade and they (Tesla) have useless batteries sitting around.

        I wouldn't be too surprised if SDS is done from a similar point of view -- as fabs get better and better there are less and less failures which means that there are less and less high-end i7 failures to turn into i5's or i3's. While I can agree with...no, not agree...understand that from a legacy, we gotta keep on keeping on point of view, I 100% disagree with it from an ethical and waste standpoint.

        Other EV manufacturers, YMMV. I'm not 100% sure how they operate. I just know some of the Tesla models do that so you need to study up a bit. I wouldn't be that surprised if they all do that. It makes a lot of sense from a standardized parts point of view.

        Comment


        • #34
          Nice, hope they will offer an SDK for game developers so it can seamlessly tie this into microtransactions.

          Comment


          • #35
            Originally posted by discordian View Post
            Nice, hope they will offer an SDK for game developers so it can seamlessly tie this into microtransactions.
            EA: Buy loot boxes for a chance to unlock processor upgrades

            Comment


            • #36
              I personally believe this code should be tossed out of the kernel until Intel's method of locking out nonpaying users is cracked. This is actually MUCH worse than the software-castrated Tesla cars, because you cannot break out the soldering iron, wire cutters, wrenches etc and bypass the computer entirely.

              I would not pay any significant money for a Tesla as I oppose their business model, but suppose I inherited one? I would treat it as the 4-wheeled equivalent of an E-bike kit, requireing lots of work before I dared take it out on the road. Bypassing battery limitations (and refusal to charge without an Internet connection) should easy if you are charging at home: Build your own lithium ion charger for the voltage in question that is just a battery charger, and install direct-to-battery-cell connections to use with that charger. That is exactly how I bypass failing chargers in old cellphones, thus not replacing the phones as intended by their makers.

              The physical motor controller in an electric car is basically a scaled-up version of an e-bike's motor controller. When you have a locked-down, European-spec 15mph E-bike, you trash the controller and replace it with a cheap Chinese controller that sells for $40 and now the bike will do 22-25mph if using 36V. If it is 24V you also replace the battery with a 36 volt version. Tesla instead of speed limiting you privacy limits you but the principle is the same. You will need to isolate the low level motor controllers from the high level computer, and it is 100% certain you can save at least the MOSFETS. Might be possible to drive them as amplifiers from a much smaller controller, or control them with a Rasberry Pi, its GPIO pins, and some smaller transistors as preamps.

              This computer need do only two things: operate (most likely three-phase) brushless DC motor or motors in the normal mode, and operate them in the braking mode as well. Many e-bike controllers can do this, and a combination of one with the MOSFETS in a Tesla might work. For that matter, there are probably industrial motor controllers that could be dropped in off the shelf, and would connect to battery power, motor phase windings, throttle, brake, and perhaps a motor speed readout that a Rasberry Pi or similar could convert to a speedometer signal. Mechanical steering, hydraulic wheel brakes, standalone sound system, a Tablet running ~OSMAND offline for a navigation system.

              All this is possible because the hardware components (motor, gas pedal, battery, brakes) have unavoidable physical connections. Now let's look at doing this inside a CPU where the connections are grown in the silicon or plated on at the nanotech level. Can't use hour hands and physical tools. Has to be done with leaked keys, side channel attacks, the usual tactics. The best hardware level/firmware level/side channel attack reverse engineering experts seem to be able to essentially waterboard a processsor for its secrets, hopefully without killing it in the process. All this takes time, but hopefully less time than it takes your 2021 era CPU to die of electromigration. Problem is it takes a lot more skill to crack a locked CPU than it does to replace the computer and/or motor controllers in an electric car that is limited by the physics of how electric motors work.

              The NSA can do it, the MSS can do it, some of the best black hats can do it, and it only take ONE leak to kill the control over every chip sold and taken offline prior to the leak's publication date. A single pissed-off ex-employee can publish the keys and kill the whole mess. At least one of the HDCP hacks was based on leaked keys, and Secure Boot has been cracked at least once as well. If you are not a three-letter agency or an elite level hacker, treat this like buying one of Crapple's iphones: it's worth more when its old enough to be jailbroken because someone else cracked it for you.

              This sort of threat from CPU antifeatures that have to be waited out goes all the way back to the Pentium III, which by default exposed a CPU serial number intended for use with software "activation." Nobody trusted it, so soon all the BIOS makers introduced the option to disable it. Nobody had to wait long for that one either.

              Comment


              • #37
                Originally posted by Volta View Post
                we'll automagically take it from your CPU. Security is another thing that needs to be taken into account.
                Even if it can't be "revoked", they can still block you from renewing your subscription needed to keep or increase your present level of capability.

                Comment


                • #38
                  Originally posted by mdedetrich View Post
                  nowadays this doesn't really happening because of how binning is done. There are a lot more SKU product lines so much so that there is a pretty much an SKU for whatever chip ends up being produced.
                  That means nothing. Even if they bin chips, you often have the problem (especially as the manufacturing node matures) that more high-binned chips are being produced than they can sell in those product tiers. So, what happens is that more capable chips end up being artificially restricted and sold in a lower product tiers.

                  Typically, Intel Xeons (i.e. the big-socket ones) have just 2 die layouts. Every different SKU is created by disabling their capabilities, sometimes because of test failures but often not. For instance Skylake SP and Cascade Lake SP cores all have 2 AVX-512 FMAs per core. However, the lower tier chips are sold with only one enabled. So, don't try to tell me that most lower-end Xeon Silver models that already have a ton of cores disabled don't have enough working cores with 2 functional AVX-512 FMAs for them to have been enabled.

                  Anyway, we'll have to wait and see just what Intel does with this. It might be very revealing of just how high their yield rates are and just how much dark silicon people have been receiving that could've actually been used.

                  Comment


                  • #39
                    Thanks guys. Never had any intel CPU for 15+ years already, and never will.

                    Comment


                    • #40
                      Originally posted by Luke View Post
                      I personally believe this code should be tossed out of the kernel until Intel's method of locking out nonpaying users is cracked.
                      Well, then maybe you should study the Linux Kernel policies and find one this violates. IMO, once they let content copy-protection schemes be enabled via the kernel, it became really difficult to reject something like this.

                      And even if the Kernel didn't allow it, there are still ways around it. For instance, Intel could simply require you to do it via BIOS, certain hypervisors, or just a special bootable image. I also wonder if they can't piggyback on existing microcode management APIs, if they really had to.

                      Originally posted by Luke View Post
                      This is actually MUCH worse than the software-castrated Tesla cars, because you cannot break out the soldering iron, wire cutters, wrenches etc and bypass the computer entirely.
                      I wouldn't assume you can hack your car, either. Even if you can do it today, probably not tomorrow.

                      Originally posted by Luke View Post
                      I would not pay any significant money for a Tesla as I oppose their business model,
                      As skeevy420 said, it probably won't matter. They're leading a race to the bottom. About the only way out is when some manufacturer goes too far and consumers just don't buy it. ...but, there are enough people who are too cheap/poor to be very long-term focused. So, the better option is some kind of government regulation limiting what features can be licensed and the terms under which they're licensable.

                      Originally posted by Luke View Post
                      but suppose I inherited one? I would treat it as the 4-wheeled equivalent of an E-bike kit, requireing lots of work before I dared take it out on the road. Bypassing battery limitations (and refusal to charge without an Internet connection) should easy if you are charging at home: Build your own lithium ion charger for the voltage in question that is just a battery charger, and install direct-to-battery-cell connections to use with that charger.
                      Hacking a car could result in either causing it not to start, or simply throwing up warning flags that result in it failing annual motor vehicle inspections that I think exist in most areas.

                      Originally posted by Luke View Post
                      Might be possible to drive them as amplifiers from a much smaller controller, or control them with a Rasberry Pi,
                      I hope you don't get a memory error or kernel panic. That sure would suck if the rear wheel locked up on you in traffic! I'd at least use something with ECC memory and a true RTOS.

                      Originally posted by Luke View Post
                      The NSA can do it, the MSS can do it, some of the best black hats can do it, and it only take ONE leak to kill the control over every chip sold and taken offline prior to the leak's publication date.
                      Well, I'd imagine the main target will be server CPUs, where most customers won't use hacks. And they can also change the keys frequently enough that the impact of a few being leaked is minimal.

                      Originally posted by Luke View Post
                      A single pissed-off ex-employee can publish the keys and kill the whole mess.
                      Expect them to be tightly-controlled, to the point where very few have such access and Intel will know which employee leaked them and can sue them into oblivion.

                      Comment

                      Working...
                      X