> the Remote Device Management baked into firmware as Apple does with its hardware?
What do you mean? Linux had SSH (and before that rlogin) for a very long time already.
> the Remote Device Management baked into firmware as Apple does with its hardware?
What do you mean? Linux had SSH (and before that rlogin) for a very long time already.
Apple devices support MDM. When you purchase the device, the device's firmware is configured to check in with an account owner. The firmware has an integrity feature such that this configuration cannot be removed by a user: https://it-training.apple.com/tutorials/deployment/dm005/
If OP just meant remote management through a BMC then that's not common except for server hardware, and it would have features like Redfish to configure the hardware itself. Apple devices don't have this.
You can also buy hardware to act as a remote keyboard/mouse/monitor and power button, and it supports systems whose motherboards have the right headers: https://pikvm.org/
I don't think it's fair to describe MDM as a firmware-level feature. I think it's entirely implemented and enforced within the environment of a booted macOS; the firmware isn't going to be bringing up a whole network stack to phone home.
If you had Linux on a MDM-enrolled Mac there wouldn't be anything MDM-related running during or after the boot process. But presumably any sane MDM config would prevent the end user from accessing the settings necessary to relax boot security to get Linux installed in the first place.
Yeah, your point about implementation is correct -- much of the MDM functionality runs within macOS.
But, eh, I still think it's fair to describe it as a feature of the firmware. The enrollment and prevention of removal have firmware-level components through Apple's Secure Boot and System Integrity Protection. A user can't simply disable MDM because these firmware-level protections prevent tampering with the enrollment.
Case in point, getting Linux installed in the first place would be blocked by firmware-level boot policies, right? I'm not too knowledge about this, and maybe you are more so.
I think it's important to make a distinction between secure boot features that are local-only, and remote management features. The "Remote Device Management baked into firmware" claim above carries with it some pretty important implications that are, as far as I can tell, not actually true.
It's not too different from scaremongering about Intel ME/AMT which is often maligned even in the context of computers that don't have the necessary Intel NICs for the remote management features.
I agree with your point about OP's statement regarding "where is not not needed Windows in any way, to the Remote Device Management baked into firmware as Apple does with its hardware" I also read that to mean that the firmware solution is self-contained and complete, even though that's pretty misaligned when you consider the meaning of a "remotely" managed device (remotely managed by what?).
But it's still entirely factual in my own description. When a device checks in during initial setup, the firmware-level boot process can receive policies that block alternative OS installation, and that absolutely is a feature of the firmware.
Anyway, I tried to interpret OP's meaning, and provided more detail on how Apple's firmware is special.
Do you think ssh is an equivalent to remote device management? Half the reason Chromebook does well is because it's really good at remote device management.
"Device Management" means "hardware-level backdoor."
Only if it's your hardware. If it's corporate hardware, it's their hardware and you're a guest.