[RFC] Remote Management feature for non-server Dasharo Supported Hardware

[pietrushnic]

Question text

Are we interested in introducing something like https://microsoft.github.io/mu/dyn/mu_feature_dfci/DfciPkg/Docs/Dfci_Feature/

I'm not sure if in that context DCU is not reinventing the wheel. Of course assuming that something like DFCI is possible without Microsoft proprietary technology.

[SergiiDmytruk]

It seems to be designed to work like this:

1. You start Windows
2. You authorize
3. Start remote-control daemon (Windows Autopilot)
4. Connect to network
5. Somebody remotely sends commands to the daemon which eventually writes something to flash (probably via UEFI runtime services)
6. UEFI reads what was written, verifies signatures, applies changes (seems like there is an intermediate format)

DCU:

1. Take an image
2. Update it with variables
3. Flash it
4. Start your device

DCU approach seems more streamlined and using DfciPkg can make things more complicated. One probably needs to implement a setting provider and feed it provisioned settings somehow (new flash area?). Not sure if doing that is all that's needed, DFCI settings might use a different GUID or not integrate with UEFI variables at all.

[krystian-hebel]

@pietrushnic I think that are we interested? is too broad of a question. I'll try to split it in smaller, more directed questions. Note that I just glanced over what DFCI is so maybe some of my thoughts are wrong.

How many of Dasharo users would want it?

Most of platforms supported by Dasharo are personal devices. DFCI seems to be made for remotely managing a fleet of devices. There may be cases where this is actually used (e.g. company laptops), but I don't know how big chunk of our user base that is.

Does it add anything to the security?

Just adding remote management won't make the platform more secure. Most likely it would add new bugs, e.g. around network stack. I don't understand the argument of making the box more secure by remotely disabling PXE boot - in both cases some network stack must be used.

Who owns the configuration?

This may be due to my ignorance, but from https://github.com/microsoft/mu_feature_dfci/blob/main/DfciPkg/Docs/Scenarios/DfciScenarios.md#lifecycle it seems that amount of configuration provided by IT admin is limited with regard to other actors. Some people may wish to not put Microsoft in the middle (that's what MitM stands for, right? :upside_down_face: ) between the admin and devices. On the other hand, this takes the burden of maintaining configuration server from IT.

What are the requirements?

Listed in https://github.com/microsoft/mu_feature_dfci/blob/main/DfciPkg/Docs/Scenarios/DfciScenarios.md#microsoft-dfci-scenario-requirements:

• Windows edition better than Home https://learn.microsoft.com/en-us/windows/client-management/mdm/uefi-csp
• $8 (monthly?) https://www.microsoft.com/en-us/security/business/microsoft-intune-pricing
• What about other OSes?

---

Summing up, in my opinion the use cases of DFCI and what we envisioned for DCU are very different.

[pietrushnic]

Most of platforms supported by Dasharo are personal devices.

NovaCustom laptops in 3mdeb are used as a fleet, but we have no means of management. End users are not our ultimate target. We want to be attractive to enterprise customers, and if some form of remote management or provisioning is possible, we should consider that. I'm not saying that DFCI is the correct choice; it is just something I found interesting and something that is used in the wild.

Three to five business customers can easily exceed number can exceed DES numbers easily. We assume that <= 5 devices are for personal use.

Just adding remote management won't make the platform more secure.

Agree.

Some people may wish to not put Microsoft in the middle (that's what MitM stands for, right? 🙃 ) between the admin and devices.

Of course. We would definitely not follow such a design. The goal would be to integrate with open-source self-hostable solutions.

$8 (monthly?)

Per user per month.

Summing up, in my opinion the use cases of DFCI and what we envisioned for DCU are very different.

This does not invalidate the need for remote management for enterprises. So if not DFCI, then what?

P.S. This is not a high priority for now, but it can quickly become, and we should at least start some discussion regarding this topic, especially since I have been getting remote management questions many times. Also, please note we must consider client space (network appliances, laptops, desktops). Other market segments rely on BMC/DASH, etc.

[mkopec]

For configuring FW settings from within the OS, see: https://github.com/lenovo/thinklmi which is integrated into Linux and fwupd already, and is simpler in principle than DFCI

It's also supported by HP and Dell enterprise systems: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-firmware-attributes

[pietrushnic]

For configuring FW settings from within the OS, see: https://github.com/lenovo/thinklmi which is integrated into Linux and fwupd already, and is simpler in principle than DFCI

Very interesting and proven by the support of major vendors. I wonder what @krystian-hebel and @SergiiDmytruk would say about it.

[SergiiDmytruk]

From https://www.kernel.org/doc/html/latest/wmi/acpi-interface.html:

The ACPI WMI interface is a proprietary extension of the ACPI specification made by Microsoft to allow hardware vendors to embed WMI (Windows Management Instrumentation) objects inside their ACPI firmware.

It seems to require changes to ACPI (not sure which exactly) and modification of Linux driver to make it work. Or a separate Dasharo-specific driver as a module to utilize the functionality. M$ here again, but this looks better.

That said, the same can be achieved by just using efivar on command-line and no need for kernel or firmware modifications. This obviously doesn't address remote management part, but neither does sysfs interface on its own.

[mkopec]

I think the big difference between these and using plain efivar is that they allow password or certificate based authentication for setting security-related options

[pietrushnic]

@mkopec authenticated variables modification is baed X.509

[krystian-hebel]

It is possible to access authenticated variables using efivarfs, but the UEFI structures have to be manually crafted and dd-ed over, at least the last time I checked. It probably could be automated, but I never got to it.

[pietrushnic]

@krystian-hebel :thinking: did you review the extended version of Arch4021? Here I show how to do that using sbvarsign tool.