linux-kernel - Re: [tip:x86/debug] x86/EFI: Properly init-annotate BGRT code

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Jan 2013 08:03:09 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	mingo@...nel.org, tglx@...utronix.de, mjg@...hat.com,
	linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [tip:x86/debug] x86/EFI: Properly init-annotate BGRT code

On Fri, Jan 25, 2013 at 07:45:42AM +0000, Jan Beulich wrote:
> >>> On 24.01.13 at 23:28, Josh Triplett <josh@...htriplett.org> wrote:
> > On Thu, Jan 24, 2013 at 12:34:21PM -0800, tip-bot for Jan Beulich wrote:
> >> Commit-ID:  13f0e4d2b9e2209f13d5a4122478eb79e6136870
> >> Gitweb:     
> > http://git.kernel.org/tip/13f0e4d2b9e2209f13d5a4122478eb79e6136870 
> >> Author:     Jan Beulich <JBeulich@...e.com>
> >> AuthorDate: Fri, 23 Nov 2012 16:30:07 +0000
> >> Committer:  Ingo Molnar <mingo@...nel.org>
> >> CommitDate: Thu, 24 Jan 2013 17:12:18 +0100
> >> 
> >> x86/EFI: Properly init-annotate BGRT code
> >> 
> >> These items are only ever referenced from initialization code.
> > 
> > Not true, and this patch will break the BGRT code.  bgrt_init, which
> > does indeed have an __init annotation, stores bgrt_image and
> > bgrt_image_size into the .private and .size fields of a sysfs
> > bin_attribute, which does *not* have an __initdata annotation, and which
> > will get read whenever the user reads the corresponding sysfs attribute.
> 
> Copying init-only data into a sysfs structure is no problem at all
> - that structure obviously is non-__initdata and hence can be
> read at any time. It was a different thing if .private and/or .size
> stored _pointers_ to one of the two variables in question.

Ah, I see; the data itself gets kmalloc'd, and you just want to discard
the original pointer and size.  Fair enough.  Sorry for the false alarm.

- Josh Triplett
--
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/