nouveau.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Ilia Mirkin <imirkin@alum.mit.edu>
To: Nick Lopez <nick@glowingmonkey.org>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>
Subject: Re: [Nouveau] Off-by-one or bad BIOS image? Apple eMac 800 GeForce 2MX
Date: Thu, 20 Jan 2022 13:24:02 -0500	[thread overview]
Message-ID: <CAKb7Uvi4+=7PTATZMh0vHcX8pg0FqR48r4_1MHphZKYQu1=hEw@mail.gmail.com> (raw)
In-Reply-To: <20220120181657.8E3BB10E684@gabe.freedesktop.org>

This stuff is always so confusing. Let's think this through.... if
bios size is 4, and we're trying to read a 4-byte thing starting at
address 0, that _ought_ to work, I think. So in my strawman case,
bios->size == 4, and size == 4. So we should only error if size >
bios->size, not if they're ==. Looks like your patch is right.

Want to make a linux kernel patch submission with this? (i.e.
including changelog, signoff, etc?)

Cheers,

  -ilia

On Thu, Jan 20, 2022 at 1:17 PM Nick Lopez <nick@glowingmonkey.org> wrote:
>
> Because I watch too much retro YouTube I decided it was a good idea to try installing Adelie Linux on my old G4/800 eMac, but the Live installer would freeze. By blacklisting nouveau I was able to get it booted and manually installed and, after hours and hours of compiling, get a working kernel tree to poke at. After only a few iterations with dump_stack() and nvkm_debug and the output of envytools/nvbios I worked out at the last initscript instruction was stored in the last byte of the ROM. I think the bounds check in the nvbios_addr() function is miscalculating the limit as one byte short, that’s why I was seeing this in the syslog:
>
>
>
> nouveau 0000:00:10.0: bios: OOB 1 000007b2 000007b2
>
> nouveau 0000:00:10.0: devinit: 0x000007b2[ ]: unknown opcode 0x00
>
> nouveau 0000:00:10.0: preinit failed with -22
>
> nouveau: DRM-master:00000000:00000080: init failed with -22
>
> nouveau 0000:00:10.0: DRM-master: Device allocation failed: -22
>
> nouveau: probe of 0000:00:10.0 failed with error -22
>
>
>
> After I changed the limit check from:
>
> if (unlikely(*addr + size >= bios->size)) {
>
> to:
>
> if (unlikely(*addr + size > bios->size)) {
>
>
>
> it initialized the card properly, brought up the fbconsole and even seems to be working in X with DRI. So the question is: was the bounds check wrong, or is the NVDA,BMP image provided by OpenFirmware truncated? I’m guess this doesn’t turn up elsewhere because the ROM images read through any of the other methods are the size of flash chip they’re stored on so there’s always unused space at the end and they never use the last byte where the NVDA,BMP provided by OpenFirmware is just the active section.
>
>
>
> The patch is against the Adelie easy-kernel patch 5.4 tree, but it looks like that code is still there in the current upstream torvalds/linux git.

  reply	other threads:[~2022-01-20 18:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19  7:27 [Nouveau] Off-by-one or bad BIOS image? Apple eMac 800 GeForce 2MX Nick Lopez
2022-01-20 18:24 ` Ilia Mirkin [this message]
2022-01-21  5:07   ` Nick Lopez
     [not found]   ` <2cc8f675-dec2-4640-88ab-b64dea2e3bc6@DM3NAM02FT036.eop-nam02.prod.protection.outlook.com>
2022-01-21  6:48     ` Ilia Mirkin

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='CAKb7Uvi4+=7PTATZMh0vHcX8pg0FqR48r4_1MHphZKYQu1=hEw@mail.gmail.com' \
    --to=imirkin@alum.mit.edu \
    --cc=nick@glowingmonkey.org \
    --cc=nouveau@lists.freedesktop.org \
    /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;
as well as URLs for NNTP newsgroup(s).