On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada
wrote:
> Sorry for chiming in late.
>
> I noticed this thread today,
> honestly, the commit made me upset.
>
>
> Can I suggest another way to make it less fragile?
> __attribute((...)) can be placed after 'struct'.
>
>
> So, we can write:
>
>
> struc
On Mon, Mar 5, 2018 at 1:27 AM, Masahiro Yamada
wrote:
>
> Can I suggest another way to make it less fragile?
> __attribute((...)) can be placed after 'struct'.
That avoids the actual bug, but it wouldn't have helped _find_ the
problem in the first place.
If somebody ever does the same thing, th
Hi Linus,
2018-02-22 7:47 GMT+09:00 Linus Torvalds :
> On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero
> wrote:
>>
>> One can see that offsets used to access various members of struct path are
>> different, and also that the original file from step 3 contains an object
>> named "__randomize_
On Wed, Feb 21, 2018 at 4:23 PM, Kees Cook wrote:
> On Wed, Feb 21, 2018 at 4:22 PM, Linus Torvalds
> wrote:
>> On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote:
>>>
>>> Do you want me to send the patch for this, or do you already have it
>>> prepared?
>>
>> I'd rather get something explicitly t
On Wed, Feb 21, 2018 at 4:22 PM, Linus Torvalds
wrote:
> On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote:
>>
>> Do you want me to send the patch for this, or do you already have it
>> prepared?
>
> I'd rather get something explicitly tested. I tried my earlier patch
> with "make allmodconfig" (a
On Wed, Feb 21, 2018 at 4:12 PM, Kees Cook wrote:
>
> Do you want me to send the patch for this, or do you already have it
> prepared?
I'd rather get something explicitly tested. I tried my earlier patch
with "make allmodconfig" (and a fix to nfsd to make it compile), but
now I'm back to testing
On Wed, Feb 21, 2018 at 3:24 PM, Linus Torvalds
wrote:
> On Wed, Feb 21, 2018 at 2:52 PM, Kees Cook wrote:
>>
>> I'll play with Linus's suggestion and see what we get.
>
> It may be just as well to just include from
> and be done with it.
Hah, yeah, that would certainly solve it too. :)
> I d
On Wed, Feb 21, 2018 at 2:47 PM, Linus Torvalds
wrote:
> And other attribute specifiers we encourage people to put in other
> parts of the type, like __user etc, so they don't have that same
> parsing issue.
Looking at other attributes we use on structs, we may have similar
risks for these:
__pa
On Wed, Feb 21, 2018 at 2:52 PM, Kees Cook wrote:
>
> I'll play with Linus's suggestion and see what we get.
It may be just as well to just include from
and be done with it.
If you look at that hacky script I documented in commit 23c35f48f5fb
("pinctrl: remove include file from ") and run it i
On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero
wrote:
> One can see that offsets used to access various members of struct path are
> different, and also that the original file from step 3 contains an object
> named "__randomize_layout".
>
> This is caused by a fact that the current version o
On Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero
wrote:
>
> One can see that offsets used to access various members of struct path are
> different, and also that the original file from step 3 contains an object
> named "__randomize_layout".
Whee.
Thanks for root-causing this issue, and this
On 18.11.2017 06:14, Kees Cook wrote:
> On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote:
>> On 2017-11-17 04:55 PM, Linus Torvalds wrote:
>>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote:
I am still getting the crash at d9e12200852d, I figured I would
double-check th
On Fri, Nov 17, 2017 at 9:29 PM, Linus Torvalds
wrote:
> On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook wrote:
>>
>> FWIW, myself doing a build at d9e12200852d with and without
>> GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output
>> where I did spot-checks.
>
> That would probably b
On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook wrote:
>
> FWIW, myself doing a build at d9e12200852d with and without
> GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output
> where I did spot-checks.
That would probably be a good thing to check anyway - check the
difference between GCC
On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote:
> On 2017-11-17 04:55 PM, Linus Torvalds wrote:
>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote:
>>>
>>> I am still getting the crash at d9e12200852d, I figured I would
>>> double-check the "good" and "bad" kernels before starting a
On 2017-11-17 04:55 PM, Linus Torvalds wrote:
> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote:
>>
>> I am still getting the crash at d9e12200852d, I figured I would
>> double-check the "good" and "bad" kernels before starting a full bisect.
>
> .. but without GCC_PLUGIN_RANDSTRUCT it's
On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote:
>
> I am still getting the crash at d9e12200852d, I figured I would
> double-check the "good" and "bad" kernels before starting a full bisect.
.. but without GCC_PLUGIN_RANDSTRUCT it's solid?
Kees removed even the baseline "randomize pure fu
On 2017-11-17 01:26 PM, Kees Cook wrote:
> On Fri, Nov 17, 2017 at 11:03 AM, Patrick McLean wrote:
>> On 2017-11-16 04:54 PM, Kees Cook wrote:
>>> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote:
On 2017-11-11 09:31 AM, Linus Torvalds wrote:
> Boris Lukashev points out that Patrick
On Fri, Nov 17, 2017 at 11:03 AM, Patrick McLean wrote:
> On 2017-11-16 04:54 PM, Kees Cook wrote:
>> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote:
>>> On 2017-11-11 09:31 AM, Linus Torvalds wrote:
Boris Lukashev points out that Patrick should probably check a newer
version of
On 2017-11-16 04:54 PM, Kees Cook wrote:
> On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote:
>> On 2017-11-11 09:31 AM, Linus Torvalds wrote:
>>> Boris Lukashev points out that Patrick should probably check a newer
>>> version of gcc.
>>>
>>> I looked around, and in one of the emails, Patrick
On Mon, Nov 13, 2017 at 2:48 PM, Patrick McLean wrote:
> On 2017-11-11 09:31 AM, Linus Torvalds wrote:
>> Boris Lukashev points out that Patrick should probably check a newer
>> version of gcc.
>>
>> I looked around, and in one of the emails, Patrick said:
>>
>> "No changes, both the working and
On Tue, Nov 14, 2017 at 3:53 PM, Rasmus Villemoes
wrote:
>
> Odd. 7.2 and 7.1 (both of which I've just compiled from source, no
> special configure flags or anything) generate exactly the same (good)
> code for fs/namespace.o after patching. I also tried with
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y just i
On 14 November 2017 at 23:43, Linus Torvalds
wrote:
> On Tue, Nov 14, 2017 at 2:24 PM, Rasmus Villemoes
> wrote:
>>
>> Can you be more specific? That's not what I see with gcc 7.1.
>
> I have gcc-7.2.1, and it made a horrible mess of the do_mount() code.
Odd. 7.2 and 7.1 (both of which I've just
On Tue, Nov 14, 2017 at 2:24 PM, Rasmus Villemoes
wrote:
>
> Can you be more specific? That's not what I see with gcc 7.1.
I have gcc-7.2.1, and it made a horrible mess of the do_mount() code.
Look for the comment "/* Separate the per-mountpoint flags */" and do
the obvious conversion of the sim
On 14 November 2017 at 00:54, Linus Torvalds
wrote:
> On Mon, Nov 13, 2017 at 3:30 PM, Linus Torvalds
> wrote:
>>
>> So let's just rewrite that mnt_flags conversion that way, justr to get
>> gcc to generate the obvious code.
>
> Oh wow. I tried to do the same thing in fs/namespace.c where it does
On Mon, Nov 13, 2017 at 3:30 PM, Linus Torvalds
wrote:
>
> So let's just rewrite that mnt_flags conversion that way, justr to get
> gcc to generate the obvious code.
Oh wow. I tried to do the same thing in fs/namespace.c where it does
the reverse bit translation, and gcc makes a _horrible_ mess o
On Mon, Nov 13, 2017 at 2:59 PM, Rasmus Villemoes
wrote:
>> Sadly, gcc makes a mess of it and actually generates code that looks
>> like the original C.[...]
>
> Actually, new enough gcc (7.1, I think) does contain a pattern that does
> this, but unfortunately only if one spells it
>
> y |= (x &
On Thu, Nov 09 2017, Linus Torvalds wrote:
> The code disassembles to
>
>0: 83 c9 08 or $0x8,%ecx
>3: 40 f6 c6 04 test $0x4,%sil
>7: 0f 45 d1 cmovne %ecx,%edx
>a: 89 d1mov%edx,%ecx
>c: 80 cd 04 or $0
On 2017-11-11 09:31 AM, Linus Torvalds wrote:
> Boris Lukashev points out that Patrick should probably check a newer
> version of gcc.
>
> I looked around, and in one of the emails, Patrick said:
>
> "No changes, both the working and broken kernels were built with
>distro-provided gcc 5.4.0
Boris Lukashev points out that Patrick should probably check a newer
version of gcc.
I looked around, and in one of the emails, Patrick said:
"No changes, both the working and broken kernels were built with
distro-provided gcc 5.4.0 and binutils 2.28.1"
and gcc-5.4.0 is certainly not very r
On Fri, Nov 10, 2017 at 6:36 PM, Linus Torvalds
wrote:
> [ Bringing in the gcc plugin people and the kernel hardening list,
> since it now is no longer even remotely looking like a nfsd, vfs or
> filesystem issue any more ]
>
> Kees, Emese,
> the whole thread is on lkml, but there's clearly somet
On Wed, 8 Nov 2017 16:43:17 -0800
Patrick McLean wrote:
> As of 4.13.11 (and also with 4.14-rc) we have an issue where when
> serving nfs4 sometimes we get the following BUG. When this bug happens,
> it usually also causes the motherboard to no longer POST until we
> externally re-flash the BIOS
[ Bringing in the gcc plugin people and the kernel hardening list,
since it now is no longer even remotely looking like a nfsd, vfs or
filesystem issue any more ]
Kees, Emese,
the whole thread is on lkml, but there's clearly something horribly
wrong with RANDSTRUCT, and it's not new even though i
On Fri, Nov 10, 2017 at 08:13:06PM -0500, J. Bruce Fields wrote:
> On Fri, Nov 10, 2017 at 03:26:27PM -0800, Patrick McLean wrote:
> >
> >
> > On 2017-11-10 10:42 AM, Linus Torvalds wrote:
> > > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean
> > > wrote:
> > >>
> > >> Something must have change
On Fri, Nov 10, 2017 at 03:26:27PM -0800, Patrick McLean wrote:
>
>
> On 2017-11-10 10:42 AM, Linus Torvalds wrote:
> > On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote:
> >>
> >> Something must have changed since 4.13.8 to trigger this though.
> >
> > Arnd pointed to some commits that migh
On 2017-11-10 03:26 PM, Patrick McLean wrote:
>
>
> On 2017-11-10 10:42 AM, Linus Torvalds wrote:
>> On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote:
>>>
>>> Something must have changed since 4.13.8 to trigger this though.
>>
>> Arnd pointed to some commits that might be relevant for the cp
On 2017-11-10 10:42 AM, Linus Torvalds wrote:
> On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote:
>>
>> Something must have changed since 4.13.8 to trigger this though.
>
> Arnd pointed to some commits that might be relevant for the cp210x
> module, but those are all already in 4.13.8, so i
On Thu, Nov 9, 2017 at 5:58 PM, Patrick McLean wrote:
>
> Something must have changed since 4.13.8 to trigger this though.
Well, yes and no.
Obviously something changed, but it doesn't necessarily have to be
anything particular.
Almost every time we've seen compiler bugs, it's been an innocuous
On Fri, Nov 10, 2017 at 2:58 AM, Patrick McLean wrote:
> On 2017-11-09 12:04 PM, Linus Torvalds wrote:
>> On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote:
>
> We will check our fork against the in-kernel cp201x driver to make sure
> we didn't miss anything, but it seems odd we would be hit
On 2017-11-09 12:04 PM, Linus Torvalds wrote:
> On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote:
>>
>> We do have CONFIG_GCC_PLUGIN_STRUCTLEAK and
>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled on these boxes as well as
>> CONFIG_GCC_PLUGIN_RANDSTRUCT as you pointed out before.
>
> It mi
On 2017-11-09 11:51 AM, Patrick McLean wrote:
> On 2017-11-09 11:37 AM, Al Viro wrote:
>> On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote:
>>
Here is the BUG we are getting:
> [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at
> 0230
>
On 2017-11-09 12:47 PM, J. Bruce Fields wrote:
> On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote:
>> Anyway, that cmovne noise makes it a bit hard to see the actual part
>> that matters (and that traps) but I'm almost certain that it's the
>> "mnt->mnt_sb->s_flags" loading that is
On Thu, Nov 09, 2017 at 12:04:19PM -0800, Linus Torvalds wrote:
> That case has probably not gotten a huge amount of testing. As Al
> points out, it can cause absolutely horrendous cache access pattern
> changes, but it might also be triggering some corruption in case
> there's a problem with the
On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote:
> Anyway, that cmovne noise makes it a bit hard to see the actual part
> that matters (and that traps) but I'm almost certain that it's the
> "mnt->mnt_sb->s_flags" loading that is part of calculate_f_flags()
> when it then does
>
>
On Thu, Nov 9, 2017 at 11:51 AM, Patrick McLean wrote:
>
> We do have CONFIG_GCC_PLUGIN_STRUCTLEAK and
> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL enabled on these boxes as well as
> CONFIG_GCC_PLUGIN_RANDSTRUCT as you pointed out before.
It might be worth just verifying without RANDSTRUCT in partic
On 2017-11-09 11:37 AM, Al Viro wrote:
> On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote:
>
>>> Here is the BUG we are getting:
[ 58.962528] BUG: unable to handle kernel NULL pointer dereference at
0230
[ 58.963918] IP: vfs_statfs+0x73/0xb0
>>
>> The
On 2017-11-09 11:38 AM, Al Viro wrote:
> On Thu, Nov 09, 2017 at 11:34:19AM -0800, Patrick McLean wrote:
>
>>> In particular, there are *no* nfsd changes in that 4.13.8..4.13.11
>>> range. There is a bunch of xfs changes, though. What's the underlying
>>> filesystem that you are exporting?
>>
>>
On Thu, Nov 09, 2017 at 11:34:19AM -0800, Patrick McLean wrote:
> > In particular, there are *no* nfsd changes in that 4.13.8..4.13.11
> > range. There is a bunch of xfs changes, though. What's the underlying
> > filesystem that you are exporting?
>
> It's an ext4 filesystem.
Had there been tool
On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote:
> > Here is the BUG we are getting:
> >> [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at
> >> 0230
> >> [ 58.963918] IP: vfs_statfs+0x73/0xb0
>
> The code disassembles to
> 2a:* 48 8b b7 30 0
On 2017-11-08 06:40 PM, Linus Torvalds wrote:
> On Wed, Nov 8, 2017 at 4:43 PM, Patrick McLean wrote:
>> As of 4.13.11 (and also with 4.14-rc) we have an issue where when
>> serving nfs4 sometimes we get the following BUG. When this bug happens,
>> it usually also causes the motherboard to no lo
On Wed, Nov 08, 2017 at 06:40:22PM -0800, Linus Torvalds wrote:
> > Here is the BUG we are getting:
> >> [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at
> >> 0230
> >> [ 58.963918] IP: vfs_statfs+0x73/0xb0
>
> The code disassembles to
>
>0: 83 c9 08
On Wed, Nov 8, 2017 at 4:43 PM, Patrick McLean wrote:
> As of 4.13.11 (and also with 4.14-rc) we have an issue where when
> serving nfs4 sometimes we get the following BUG. When this bug happens,
> it usually also causes the motherboard to no longer POST until we
> externally re-flash the BIOS (us
As of 4.13.11 (and also with 4.14-rc) we have an issue where when
serving nfs4 sometimes we get the following BUG. When this bug happens,
it usually also causes the motherboard to no longer POST until we
externally re-flash the BIOS (using the BMC web interface). If a
motherboard does not have an e
53 matches
Mail list logo
