linux-kernel - Re: [PATCH v1] arch/x86: port I/O tracing on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc40a671-29f6-b897-1562-8dd48a01cbbf@foxvalley.net>
Date:   Thu, 21 Sep 2023 11:07:50 -0600
From:   Dan Raymond <draymond@...valley.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        hpa@...or.com
Subject: Re: [PATCH v1] arch/x86: port I/O tracing on x86

On 9/19/2023 4:43 PM, Dan Raymond wrote:
> On 9/19/2023 3:31 PM, Dan Raymond wrote:
>> On 9/19/2023 3:12 PM, Peter Zijlstra wrote:
>>>>> This means I can no longer use early_console->write() to print to my
>>>>> early_serial_console.
>>>>
>>>> Why not?  Did you try it?
>>>
>>> I have tried debugging the kernel for the last 15+ years. The only
>>> reliable way to get something out of the machine is outb on the serial
>>> port. Anything else is a waste of time..
>>>
>>> Adding tracing to it (which relies on RCU, which might not be alive at
>>> this point) which might itself be the problem, is a total no-go.
>>>
>>> You do not wreck early_serial_console.
>>
>> But you didn't try my patch to see if it "wrecks" early_serial_console.
>> I doubt it has any impact there because it does not get compiled into
>> boot code.  Notice the BOOT_COMPRESSED_MISC_H and BOOT_BOOT_H checks.
>>
>> I don't understand your general objection.  The kernel already has
>> tracing for memory mapped I/O which includes serial ports.  This patch
>> just extends that to include port I/O.
> 
> Another point: The tracing infrastructure uses RCU for management of
> trace buffers.  If you don't explicitly enable portio tracing nothing
> will get written to the trace buffers.  Nothing extra will be done
> during outb() except for a quick check to see that tracing is disabled.
> This check took only a few clock cycles on average during my testing.
> This should be fine even during early boot.

Tracing is enabled/disabled by modifying the code segment at runtime.
To demonstrate this point:

# grep do_trace_portio_write /proc/kallsyms
c13800d0 T do_trace_portio_write
c1915fd0 r __ksymtab_do_trace_portio_write
c19231b5 r __kstrtabns_do_trace_portio_write
c192ca4d r __kstrtab_do_trace_portio_write

# hexdump -C -s 0x013800d0 /dev/mem | head -1
013800d0  3e 8d 74 26 00 c3 8d b4  26 00 00 00 00 8d 76 00  |>.t&....&.....v.|

# echo 1 > /sys/kernel/tracing/events/portio/portio_write/enable
# hexdump -C -s 0x013800d0 /dev/mem | head -1
013800d0  e9 0b 00 00 00 c3 8d b4  26 00 00 00 00 8d 76 00  |........&.....v.|

Disassembling this shows what changed:

# echo "0: 3e 8d 74 26 00 c3" | xxd -r > a.out
# objdump -D -b binary -m i386
...
00000000 <.data>:
   0:   3e 8d 74 26 00          lea    %ds:0x0(%esi,%eiz,1),%esi
   5:   c3                      ret

# echo "0: e9 0b 00 00 00 c3" | xxd -r > a.out
# objdump -D -b binary -m i386
...
00000000 <.data>:
   0:   e9 0b 00 00 00          jmp    0x10
   5:   c3                      ret

The 'lea' instruction is a nop so when tracing is disabled this function
does nothing.  When tracing is enabled the 'jmp' instruction transfers
control past the 'ret' instruction to the tracing logic.