cvs commit: src/sys/dev/uart uart_core.c
xcllnt at mac.com
Wed Mar 28 21:53:30 UTC 2007
On Mar 28, 2007, at 2:19 PM, Ben Kaduk wrote:
> On 3/28/07, Marcel Moolenaar <marcel at freebsd.org> wrote:
>> marcel 2007-03-28 18:26:12 UTC
>> FreeBSD src repository
>> Modified files:
>> sys/dev/uart uart_core.c
>> When we match UARTs found during bus-enumeration with UARTs used
>> system devices (i.e. console, debug port or keyboard), don't stop
>> after the first match. Find them all and keep track of the last.
>> The reason for this change is that the low-level console is always
>> added to the list of system devices first, with other devices added
>> later. Since new devices are added to the list at the head, we have
>> the console always at the end. When a debug port is using the same
>> UART as the console, we would previously mark the "newbus" UART as
>> a debug port instead of as a console. This would later result in a
>> panic because no "newbus" device was associated with the console.
>> By matching all possible system devices we would mark the "newbus"
>> UART as a console and not as a debug port.
>> While it is arguably better to be able to mark a "newbus" UART as
>> both console and debug port, this fix is lightweight and allows
>> a single UART to be used as the console as well as a debug port
>> with only the aesthetic bug of not telling the user about it also
>> being a debug port.
> I am rather ignorant about such things, but is there any security risk
> in having an "undocumented" debug port?
There's no security issue. The user/administrator has to configure
the machine and/or kernel before there will be a UART-based debug
port. The kernel will announce when uart is used as a debug port.
There's just a particular case when the uart port in question will
not announce that it's the debug port.
xcllnt at mac.com
More information about the cvs-src