linux-kernel - Re: [PATCH] workqueue: Fix an object aliasing bug with `work_data

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:	Wed, 25 May 2016 22:20:55 +0100
From:	"Maciej W. Rozycki" <macro@...tec.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Lai Jiangshan <jiangshanlai@...il.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] workqueue: Fix an object aliasing bug with
 `work_data_bits'

On Wed, 25 May 2016, Tejun Heo wrote:

> > Fix an aliasing issue causing a MIPS port build error:
> > 
> > In file included from include/linux/srcu.h:34:0,
> >                  from include/linux/notifier.h:15,
> >                  from ./arch/mips/include/asm/uprobes.h:9,
> >                  from include/linux/uprobes.h:61,
> >                  from include/linux/mm_types.h:13,
> >                  from ./arch/mips/include/asm/vdso.h:14,
> >                  from arch/mips/vdso/vdso.h:27,
> >                  from arch/mips/vdso/gettimeofday.c:11:
> > include/linux/workqueue.h: In function 'work_static':
> > include/linux/workqueue.h:186:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
> >   return *work_data_bits(work) & WORK_STRUCT_STATIC;
> >   ^
> 
> Umm... the kernel is built explicitly with -fno-strict-aliasing and
> it's not something individual archs can opt out.

 Hmm, good point, I had forgotten about it, it's been a while -- now I 
recall there was once quite a discussion about it, when GCC switched its 
default.

 However it's VDSO being built here, i.e. strictly speaking not a part of 
the kernel itself, and this uses specialised build recipes so as to make 
this code user-callable (PIC, among others).  Which is undoubtedly why the 
error triggers so rarely.  So I guess the way to sort this out is to stick 
an explicit `-fno-strict-aliasing' option along with `-fno-common' and 
some other stuff already present there.  Due to the arcana of MIPS ABIs 
this is unfortunately very fragile.

 I'll handle it with the MIPS port then.  Sorry to trouble you with a bad 
change, thanks for the advice, and please consider the patch withdrawn.

  Maciej