similar to: retpoline mitigation and 6.0

Displaying 20 results from an estimated 3000 matches similar to: "retpoline mitigation and 6.0"

2018 Feb 03
0
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > >> On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: >> > >> > I saw the retpoline mitigation landed in r323155. Are we ready to >> > merge this to 6.0, or are
2018 Feb 03
4
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: > > > > I saw the retpoline mitigation landed in r323155. Are we ready to > > merge this to 6.0, or are there any open issues that we're waiting > > for? Also, were there any followups I should know about? Also,
2018 Feb 03
0
retpoline mitigation and 6.0
On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: > > I saw the retpoline mitigation landed in r323155. Are we ready to > merge this to 6.0, or are there any open issues that we're waiting > for? Also, were there any followups I should know about? Also, > release notes please :-) Eep, please can we keep the command line option for clang and the thunk ABI
2018 Feb 03
1
retpoline mitigation and 6.0
On 02/02/2018 04:27 PM, Chandler Carruth wrote: > On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org <mailto:dwmw2 at infradead.org>> wrote: > > On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev
2018 Feb 01
0
retpoline mitigation and 6.0
There was one open issue that i landed the fix for today. I was letting bots clear out before i ping you with the patch series to merge. On Thu, Feb 1, 2018 at 1:11 AM Hans Wennborg <hans at chromium.org> wrote: > Hi all, > > I saw the retpoline mitigation landed in r323155. Are we ready to merge > this to 6.0, or are there any open issues that we're waiting for? Also,
2018 Feb 03
0
retpoline mitigation and 6.0
On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote: > > Two aspects to this... > > One, we're somewhat reluctant to guarantee an ABI here. At least I > am. While we don't *expect* rampant divergence here, I don't want > this to become something we cannot change if there are good reasons > to do so. We've already changed the thunks once based on
2018 Feb 03
2
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:59 PM David Woodhouse <dwmw2 at infradead.org> wrote: > > > On Sat, 2018-02-03 at 00:51 +0000, Chandler Carruth wrote: > > While you *can* export your external thunk, that's a choice of the code > defining the thunk. > > > The driving force in the kernel is to be able to runtime patch the thunks > away, when running on a CPU or in a
2018 Feb 03
0
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 5:56 PM Guenter Roeck <linux at roeck-us.net> wrote: > On 02/02/2018 04:27 PM, Chandler Carruth wrote: > > On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com > <mailto:chandlerc at google.com>> wrote: > > > > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org > <mailto:dwmw2 at
2018 Feb 03
2
retpoline mitigation and 6.0
On Fri, Feb 2, 2018 at 4:36 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote: > > > > Two aspects to this... > > > > One, we're somewhat reluctant to guarantee an ABI here. At least I > > am. While we don't *expect* rampant divergence here, I don't want > > this to become
2018 Feb 07
3
retpoline mitigation and 6.0
On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > That would be __x86_indirect_thunk but the kernel doesn't use it. > > We use -mindirect-branch-register and only ever expect the compiler > > to use the register versions which are CET-compatible. > > > > However, in at least one case in the 32-bit kernel we do emit the > > old
2018 Feb 03
0
retpoline mitigation and 6.0
On Sat, 2018-02-03 at 00:51 +0000, Chandler Carruth wrote: > While you *can* export your external thunk, that's a choice of the > code defining the thunk. The driving force in the kernel is to be able to runtime patch the thunks away, when running on a CPU or in a mode that doesn't need them. We really want to have central implementations and have everything use them. > >
2018 Feb 07
0
retpoline mitigation and 6.0
On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > > > > That would be __x86_indirect_thunk but the kernel doesn't use it. > > > We use -mindirect-branch-register and only ever expect the compiler > > > to use the register versions which are
2018 Feb 07
2
retpoline mitigation and 6.0
Also, could you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing
2018 Feb 07
2
retpoline mitigation and 6.0
On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote: > On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com > > wrote: > > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org > > > wrote: > > > At this point, what we really want is for identical thunks to > > > have identical names — just like we do for
2018 Feb 03
0
retpoline mitigation and 6.0
On Sat, 2018-02-03 at 01:08 +0000, Chandler Carruth wrote: > > Sure, I can see why for the kernel, this is important. It also gets > to essentially define its ABI however it wants. > > For our other users, they specifically don't want this in the ABI > (because they actually have DSOs and other junk being linked > together). And yes, we actually have a decent number of
2018 Feb 07
0
retpoline mitigation and 6.0
The patch is up for review here: https://reviews.llvm.org/D42998 On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com> wrote: > Also, could you patch and test Clang with the Linux kernel after I make > this change? I'd like to know that we actually successfully call the > correct thunks and that they behave correctly. I'm not super worried, but >
2018 Feb 09
2
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > For now I'm just going to attempt to work around it like this in the > kernel, so I can concentrate on the retpoline bits: >  http://david.woodhou.se/clang-percpu-hack.patch 32-bit doesn't boot. Built without CONFIG_RETPOLINE and with Clang 5.0 (and the above patch) it does. I'm rebuilding a Release build of
2018 Feb 07
0
retpoline mitigation and 6.0
On Tue, Feb 6, 2018 at 4:32 PM David Woodhouse <dwmw2 at infradead.org> wrote: > > > On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote: > > On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > > At this point, what we
2018 Feb 07
4
retpoline mitigation and 6.0
On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Tue, 2018-02-06 at 22:08 +0000, Chandler Carruth wrote: > > So, I was waiting to hear a definitive response on whether using aliases > is hard, and didn't see one here, which is why I haven't responded further. > > However, a colleauge pointed me at an LKML thread where it seems
2018 Feb 09
0
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 02:21 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse wrote: > > > > > > For now I'm just going to attempt to work around it like this in the > > kernel, so I can concentrate on the retpoline bits: > >  http://david.woodhou.se/clang-percpu-hack.patch > > 32-bit doesn't boot. Built without