On Wed, Jan 24, 2018 at 03:03:48PM +0100, Jiri Kosina wrote:
> On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
>
> > > > I just thought since you were already using modversions in enterprise
> > > > distros already, that adding it there would be the simplest.
> > >
> > > The patch as-is
On Wed, Jan 24, 2018 at 03:03:48PM +0100, Jiri Kosina wrote:
> On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
>
> > > > I just thought since you were already using modversions in enterprise
> > > > distros already, that adding it there would be the simplest.
> > >
> > > The patch as-is
On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
> > > I just thought since you were already using modversions in enterprise
> > > distros already, that adding it there would be the simplest.
> >
> > The patch as-is introduces immediate modversion mismatch between
> > retpolined kernel and
On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
> > > I just thought since you were already using modversions in enterprise
> > > distros already, that adding it there would be the simplest.
> >
> > The patch as-is introduces immediate modversion mismatch between
> > retpolined kernel and
On Wed, Jan 24, 2018 at 10:56:49AM +0100, Jiri Kosina wrote:
> On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
>
> > But will Andi's patch work well for you? Adding a MODULE_INFO() tag to
> > every module?
>
> Yes, that would work -- all the modules that get built in tree, or out of
> tree
On Wed, Jan 24, 2018 at 10:56:49AM +0100, Jiri Kosina wrote:
> On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
>
> > But will Andi's patch work well for you? Adding a MODULE_INFO() tag to
> > every module?
>
> Yes, that would work -- all the modules that get built in tree, or out of
> tree
On Wed, Jan 24, 2018 at 11:32:00AM +1100, Kees Cook wrote:
> I've wanted this for a while (especially for the coming detected
> support for stack protector). Having more than just the clfags is, I
> think, important. We'd likely want to record the entire environment
> (compiler version, linker
On Wed, Jan 24, 2018 at 11:32:00AM +1100, Kees Cook wrote:
> I've wanted this for a while (especially for the coming detected
> support for stack protector). Having more than just the clfags is, I
> think, important. We'd likely want to record the entire environment
> (compiler version, linker
On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
> But will Andi's patch work well for you? Adding a MODULE_INFO() tag to
> every module?
Yes, that would work -- all the modules that get built in tree, or out of
tree but with retpolined compiler, would have that marker that could be
On Wed, 24 Jan 2018, Greg Kroah-Hartman wrote:
> But will Andi's patch work well for you? Adding a MODULE_INFO() tag to
> every module?
Yes, that would work -- all the modules that get built in tree, or out of
tree but with retpolined compiler, would have that marker that could be
On Wed, Jan 24, 2018 at 12:49:37AM +0100, Jiri Kosina wrote:
> On Tue, 23 Jan 2018, Andi Kleen wrote:
>
> > > Thanks for pointing this out, Andi. I've been just now writing more or
> > > less the same thing; ditching that and will reuse your patch instead.
> > >
> > > Why was the more aggresive
On Wed, Jan 24, 2018 at 12:49:37AM +0100, Jiri Kosina wrote:
> On Tue, 23 Jan 2018, Andi Kleen wrote:
>
> > > Thanks for pointing this out, Andi. I've been just now writing more or
> > > less the same thing; ditching that and will reuse your patch instead.
> > >
> > > Why was the more aggresive
On Wed, Jan 24, 2018 at 10:05 AM, Borislav Petkov wrote:
> On Tue, Jan 23, 2018 at 11:55:05PM +0100, Jiri Kosina wrote:
>> I think we should start recording CFLAGS the kernel has been compiled with
>> anyway; doesn't hurt and might come handy when debugging.
>>
>> /proc/version is
On Wed, Jan 24, 2018 at 10:05 AM, Borislav Petkov wrote:
> On Tue, Jan 23, 2018 at 11:55:05PM +0100, Jiri Kosina wrote:
>> I think we should start recording CFLAGS the kernel has been compiled with
>> anyway; doesn't hurt and might come handy when debugging.
>>
>> /proc/version is probably not
On Tue, 23 Jan 2018, Andi Kleen wrote:
> > Thanks for pointing this out, Andi. I've been just now writing more or
> > less the same thing; ditching that and will reuse your patch instead.
> >
> > Why was the more aggresive version (6cfb521ac0d5b) merged into Linus' tree
> > instead of that?
>
On Tue, 23 Jan 2018, Andi Kleen wrote:
> > Thanks for pointing this out, Andi. I've been just now writing more or
> > less the same thing; ditching that and will reuse your patch instead.
> >
> > Why was the more aggresive version (6cfb521ac0d5b) merged into Linus' tree
> > instead of that?
>
> Thanks for pointing this out, Andi. I've been just now writing more or
> less the same thing; ditching that and will reuse your patch instead.
>
> Why was the more aggresive version (6cfb521ac0d5b) merged into Linus' tree
> instead of that?
Greg prefered using modversions, and in the end
> Thanks for pointing this out, Andi. I've been just now writing more or
> less the same thing; ditching that and will reuse your patch instead.
>
> Why was the more aggresive version (6cfb521ac0d5b) merged into Linus' tree
> instead of that?
Greg prefered using modversions, and in the end
On Tue, 23 Jan 2018, Andi Kleen wrote:
> > Distros have always been in the situation "we let the external modules to
> > load, as it'll work when it comes to functionality, but then it's our
> > duty/responsibility to explain to 3rd parties that they *really* should
> > recompile". Mostly
On Tue, 23 Jan 2018, Andi Kleen wrote:
> > Distros have always been in the situation "we let the external modules to
> > load, as it'll work when it comes to functionality, but then it's our
> > duty/responsibility to explain to 3rd parties that they *really* should
> > recompile". Mostly
> Distros have always been in the situation "we let the external modules to
> load, as it'll work when it comes to functionality, but then it's our
> duty/responsibility to explain to 3rd parties that they *really* should
> recompile". Mostly because of security fixes to static inlines, but not
> Distros have always been in the situation "we let the external modules to
> load, as it'll work when it comes to functionality, but then it's our
> duty/responsibility to explain to 3rd parties that they *really* should
> recompile". Mostly because of security fixes to static inlines, but not
On Tue, 23 Jan 2018, Jiri Kosina wrote:
> So that vermagic patch doesn't really help anything in real world (FWIW
> I've just dropped it from SLE kernel). "Potentially insecure" doesn't mean
> it shouldn't be loaded if the user wishes so. Only "functionally
> incorrect" (which is the kernel
On Tue, 23 Jan 2018, Jiri Kosina wrote:
> So that vermagic patch doesn't really help anything in real world (FWIW
> I've just dropped it from SLE kernel). "Potentially insecure" doesn't mean
> it shouldn't be loaded if the user wishes so. Only "functionally
> incorrect" (which is the kernel
> > And it probably should be a more reliable method which we probably could
> > use to detect !retpolined modules too.
>
> Andi actually implemented this, but it ended up being watered down
> somewhat.
It's enforced in mainline with the following patch
It's not fully bullet proof, but should
> > And it probably should be a more reliable method which we probably could
> > use to detect !retpolined modules too.
>
> Andi actually implemented this, but it ended up being watered down
> somewhat.
It's enforced in mainline with the following patch
It's not fully bullet proof, but should
On Tue, Jan 23, 2018 at 11:55:05PM +0100, Jiri Kosina wrote:
> I think we should start recording CFLAGS the kernel has been compiled with
> anyway; doesn't hurt and might come handy when debugging.
>
> /proc/version is probably not the best place ... /proc/cflags?
Yap, I guess I can find that
On Tue, Jan 23, 2018 at 11:55:05PM +0100, Jiri Kosina wrote:
> I think we should start recording CFLAGS the kernel has been compiled with
> anyway; doesn't hurt and might come handy when debugging.
>
> /proc/version is probably not the best place ... /proc/cflags?
Yap, I guess I can find that
On Tue, 23 Jan 2018, Borislav Petkov wrote:
> > + mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_GENERIC :
> > +SPECTRE_V2_RETPOLINE_MINIMAL;
>
>
> but that might not always be an
On Tue, 23 Jan 2018, Borislav Petkov wrote:
> > + mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_GENERIC :
> > +SPECTRE_V2_RETPOLINE_MINIMAL;
>
>
> but that might not always be an
On Tue, 2018-01-23 at 23:40 +0100, Borislav Petkov wrote:
>
> Btw, this came up today: do we have an idea how to detect objects built
> with gcc which has retpoline support?
>
> The only way I could think of is boot the respective kernel and stare at
> dmesg:
>
> [ 0.064006] Spectre V2
On Tue, 2018-01-23 at 23:40 +0100, Borislav Petkov wrote:
>
> Btw, this came up today: do we have an idea how to detect objects built
> with gcc which has retpoline support?
>
> The only way I could think of is boot the respective kernel and stare at
> dmesg:
>
> [ 0.064006] Spectre V2
On Thu, Jan 11, 2018 at 09:46:26PM +, David Woodhouse wrote:
> Add a spectre_v2= option to select the mitigation used for the indirect
> branch speculation vulnerability.
>
> Currently, the only option available is retpoline, in its various forms.
> This will be expanded to cover the new
On Thu, Jan 11, 2018 at 09:46:26PM +, David Woodhouse wrote:
> Add a spectre_v2= option to select the mitigation used for the indirect
> branch speculation vulnerability.
>
> Currently, the only option available is retpoline, in its various forms.
> This will be expanded to cover the new
Add a spectre_v2= option to select the mitigation used for the indirect
branch speculation vulnerability.
Currently, the only option available is retpoline, in its various forms.
This will be expanded to cover the new IBRS/IBPB microcode features.
The RETPOLINE_AMD feature relies on a
Add a spectre_v2= option to select the mitigation used for the indirect
branch speculation vulnerability.
Currently, the only option available is retpoline, in its various forms.
This will be expanded to cover the new IBRS/IBPB microcode features.
The RETPOLINE_AMD feature relies on a
36 matches
Mail list logo