On Tue, 20 Jun 2017 21:45:31 -0700
stan wrote:
> On Tue, 20 Jun 2017 23:44:24 -0400
> Tony Nelson wrote:
>
> > It's not allocated memory. It's a Page Table Entry in the Kernel
> > that ensures that no actual memory is mapped there and that the
> > region is thus unreadable and unwritable. Thi
On Tue, 20 Jun 2017 23:44:24 -0400
Tony Nelson wrote:
> It's not allocated memory. It's a Page Table Entry in the Kernel that
> ensures that no actual memory is mapped there and that the region is
> thus unreadable and unwritable. This is not unlike a swapped-out
> page, except the Kernel Page
On 17-06-20 13:09:50, stan wrote:
On Tue, 20 Jun 2017 12:20:57 -0400
Tom Horsley wrote:
> That seems like it might be impossible without architecture changes
> in the chips to allow bounds checking the stack pointer in hardware
> (which certainly wouldn't fix any existing systems :-).
I think
On Tue, 20 Jun 2017 17:08:09 +0100
Patrick O'Callaghan wrote:
> Full details are in the report already cited, but briefly the fix
> causes each page of the new stack frame to be probed to make sure it
> doesn't overlap with the guard page (a write-protected page created to
> prevent stack and hea
On Tue, 20 Jun 2017 12:20:57 -0400
Tom Horsley wrote:
> That seems like it might be impossible without architecture changes
> in the chips to allow bounds checking the stack pointer in hardware
> (which certainly wouldn't fix any existing systems :-).
I think the kernel fix was the first solutio
On Tue, 2017-06-20 at 12:20 -0400, Tom Horsley wrote:
> On Tue, 20 Jun 2017 08:42:39 -0700
> stan wrote:
>
> > My
> > assumption was that this was adding the strong stack protection to the
> > kernel side of things.
>
> That seems like it might be impossible without architecture changes
> in the
On Tue, 20 Jun 2017 08:42:39 -0700
stan wrote:
> My
> assumption was that this was adding the strong stack protection to the
> kernel side of things.
That seems like it might be impossible without architecture changes
in the chips to allow bounds checking the stack pointer in hardware
(which cert
On Tue, 2017-06-20 at 08:42 -0700, stan wrote:
> On Tue, 20 Jun 2017 13:11:24 +0100
> Patrick O'Callaghan wrote:
>
> > On Mon, 2017-06-19 at 23:08 -0700, stan wrote:
> > > I'm running
> > > the kernel with the fix, and it is working fine so far.
> >
> > As I understand it (and as the bug rep
On Tue, 20 Jun 2017 13:11:24 +0100
Patrick O'Callaghan wrote:
> On Mon, 2017-06-19 at 23:08 -0700, stan wrote:
> > I'm running
> > the kernel with the fix, and it is working fine so far.
>
> As I understand it (and as the bug report appears to confirm) the fix
> is to ld.so, not the kernel,
On Tue, 2017-06-20 at 08:56 -0400, Tom Horsley wrote:
> On Tue, 20 Jun 2017 08:32:23 -0400
> Tom Horsley wrote:
>
> > That doesn't make any sense. If the exploit happens in ld.so, fixing it
> > doesn't do anything. All you need to do is point an executable at an
> > old copy of ld.so and you have
On Tue, 20 Jun 2017 08:32:23 -0400
Tom Horsley wrote:
> That doesn't make any sense. If the exploit happens in ld.so, fixing it
> doesn't do anything. All you need to do is point an executable at an
> old copy of ld.so and you have access to the same exploit.
OK, I see it now. The exploit only ha
On Tue, 20 Jun 2017 13:11:24 +0100
Patrick O'Callaghan wrote:
> As I understand it (and as the bug report appears to confirm) the fix
> is to ld.so, not the kernel, though changing ld.so does of course mean
> a reboot.
That doesn't make any sense. If the exploit happens in ld.so, fixing it
doesn'
12 matches
Mail list logo
