From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Steven J . Hill" <Steven.Hill@imgtec.com>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
linux-kernel@vger.kernel.org,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] MIPS: fw: Gracefully handle unknown firmware protocols
Date: Mon, 26 Aug 2024 14:17:39 +0100 [thread overview]
Message-ID: <8c49fec9-2afc-44ca-aebc-d08ae0d11305@app.fastmail.com> (raw)
In-Reply-To: <87o75gy85b.fsf@miraculix.mork.no>
在2024年8月25日八月 下午3:44,Bjørn Mork写道:
> "Jiaxun Yang" <jiaxun.yang@flygoat.com> writes:
>> 在2024年8月24日八月 下午3:41,Bjørn Mork写道:
>>> Boards based on the same SoC family can use different boot loaders.
>>> These may pass numeric arguments which we erroneously interpret as
>>> command line or environment pointers. Such errors will cause boot
>>> to halt at an early stage since commit 056a68cea01e ("mips: allow
>>> firmware to pass RNG seed to kernel").
>>>
>>> One known example of this issue is a HPE switch using a BootWare
>>> boot loader. It was found to pass these arguments to the kernel:
>>>
>>> 0x00020000 0x00060000 0xfffdffff 0x0000416c
>>>
>>> We can avoid hanging by validating that both passed pointers are in
>>> KSEG1 as expected.
>>
>> Hi Bjorn,
>>
>> This is actually breaking 64 bit systems passing fw_args in XKPHYS or KSEG0.
>
> Ouch. Thanks for the feedback.
>
> But if so, then aren't those already broken with the current test
> against CKSEG0? I didn't add that.
>
Ah my bad. My impression was it is possible to pass args in XKPHYS with
existing infra (and some PMON bootloader is doing that) but it turns out that
capability was somehow dropped when I was migrating various platforms to
fw_init_cmdline.
Feel free to propose a patch and go with valid_fw_arg, it's always good to have
robust generic implementation for validating stuff.
In long term we may need to clean up this as Maciej suggested, but IMO going through
jungle of platforms is not a feasible task for casual contributors.
Thanks
--
- Jiaxun
next prev parent reply other threads:[~2024-08-26 13:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-24 14:41 [PATCH] MIPS: fw: Gracefully handle unknown firmware protocols Bjørn Mork
2024-08-25 12:50 ` Jiaxun Yang
2024-08-25 13:56 ` Maciej W. Rozycki
2024-08-25 14:44 ` Bjørn Mork
2024-08-25 15:18 ` Maciej W. Rozycki
2024-08-25 15:47 ` Bjørn Mork
2024-08-25 19:59 ` Maciej W. Rozycki
2024-08-26 8:52 ` Bjørn Mork
2024-08-26 13:17 ` Jiaxun Yang [this message]
2024-08-28 22:15 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c49fec9-2afc-44ca-aebc-d08ae0d11305@app.fastmail.com \
--to=jiaxun.yang@flygoat.com \
--cc=Steven.Hill@imgtec.com \
--cc=bjorn@mork.no \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox