I think the MPH limit for ebike classification makes sense. But why do they need a 750W limit? Whats the harm in a motor putting out 3000W to get a loaded cargo bike up a steep hill at 8 MPH.
Doing some quick math, if your bike is using 3kw to climb a reasonably steep (15% grade) hill at 8mph, we can calculate the weight it must be carrying, which ends up being about 1,200lbs
To answer your question, the limit on motor power exists as a proxy for limiting the weight, speed, and acceleration of ebikes within safe limits, since having an ebike charging uphill at 20mph with 500lbs of payload would present actual safety risks. Trying to regulate payload/speed/slope combinations directly has practical problems (police officers don't really want to stop delivery drivers to weight their cargo), while regulating motor power is much simpler.
- The game obviously needs to run as root, at least until large amounts of this stuff gets upstreamed into the kernel.
- We're going to be leaving the kernel and boot as untrusted, but injecting a hypervisor underneath the running kernel that is responsible for protecting most pages of game memory. This allows users to still run whatever kernel they want.
- The hypervisor sets up two sets of page tables, one that's only active when the game's thread is running and in userspace, one that hides protected pages and is active when the kernel or other threads are running. Note that game code itself needs to get decrypted into protected ram.
- The TPM of the system gets involved when we jump into the hypervisor to attest that the hypervisor is actually running, and the hypervisor then provides attestations to userspace that certain memory regions are protected from kernel or other thread access.
- Any syscalls will fail if they require the kernel to read or write pages that are protected. The game needs to allocate data that should be shared with the kernel into non-protected pages.
- When the game is closed, we can remove the hypervisor and Linux will be back to bare metal operation. This should be unobservable to the rest of the system.
This architecture preserves the ability of users to run arbitrary kernel modules, but does mean a hypothetical attacker can observe data that passes through the kernel (like draw calls/pixels). It's likely that a more complete implementation would also want some way for the hypervisor to attest to the accuracy of keyboard/mouse input and interface with iommu configuration like Windows KAC does.