Are you talking about the management engine? Has that been proven to allow this type of access where they can enable the webcam or microphone without user permission?
I need to look into this it sounds like. I’ve heard people say it can enable back door access, but it’s only been rumors and hypotheticals based on its access rights. If it can for example enable your webcam without any type of notification it’s happening that would be very concerning.
I’ve heard people say it can enable back door access, but it’s only been rumors and hypotheticals based on its access rights.
Out of curiosity, how is your knowledge?
If it can for example enable your webcam without any type of notification it’s happening that would be very concerning.
From a theoretical standpoint, given that it apparently has access to the same physical memory, all that would be needed is to know the correct memory addresses to read a single frame from.
How the kernel allocates that and maps it appropriately is both driver-specific and OS-specific.
Technically speaking, it could be that there are specific pools of physical addresses reserved for such things. The vram for an integrated card has at least a portion which is typically shared, so that’s worth taking into account as well, because the boundaries could be device specific or standard specific.
I’d personally have to research more myself, but if we’re operating off of Murphy’s law, then I’d wager that, yes, it’s very possible. Perhaps even if your kernel module for the camera driver is disabled by the host OS.
It’s certainly possible that the IME lane access is restricted in terms of what IO will be considered valid, but given that it isn’t documented, and given that it runs a multitasking, Unix-OS…that alone says a lot. Maybe not enough to be certain, but a lot.
Previously it was running an RTOS. So, you have constant time tasks. Now that it isn’t running an RTOS, there has to be a reason. Maybe it’s designed to aid branch prediction - if it is, though, then it probably has access to the instructions that are being executed by the host CPU. If that’s the case, then that implies that there are restrictions in the page mapping mechanism with respect to what physical addresses can be virtually mapped - assuming any protection at all.
Both Intel and AMD have backdoors created in their chips.
Are you talking about the management engine? Has that been proven to allow this type of access where they can enable the webcam or microphone without user permission?
Yes, IME.
It can read from your memory. It has access to the PCI bus. It runs in ring -3. Apparently it also runs MINIX.
It can operate without you being aware of what it’s doing.
So, yes.
I need to look into this it sounds like. I’ve heard people say it can enable back door access, but it’s only been rumors and hypotheticals based on its access rights. If it can for example enable your webcam without any type of notification it’s happening that would be very concerning.
Out of curiosity, how is your knowledge?
From a theoretical standpoint, given that it apparently has access to the same physical memory, all that would be needed is to know the correct memory addresses to read a single frame from.
How the kernel allocates that and maps it appropriately is both driver-specific and OS-specific.
Technically speaking, it could be that there are specific pools of physical addresses reserved for such things. The vram for an integrated card has at least a portion which is typically shared, so that’s worth taking into account as well, because the boundaries could be device specific or standard specific.
I’d personally have to research more myself, but if we’re operating off of Murphy’s law, then I’d wager that, yes, it’s very possible. Perhaps even if your kernel module for the camera driver is disabled by the host OS.
It’s certainly possible that the IME lane access is restricted in terms of what IO will be considered valid, but given that it isn’t documented, and given that it runs a multitasking, Unix-OS…that alone says a lot. Maybe not enough to be certain, but a lot.
Previously it was running an RTOS. So, you have constant time tasks. Now that it isn’t running an RTOS, there has to be a reason. Maybe it’s designed to aid branch prediction - if it is, though, then it probably has access to the instructions that are being executed by the host CPU. If that’s the case, then that implies that there are restrictions in the page mapping mechanism with respect to what physical addresses can be virtually mapped - assuming any protection at all.
You see where I’m going with this?