On Fri, Dec 08, 2017 at 08:38:26AM -0800, Andy Lutomirski wrote:
> 4. In an actual vma. I don't see the benefit of doing this at all --
> it's just like #2 except way more error prone. Hell, you have to make
> sure that you can't munmap or mremap it, which isn't a consideration
> at all with the
On Fri, Dec 8, 2017 at 9:37 AM, Thomas Gleixner wrote:
> On Fri, 8 Dec 2017, Andy Lutomirski wrote:
>> Can we take a step back here? I think there are four vaguely sane
>> ways to make the LDT work:
>>
>> 1. The way it is right now -- in vmalloc space. The only real
>> downside is that it requir
On Fri, 8 Dec 2017, Andy Lutomirski wrote:
> Can we take a step back here? I think there are four vaguely sane
> ways to make the LDT work:
>
> 1. The way it is right now -- in vmalloc space. The only real
> downside is that it requires exposing that part of vmalloc space in
> the user tables, w
From: Andy Lutomirski
> Sent: 08 December 2017 16:48
...
> I mean: if the user CS or SS is not accessed and the LDT is RO, then
> we get #PF on the IRET instruction, I think. Dealing with that is
> truly awful.
Any fault in-kernel on the IRET is horrid.
Doesn't really matter which one.
Same goes
On Fri, Dec 8, 2017 at 8:46 AM, David Laight wrote:
> From: Andy Lutomirski
>> Sent: 08 December 2017 16:34
>
>> #GP on IRET is a failure, and we have disgusting code to handle it.
>
> Is that the trap in kernel space when the on-stack segment registers
> are invalid?
> Definitely needs horrid cod
From: Andy Lutomirski
> Sent: 08 December 2017 16:34
> #GP on IRET is a failure, and we have disgusting code to handle it.
Is that the trap in kernel space when the on-stack segment registers
are invalid?
Definitely needs horrid code...
> #PF on IRET would not be a failure -- it's a case where I
On Fri, Dec 8, 2017 at 3:31 AM, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
>> On Fri, 8 Dec 2017, Ingo Molnar wrote:
>> > * Thomas Gleixner wrote:
>> >
>> > > On Fri, 8 Dec 2017, Ingo Molnar wrote:
>> > > > * Andy Lutomirski wrote:
>> > > > > I don't love mucking with user address space.
On Fri, Dec 8, 2017 at 6:06 AM, Peter Zijlstra wrote:
> On Fri, Dec 08, 2017 at 05:20:00AM -0800, Andy Lutomirski wrote:
>> >
>> > The error code of such an access is always 0x03. So I added a special
>> > handler, which checks whether the address is in the LDT map range and
>> > verifies that the
On Fri, Dec 08, 2017 at 03:06:54PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 08, 2017 at 05:20:00AM -0800, Andy Lutomirski wrote:
> > >
> > > The error code of such an access is always 0x03. So I added a special
> > > handler, which checks whether the address is in the LDT map range and
> > > ver
On Fri, Dec 08, 2017 at 05:20:00AM -0800, Andy Lutomirski wrote:
> >
> > The error code of such an access is always 0x03. So I added a special
> > handler, which checks whether the address is in the LDT map range and
> > verifies that the access bit in the descriptor is 0. If that's the case it
>
From: Andy Lutomirski
> Sent: 08 December 2017 13:20
...
> >> - It would also be a cleaner approach all around, and would avoid the
> >> fixmap
> >> complications and the scheduler muckery.
> >
> > The error code of such an access is always 0x03. So I added a special
> > handler, which checks wh
> On Dec 8, 2017, at 1:34 AM, Thomas Gleixner wrote:
>
>> On Fri, 8 Dec 2017, Ingo Molnar wrote:
>> * Andy Lutomirski wrote:
>>> I don't love mucking with user address space. I'm also quite nervous about
>>> putting it in our near anything that could pass an access_ok check, since
>>> we're
* Thomas Gleixner wrote:
> On Fri, 8 Dec 2017, Ingo Molnar wrote:
> > * Thomas Gleixner wrote:
> >
> > > On Fri, 8 Dec 2017, Ingo Molnar wrote:
> > > > * Andy Lutomirski wrote:
> > > > > I don't love mucking with user address space. I'm also quite nervous
> > > > > about
> > > > > putting
On Fri, 8 Dec 2017, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
>
> > On Fri, 8 Dec 2017, Ingo Molnar wrote:
> > > * Andy Lutomirski wrote:
> > > > I don't love mucking with user address space. I'm also quite nervous
> > > > about
> > > > putting it in our near anything that could pass an a
* Thomas Gleixner wrote:
> On Fri, 8 Dec 2017, Ingo Molnar wrote:
> > * Andy Lutomirski wrote:
> > > I don't love mucking with user address space. I'm also quite nervous
> > > about
> > > putting it in our near anything that could pass an access_ok check, since
> > > we're
> > > totally sc
On Fri, 8 Dec 2017, Ingo Molnar wrote:
> * Andy Lutomirski wrote:
> > I don't love mucking with user address space. I'm also quite nervous about
> > putting it in our near anything that could pass an access_ok check, since
> > we're
> > totally screwed if the bad guys can figure out how to wri
* Andy Lutomirski wrote:
>
>
> > On Dec 7, 2017, at 9:23 AM, Thomas Gleixner wrote:
> >
> >> On Thu, 7 Dec 2017, Andy Lutomirski wrote:
> >>
> >>> On Thu, Dec 7, 2017 at 4:43 AM, Borislav Petkov wrote:
> On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote:
> I think I
> On Dec 7, 2017, at 9:23 AM, Thomas Gleixner wrote:
>
>> On Thu, 7 Dec 2017, Andy Lutomirski wrote:
>>
>>> On Thu, Dec 7, 2017 at 4:43 AM, Borislav Petkov wrote:
On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote:
I think I like this approach. I also think it might be
On Thu, 7 Dec 2017, Andy Lutomirski wrote:
> On Thu, Dec 7, 2017 at 4:43 AM, Borislav Petkov wrote:
> > On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote:
> >> I think I like this approach. I also think it might be nice to move the
> >> whole cpu_entry_area into this new pgd range
On Thu, Dec 7, 2017 at 4:43 AM, Borislav Petkov wrote:
> On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote:
>> I think I like this approach. I also think it might be nice to move the
>> whole cpu_entry_area into this new pgd range so that we can stop mucking
>> around with the fixma
On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote:
> I think I like this approach. I also think it might be nice to move the
> whole cpu_entry_area into this new pgd range so that we can stop mucking
> around with the fixmap.
Yeah, and also, I don't like the idea of sacrificing a wh
21 matches
Mail list logo
