linux-kernel - RE: [patch 13/18] x86, ds: add leakage warning

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E92718067@irsmsx504.ger.corp.intel.com>
Date:	Fri, 3 Apr 2009 07:42:08 +0100
From:	"Metzger, Markus T" <markus.t.metzger@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"tglx@...utronix.de" <tglx@...utronix.de>,
	"hpa@...or.com" <hpa@...or.com>,
	"markus.t.metzger@...il.com" <markus.t.metzger@...il.com>,
	"roland@...hat.com" <roland@...hat.com>,
	"eranian@...glemail.com" <eranian@...glemail.com>,
	"oleg@...hat.com" <oleg@...hat.com>,
	"Villacis, Juan" <juan.villacis@...el.com>,
	"ak@...ux.jf.intel.com" <ak@...ux.jf.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [patch 13/18] x86, ds: add leakage warning

>-----Original Message-----
>From: Ingo Molnar [mailto:mingo@...e.hu]
>Sent: Thursday, April 02, 2009 9:28 PM
>To: Metzger, Markus T
>Cc: tglx@...utronix.de; hpa@...or.com; markus.t.metzger@...il.com; roland@...hat.com;
>eranian@...glemail.com; oleg@...hat.com; Villacis, Juan; ak@...ux.jf.intel.com; linux-
>kernel@...r.kernel.org
>Subject: Re: [patch 13/18] x86, ds: add leakage warning
>
>
>* markus.t.metzger@...el.com <markus.t.metzger@...el.com> wrote:
>
>> +static inline void ds_warn_leak(struct task_struct *tsk)
>> +{
>> +	WARN(tsk->thread.ds_ctx, "leaking DS context\n");
>> +}
>
>> +	ds_warn_leak(tsk);
>
>since we normally expect X86_DS enabled i'd suggest this
>simplification: always have thread.ds_ctx around so the WARN_ON can
>go there unconditionally. (it wont trigger in the !DS case)

OK.


>>  struct task_struct;
>>  struct mm_struct;
>> +struct ds_context;
>
>why is this needed in processor.h?

This seems to be common practice.

The only thing we need here is a forward declaration in order to put a pointer
field into the thread_struct.

The same holds for sched.h, which uses bts_context. Since bts_context again has a pointer
to a task_struct, we would have circular dependencies, so either one needs a forward
declaration.

If I split ds.h into ds_types.h and ds_api.h, the only place where this could
be used would be processor.h. All the rest needs to include both - or, rather,
ds_api.h, which then includes ds_types.h.



>ds.h should be split into ds_types.h and ds_api.h, with the pure
>data type definitions in ds_types.h. processor.h (which needs to
>know about the DS context type) then includes ds_types.h - which
>is a lightweight header.
>
>Actual DS using facilities also disable ds_api.h.
>
>This keeps data types nicely separated from methods and inlines.
>
>	Ingo
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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