linux-kernel - Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

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] [day] [month] [year] [list]

Message-ID: <18c884cb-dd73-09eb-65da-604cf45cb1b4@daynix.com>
Date:   Fri, 2 Dec 2022 03:14:41 +0900
From:   Akihiko Odaki <akihiko.odaki@...nix.com>
To:     Hector Martin <marcan@...can.st>,
        Mark Kettenis <mark.kettenis@...all.nl>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, asahi@...ts.linux.dev,
        krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
        alyssa@...enzweig.io, sven@...npeter.dev
Subject: Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

On 2022/12/02 2:46, Hector Martin wrote:
> On 02/12/2022 01.38, Akihiko Odaki wrote:
>>   >> In contrary, if you boot the kernel without the hypervisor
>>   >> feature and this change, you will completely lose the console.
>>   >
>>   > How so? The console goes to both places with stdout-path set to serial0.
>>   > What it *does* change is where input is accepted prior to getty startup
>>   > (which is why u-boot specifically conditions this on keyboard presence,
>>   > modulo the USB issue - because if you *don't* have a keyboard then tty
>>   > keyboard input is useless). But if you're booting kernels without u-boot
>>   > along the way, you're probably doing it from the hypervisor or linux.py
>>   > anyway, especially if you plan to do something like "init=/bin/sh",
>>   > because without u-boot (+ optionally some EFI loader) there is no way of
>>   > editing command line arguments at boot time stand-alone.
>>
>> Well, that is not exactly the behavior I saw. In my case, if stdout-path
>> is pointed to serial, there is no output on the framebuffer, and it just
>> printed "_".
>>
>> It looks like the kernel only outputs to either of serial and
>> framebuffer, not both.
> 
> That is not what I've seen in all of my hypervisor runs since the dawn
> of time. You get log output on both.
> 
>> What I experienced is that when I directly booted the kernel from m1n1
>> without hypervisor, it showed no output to the display even though the
>> same kernel worked with U-Boot. While I could tell it used wrong console
>> by running the hypervisor, I wondered why it behaves differently without
>> U-Boot, and found the aforementioned U-Boot change, coming up with this
>> patch.
> 
> Then it sounds like something else is different about our setups,
> because I've booted the kernel from linux.py hundreds of times and I get
> output on both. Looking through the console code, the VT console gets
> added and enabled really early, and the subsequent serial console
> registration later does not disable it.
> 
> Look for "console: colour dummy device 80x25". It should be immediately
> followed by "printk: console [tty0] enabled", and this should all come
> well before the ttySAC0 serial stuff shows up.
> 
> - Hector

I think I understand the situation now. By "console", I was meaning the 
input and output of init, but I failed to clarify that and you thought 
it referring to kernel message output. I saw no messages earlier than 
init because my kernel command line has loglevel=3.

Regards,
Akihiko Odaki