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 for Android: free password hash cracker in your pocket

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

Message-ID: <647b6572-e5d1-d243-283e-616cef15a1f5@marcan.st>
Date:   Fri, 2 Dec 2022 02:46:11 +0900
From:   Hector Martin <marcan@...can.st>
To:     Akihiko Odaki <akihiko.odaki@...nix.com>,
        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 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