From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3078 invoked from network); 4 Jan 2024 21:21:33 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 4 Jan 2024 21:21:33 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2694E43EF8; Fri, 5 Jan 2024 07:21:31 +1000 (AEST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by minnie.tuhs.org (Postfix) with ESMTPS id E4BBF43EF7 for ; Fri, 5 Jan 2024 07:21:26 +1000 (AEST) Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2cca8eb0509so11394461fa.3 for ; Thu, 04 Jan 2024 13:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704403282; x=1705008082; darn=tuhs.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fXUlC8rdu1X09QmddGT4uZtCXYsBGWRv+sYJiOWSeeE=; b=SHm6Ob7dPNeSHh1AoJsdmQU6eTh58ptt/bZAd1Tp/nHVO3HAQ6IJ1VXmMSnicTowHn CTYHQu7gYrU1rYIxCCV3tWe/5VRxZSNG0hStvDm8Hsc9JljPMbvIiTy9YY+OTozHfP0Z M3uN69gdizLrtvEHXlyaNQRJOkwMrj8JCEciyJ+f3jbQvGdusdqDD2YeWH8BLj0aJCGk zgTKtdtAPDXyxWaB7l2ZCXBI6eC2JXBF6GfVMtywuResIroL2x0I/hxLFMTTMb25Gbu4 jewcGsFs4bPP4e26l9eSDfdTeSiJfEBfLYyRxlrae1yQbTT7WPUR+J/2xM09g4akChTC YkAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704403282; x=1705008082; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fXUlC8rdu1X09QmddGT4uZtCXYsBGWRv+sYJiOWSeeE=; b=woQwaDRMJ5u2UY4LnaLiOyrNz3jS5+pScnF1YT9q6AaeHoniYXqHu3XAE/VpIj0aAe II5QnEA0L03BonYnl/ZBsXerx4RBkZrUxMO0m3YfaUQunPcFcVrNJKbYIMYd5OAt4xi7 9ANXc/Z8h/1qn3gh0cT4KAf5bwcywqSuJwnXwyuIZrBhX+S/8p3VsfBCypLhc29CMXnW 7nCZTVLvySmNRK3G6XXJMtvwsjOKsc1iddbTFfkNG7zwvXKHjTM/mx3ZJt5cEproH6wn xAIuy6oOdY4LxEuvQJBioBb1u9Nl9YvRFPall2b3GYScKyo4TaB2L5Lj5UV+LS6ANwPO NyvQ== X-Gm-Message-State: AOJu0Yy205Jbwkw1mYhtGmFXkC9g9edVYBnmZQ2p4s406AM+3qmztDsM 0UGE2gslD3ledyYjVPOGrjHdhMmfRruq0hyhDWU= X-Google-Smtp-Source: AGHT+IGeoP5tdANvbrNlXxx/sG7brSDRw2accx6fEq3Jhrl7yIWmejuJgyHa8LsWWB5RNVVb9kBcabqBz42IlhLg9fE= X-Received: by 2002:a2e:904c:0:b0:2cc:d490:28b9 with SMTP id n12-20020a2e904c000000b002ccd49028b9mr556907ljg.5.1704403281277; Thu, 04 Jan 2024 13:21:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dan Cross Date: Thu, 4 Jan 2024 16:20:44 -0500 Message-ID: To: segaloco Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: LALJQHE3GKO36CPQDWNUPRAS5527WLGR X-Message-ID-Hash: LALJQHE3GKO36CPQDWNUPRAS5527WLGR X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: COFF X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Intel ME, UEFI, User Control was Re: Question about BSD disklabel history List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Jan 4, 2024 at 2:20=E2=80=AFPM segaloco via COFF wr= ote: > [TUHS bcc, moved to COFF] > > On Thursday, January 4th, 2024 at 10:26 AM, Kevin Bowling wrote: > > For whatever reason, intel makes it difficult to impossible to remove > > the ME in later generations. > > Part of me wonders if the general computing industry is starting to cheat= off of the smartphone sector's homework, this phenomenon where whole criti= cal components of a hardware device you literally own are still heavily con= trolled and provisioned by the vendor unless you do a whole bunch of tinker= ing to break through their stuff and "root" your device. That I can fully = pay for and own a "computer" and I am not granted full root control over th= at device is one of the key things that keeps "smart" devices besides my wo= rk issued mobile at arms length. > > For me this smells of the same stuff, they've gotten outside of the lane = of *essential to function* design decisions and instead have now put in a "= feature" that you are only guaranteed to opt out of by purchasing an entire= ly different product. In other words, the only guaranteed recourse if a CP= U has something like this going on is to not use that CPU, rather than as t= he device owner having leeway to do what you want. Depends on the vendor r= eally, some give more control than others, but IMO there is only one level = of control you give to someone who has bought and paid for a complete devic= e: unlimited. Anything else suggests they do not own the device, it is a p= ermanently leased product that just stops requiring payments after a while,= but if I don't get the keys, I don't consider myself to own it, I'm just b= orrowing it, kinda like how the Bell System used to own your telephone no m= atter how many decades it had been sitting on your desk. > > My two cents, much of this can also be said of BIOS, UEFI, anything else = that gets between you and the CPUs reset vector. Is it a nice option to ha= ve some vendor provided blob to do your DRAM training, possibly transition = out of real mode, enumerate devices, whatever. Absolutely, but it's nice a= s an *option* that can be turned off should I want to study and commit to d= oing those things myself. I fear we are approaching an age where the only = way you get reset vector is by breadboarding your own thing. I get wanting= to protect users from say bricking the most basic firmware on a board, but= if I want to risk that, I should be completely free to do so on a device I= 've fully paid for. For me the key point of contention is choice and conse= nt. I'm fine having this as a selectable option. I'm not fine with it bec= oming an endemic "requirement." Are we there yet? Can't say, I don't run = anything serious on x86-family stuff, not that ARM and RISC-V don't also ha= ve weird stuff like this going on. SBI and all that are their own wonderfu= l kettle of fish. We've been there for a while. I've been swimming in these waters for a couple of years now, and it _is_ an issue. That said, I can kind of sympathize with the vendors to an extent; they're between a rock and a hard place in a lot of ways. Starting up a modern CPU (even one in an end-user device like a phone or a laptop) is, I imagine, a bit like starting the engines on a container ship. You don't just press a switch and have massive two-story diesel pistons start firing in enormous cylinders; instead, you push a switch which starts an electric motor which turns on something like a V8 engine, which starts up a larger engine that starts the process of compressing the big pistons so the thing can start; it's a slow, multi-stage process out of physical necessity. Modern CPUs follow a similar process: you apply power to a board and it's going to do all sorts of stuff like power sequencing for DIMM sockets, asking them what's there, whether they're working properly, etc. Then there's turning on thermal sensors, the IO bus, flash, etc. A slew of internal diagnostics are going to run across a number of components. And all of this is happening before you even begin bringing the CPU socket online, let alone allowing the CPUs to come out of reset. And most of this is going to be done with FPGAs or little rinky-dink microcontrollers embedded in various places (an interesting exercise might be trying to count the number of CPUs on a modern mainboard): and that's not even counting the CPUs on IO devices. Most of those aren't just hidden, they're invisible to anyone other than the device manufacturer. Even if I had the documentation and the means to replace the images in those disparate components, it'd be a daunting task from a time/reward perspective. Most of the time, it's just not possible. How did we get here? Well, in part because systems are a lot more complex now than they were in the past, and that has reflected itself back onto software. The reality is that, for most users, even those who care about what software they run, most of this stuff just isn't that _interesting_. We care what runs on the x86 CPU (or whatever) sure, but how many people even _know_ about the little CPU embedded in their USB flash stick? So there's little incentive for the software vendors to put a lot of effort into supporting this stuff, and so it falls on board vendors, who just do what they've got to do to ship a product. I've mentioned the Oxide architecture before: we have no UEFI and we have no BIOS. We also designed our own custom boards. At Oxide, we build a service processor board based on an ARM Cortex-M profile microcontroller that runs its own OS that we built in-house most of the pre-CPU-poweron tasks. And yet, there are still some things that we can't get away from (firmware on peripherals, and the aforementioned PSP). The PSP is an interesting case in point; even if we _wanted_ to bypass it entirely, we can't; it's built into the CPU SoC complex and it's just how the thing works. And we build the computers! Imagine the situation for a user of a commodity COTS system. > BTW sorry that's pretty rambly, the lack of intimate user control over es= pecially smart devices these days is one of the pillars of my gripes with m= odern tech. Only time will tell how this plays out. Unfortunately the gen= eral public just isn't educated enough (by design, not their own fault) on = their rights to really get a big push on a societal scale to change this. = People just want I push button I get Netflix, they'll happily throw all the= ir rights in the garbage over bread and circuses....but that ain't new... I think most people just want a computer (or phone, tablet, whatever) at all and the entire system has congealed (again, to use Roscoe's term) around the way that things are now. Even for those of us who don't like it, it's damned hard to change the status quo. - Dan C.