Mailbox property tag 0x00030010 (RPI_FIRMWARE_EXECUTE_CODE) is insecure

[ptesarik]

The RPI_FIRMWARE_EXECUTE_CODE tag allows executing arbitrary code on the VPU. Since the VPU can read and write all physical memory, this API can be abused for privilege escalation.

This call should be removed, or at least made configurable at boot (off by default).

[lategoodbye]

I agree and think that the Linux firmware driver should also reject such requests.

[popcornmix]

We can't remove it as it's currently used by a large number of pi users (e.g. for accelerated hevc decode). We could add an option for disabling it for user's who don't require it and would prefer more security.

Is disabling it when using the cutdown firmware okay? (gpu_mem=16) Would an additional config.txt option be preferable?

[lategoodbye]

Regarding the firmware, i would prefer an additional config.txt option. But is 0x00030010 really the only insecure property tag? I think it doesn't make sense to introduce options for every single property.

[dp111]

PiTubeDirect bare metal project uses this tag and the cutdown firmware (gpu_mem=16).

On Tue, 21 May 2019 at 14:08, Stefan Wahren notifications@github.com wrote:

Regarding the firmware, i would prefer an additional config.txt option. But is 0x00030010 really the only insecure property tag? I think it doesn't make sense to introduce options for every single property.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1140?email_source=notifications&email_token=AEVVFIQLX7XE3NGYTC3TW4DPWPX47A5CNFSM4HNWZ2ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV33CNY#issuecomment-494383415, or mute the thread https://github.com/notifications/unsubscribe-auth/AEVVFIUTQ24FQHMPV56J7XDPWPX47ANCNFSM4HNWZ2ZA .

[popcornmix]

SET_EXECUTE_CODE/SET_EXECUTE_QPU/SET_EXECUTE_MULTI are the only ones I see that could provide security holes through the mailbox interface.

GET_PERIPH_REG/SET_PERIPH_REG only allow access to AXI bus monitors (statistic counters) which aren't accessible from arm, so shouldn't be a problem.

There are others that can crash the chip (clocks and power), but I don't see a security issue.

[ptesarik]

For the upstream kernel, I would recommend not exposing the raw /dev/vcio interface, but instead add an abstraction layer in the kernel that implements a useful and secure subset of the available features. I don't have a precise idea yet how the userspace API should look like.

[lategoodbye]

For the upstream kernel, I would recommend not exposing the raw /dev/vcio interface, but instead add an abstraction layer in the kernel that implements a useful and secure subset of the available features. I don't have a precise idea yet how the userspace API should look like.

From my side there are currently no plans to upstream such firmware related driver.

[Terminus-IMRC]

/dev/vcio is only exposed to root user and video group by default on Raspbian, so it's secure if you correctly manage the permission and the group.

We're also the one who uses QPU as an accelerator and want /dev/vcio not to be removed. Although we can write a driver or use /dev/mem or Eric Anholt's mesa driver (experimental), we prefer an official driver which is widely used.

[ptesarik]

@Terminus-IMRC, I'm afraid your opinion is not quite correct.

First, users may want to limit video group privileges, and this is a non-obvious “backdoor” that must be closed. But then it is impossible to decouple root privileges from the use of hardware-accelerated HEVC decoding.

Second, the issue goes deeper. The firmware tries to protect some interfaces even from the Linux kernel, but the mailbox interface can be used to circumvent any such protection. I personally do not care (I believe the Linux kernel should have full control of the hardware), but if RPF offers e.g. locking customer OTP settings (see Industrial Use), then this issue must be solved in the firmware.

[lategoodbye]

@Terminus-IMRC The reason why i do not plan to upstream vcio and the others are not security related. We still have 3 vchiq driver in staging, so this must be handled first.

I never intended to remove /dev/vcio from the RPF tree, but i do see little chance for /dev/vcio to get upstreamed.

[Terminus-IMRC]

Thanks for replies. I get the point that some users want to use /dev/vcio just for video encoding/decoding.

@lategoodbye This question is not related to this issue, but do you have any plan to upstream /dev/vcsm after upstreaming vchiq?

[lategoodbye]

To be honest, i dislike driver which are bound to closed-source firmware, so i'm not really motivated. This is a job for someone who get paid for such a work.

[6by9]

@Terminus-IMRC

This question is not related to this issue, but do you have any plan to upstream /dev/vcsm after upstreaming vchiq?

/dev/vcsm (https://github.com/raspberrypi/linux/tree/rpi-4.19.y/drivers/char/broadcom/vc_sm) is being deprecated and replaced with https://github.com/raspberrypi/linux/tree/rpi-4.19.y/drivers/staging/vc04_services/vc-sm-cma with the aim of removing/significantly reducing the gpu_mem allocation heap. It is also used by the V4L2 M2M codec driver which we will be looking at upstreaming when time allows.

[Terminus-IMRC]

Thanks, will have a look.