How about performance when running with ASI?
On Fri, Apr 26, 2019 at 07:41:09AM -0700, Dave Hansen wrote:
> On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > The idea behind the prevention is that if we fault in pages in the
> > execution path, we can compare target address against the kernel symbol
> > table. So if we're in a function, we allow
On Thu, Apr 25, 2019 at 05:30:13PM -0700, Andy Lutomirski wrote:
> On Thu, Apr 25, 2019 at 2:46 PM Mike Rapoport wrote:
> >
> > Hi,
> >
> > Address space isolation has been used to protect the kernel from the
> > userspace and userspace programs from each other since the invention of the
> > virtu
On 4/25/19 2:45 PM, Mike Rapoport wrote:
> The idea behind the prevention is that if we fault in pages in the
> execution path, we can compare target address against the kernel symbol
> table. So if we're in a function, we allow local jumps (and simply falling
> of the end of a page) but if we're
On Thu, 25 Apr 2019, Andy Lutomirski wrote:
> The benefit seems to come from making sure that the RET instruction
> actually goes somewhere that's already been faulted in.
Which doesn't seem to be really compatible with things like retpolines or
anyone using FTRACE_WITH_REGS to modify stored in
On Thu, Apr 25, 2019 at 2:46 PM Mike Rapoport wrote:
>
> Hi,
>
> Address space isolation has been used to protect the kernel from the
> userspace and userspace programs from each other since the invention of the
> virtual memory.
>
> Assuming that kernel bugs and therefore vulnerabilities are inev
Hi,
Address space isolation has been used to protect the kernel from the
userspace and userspace programs from each other since the invention of the
virtual memory.
Assuming that kernel bugs and therefore vulnerabilities are inevitable it
might be worth isolating parts of the kernel to minimize d
7 matches
Mail list logo
