Originally posted by birdie
View Post
Announcement
Collapse
No announcement yet.
Intel Software Defined Silicon Planned For Integration In Linux 5.18
Collapse
X
-
Originally posted by coder View PostNewsflash: 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.
Comment
-
Originally posted by coder View PostThat 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.
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
-
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
-
Originally posted by Volta View Postwe'll automagically take it from your CPU. Security is another thing that needs to be taken into account.
Comment
-
Originally posted by mdedetrich View Postnowadays 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.
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
-
Originally posted by Luke View PostI personally believe this code should be tossed out of the kernel until Intel's method of locking out nonpaying users is cracked.
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 PostThis 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.
Originally posted by Luke View PostI would not pay any significant money for a Tesla as I oppose their business model,
Originally posted by Luke View Postbut 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.
Originally posted by Luke View PostMight be possible to drive them as amplifiers from a much smaller controller, or control them with a Rasberry Pi,
Originally posted by Luke View PostThe 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.
Originally posted by Luke View PostA single pissed-off ex-employee can publish the keys and kill the whole mess.
- Likes 1
Comment
Comment