Introduce serial driver for STM32F429

[georgekang]

Serial is a convenient tool to output log message in developing. It
is more friendly in using and can provide more data than original tools,
LED blinking and semihosting.

Serial now is only available on STM32F429 and its driver programs are
ported from mbed project. (https://github.com/mbedmicro/mbed.git)

Currently serial output can be enabled when the variable "SERIAL_DEBUG"
in Makefile of stm32f4/uvisor is set as "enable". Serial input is
not supported but we may need it for interactive interface in the future.

UART_4 is selected as default serial device with PC_10 as tx pin
and PC_11 as rx pin and the default baud rate is 115200.

[meriac]

Hi George,

we won't be able to accept this patch as it is. Here's some background on the intended future functionality of debug and debug messages in uVisor:

• uVisor is supposed to have as little as possible special knowledge about the target and it peripherals
• uVisor must still support complex debugging like over meshed wireless networks, IPv6 Ethernet with SSL or USB CDC serial.

Solution:

• Debug communication and debug LED handling will be moved into a uVisor box
• Whenever uVisor will print messages, it will issue a de-privileged call to the dedicated box that handles the output.
• whenever the remote system wants to communicate to uVisor, the debug box will call into uVisor to deliver just the payload.
• as a result uVisor does not need to know about complex protocols, but is still able to interact with remote systems in a debug session.
• the debug box might be able to debug other boxes if these boxes allow to do so (similar to Android where an app needs to explicitly allow debugging in its manifest)
• we stop uVisors attack surface from growing by reducing privileged code
• uVisors security properties are very comparable across a multitude of system: security verifications become transferable across systems

I am very much interested in your opinion on my suggestion. If you like it we'll add a ticket for delegation of debug and subsequently you could move your code into a deprivileged box.

@AlessandroA @jserv

[georgekang]

@meriac , thanks for your information.

According to your suggestion, the scenario of message printing for uVisor is very similar to interrupt handling. The total scenario could be as followings:

• Debug box registers print method in uVisor through syscall, UVISOR_SVC.
• When uVisor needs to print messages, it will issue a svc call to load debug box and then
  change to unprivileged mode to execute the print method registered before.
• Upon finishing the print method, uVisor will return to privileged mode
  through another svc call.

The last two steps are also used in isr multiplexer in interrupt handling to run the correct irq handler.
The behavior is almost the same and we can extend isr multiplexer to implement debugging in uVisor.

For other boxes which need to print messages, debug box could provide secure gateway for them to do this. In secure gateway, context switch can be triggered by svc call and the debug box will be loaded to handle the messages.

The only problem now is that the data which could be transferred by svc call is very limited. The easiest way is that only one character is transferred in each debugging request but it will be inefficient when there are a large number of messages to print out. There should be a mechanism like share memory to solve this problem.

I am very glad to discuss with you about this topic and appreciate more advice from you.

[meriac]

@georgekang for sending debug messages down to the unprivileged debug box:

• the box would accept data from a shared memory that is read-only for the debug-box and inaccessible from the other boxes
• from the debug box perspective it receives a pointer and length to a string
• the debug box does not need to distinguish between data from another box of from uvisor as a result

If you want, we can discuss the details of debug messages via a dedicated box. My Skype user name is "milosch.meriac".

[georgekang]

@meriac, thanks for your reply.

Here are my questions about debug box.

• for uVisor, it can store its messages to this shared memory directly, right?
• for other boxes, secure gateway is only the way they could use to send messages to debug box. According to the second term of your suggestion, the secure function would be like following

UVISOR_EXTERN void __secure_message_output(char *str, uint32_t len)
{
    ...
}

/* the gateway to the secure function */
void secure_message_output(char *str, uint32_t len)
{
    secure_gateway(debug_box_name, __secure_message_out, str, len);
}

It looks good but it also means debug box has the authority to access 'str'. Is it possible that the memory space of 'str' is inaccessible from debug box and memory fault would happen when debug box reads the data of 'str' in this situation?

My skype account is "georgekang03", and I have added your account in my Skype list. Maybe we can arrange meeting to discuss more details about the design of debug box.
Thanks.

[meriac]

@georgekang we have three options:

• for the main box this just magically works, as the main box memory is always accessible to all boxes
• for secure boxes, each box needs to allocate a shared memory that is accessible to the debug box
• additionally we'll add a putchar option across the secure boundary. Please notice that our printf-functions does not require buffers, instead it maps a print to a sequence of putchars. This means that no sharing of memory is required at higher cycle costs.

UVISOR_EXTERN void __secure_message_putc(char c)
{
    ...
}

/* the gateway to the secure function */
void secure_message_putc(char c)
{
    secure_gateway(debug_box_name, __secure_message_putc, c);
}

[meriac]

Please continue discussion at #70