linux-kernel - Re: inode->i_wb

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]

Date:	Mon, 12 Mar 2012 17:06:52 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Dave Jones <davej@...hat.com>
Cc:	Yang Bai <hamo.by@...il.com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Fedora Kernel Team <kernel-team@...oraproject.org>,
	kernel@...arici.cz
Subject: Re: inode->i_wb_list corruption.

<#part sign=pgpmime>
On Mon, 12 Mar 2012 19:26:30 -0400, Dave Jones <davej@...hat.com> wrote:

> Thinking about how the GTT could contain stale pointers, I came up with this scenario:
> 
> Before we begin the thaw, the initramfs sets up a framebuffer.
> This causes the GTT to be setup.

Yes. The frame buffer is allocated as regular kernel pages, of course.

> - Thaw begins, hardware state still points to the GTT setup by the modesetting code.
>   At this point, any graphics operations are going to cause writes through
>   those translations. Bad news if we just wrote a bunch of thawed data
>   there.

The question is what data could still be pending there; we're running
just fbcon at that point, which uses only write-through
access. Presumably, any fbdev writes will have been long-since finished
once we start the new kernel.

> - Thaw begins, and data is written over the GTT setup by the initramfs, but 
>   the hardware registers still points at it, until thaw is complete, when we
>   reprogram the GTT registers to their pre-hibernate values.

I'm not sure how the new kernel could manage to do any writes through
this though -- it shouldn't touch the frame buffer until it has thawed
the video driver, right?

> If we could somehow set modeset=0 automatically if we detect a hibernate
> partition it would probably 'solve' it, but I suspect the real answer
> would be to do GTT teardown before we do a thaw.

We've got a ton of memory available in the 'stolen' area which the BIOS
used as a frame buffer; we should be able to switch to that before the
switch, if we decide that this is necessary.

-- 
keith.packard@...el.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/