linux-kernel - Re: Decoding an oops

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: <CAO+szGvTSy5m6d219X3=i+mXgEVTfaLYKtgXESEKJu8TDZXBGA@mail.gmail.com>
Date:   Mon, 7 Oct 2019 21:11:45 +0100
From:   Francis M <fmcbra@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Decoding an oops

On Mon, 7 Oct 2019 at 20:38, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, Oct 7, 2019 at 7:58 AM Francis M <fmcbra@...il.com> wrote:
> >
> > Attached is a JPEG of what I've been able to capture from the console.
> > I'm guessing it's probably not enough to go on, but hoping someone
> > might have an 'ahh, that looks familiar' moment.
>
> That is an awkwardly small snippet and not showing any of the real
> oops state at all (the code/rip dump is actually the user space state
> at the time of the system call that then causes the problem).

I was pretty sure it'd turn out to be worthless, cheers for
confirming ;)

> Can you make your VM use a bigger terminal so that it shows more of
> the oops? Assuming your virtual environment supports the usual VESA
> VGA modes, it might be as easy as just booting with "vga=775" to get a
> 1280x1024 console.

I forgot about the old VGA mode parameters. Have had trouble
(read: zero luck) getting a high-res console for this VM from grub
through to kernel boot since it was provisioned, but I'll give the
above a shot once I've got the disc images safely backed up.

Have gleaned a small nugget more of stack which might help
down the road if this turns out to be VirtualBox-specific: I'm
reliably seeing "vbg_*" (drivers/virt/vboxguest/) stack frames
very early in the oops but they're scrolling way too fast for me
to snap a photo with my mobile. Maybe stack corruption,
maybe not. Pretty sure the VM is using mainline vboxguest.

Anyway, I'll try and glean as much info as I can with vga= and /
or delayed "printk()".

Should note in case the Oracle devs see this, this is a Win 10 Pro
host, 2019 Core i7, running VirtualBox 6.x. I'll haul this bug 'report'
upstream if further analysis points to vboxguest.

Cheers,
Francis