* Ingo Molnar wrote:
> > I don't think you want to spend that many cycles in the NMI
> > handler for a dubious feature. Ok in theory you could
> > add something with binary search, but that would be quite
> > a bit of effort and it would be probably challenging
> > to do that all NMI safe.
>
* Andi Kleen wrote:
> >
> > OK, so how about we use something like:
> >
> > is_kernel_text() || is_module_text_address()
>
> is_module_text_address() has to walk all modules.
> A random system with a distro kernel I checked has 101 modules loaded.
I checked another random distro and it
* Andi Kleen a...@firstfloor.org wrote:
OK, so how about we use something like:
is_kernel_text() || is_module_text_address()
is_module_text_address() has to walk all modules.
A random system with a distro kernel I checked has 101 modules loaded.
I checked another random
* Ingo Molnar mi...@kernel.org wrote:
I don't think you want to spend that many cycles in the NMI
handler for a dubious feature. Ok in theory you could
add something with binary search, but that would be quite
a bit of effort and it would be probably challenging
to do that all NMI
>
> OK, so how about we use something like:
>
>is_kernel_text() || is_module_text_address()
is_module_text_address() has to walk all modules.
A random system with a distro kernel I checked has 101 modules loaded.
16 * 101 = too much
I don't think you want to spend that many cycles in
On Thu, Apr 25, 2013 at 07:42:11PM +0200, Andi Kleen wrote:
> There's the non cachable region tracking. But there's no guarantee a
> MMIO has to be in there, driver may still rely just on MTRRs. Also
> there may be MMIOs the kernel doesn't know about which just happen
> to be somewhere in the
On Thu, Apr 25, 2013 at 07:42:11PM +0200, Andi Kleen wrote:
There's the non cachable region tracking. But there's no guarantee a
MMIO has to be in there, driver may still rely just on MTRRs. Also
there may be MMIOs the kernel doesn't know about which just happen
to be somewhere in the direct
OK, so how about we use something like:
is_kernel_text() || is_module_text_address()
is_module_text_address() has to walk all modules.
A random system with a distro kernel I checked has 101 modules loaded.
16 * 101 = too much
I don't think you want to spend that many cycles in the
On Thu, Apr 25, 2013 at 07:18:42PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 25, 2013 at 07:00:37PM +0200, Andi Kleen wrote:
> > > Traping the read deals with the first. The second shouldn't be a problem
> > > since
> > > we generally only allow kernel info for CAP_ADMIN; if we don't already
>
On Thu, Apr 25, 2013 at 07:00:37PM +0200, Andi Kleen wrote:
> > Traping the read deals with the first. The second shouldn't be a problem
> > since
> > we generally only allow kernel info for CAP_ADMIN; if we don't already for
> > LBR
> > that needs to be fixed separately.
>
> Where is that
> Traping the read deals with the first. The second shouldn't be a problem since
> we generally only allow kernel info for CAP_ADMIN; if we don't already for LBR
> that needs to be fixed separately.
Where is that check? I don't see it.
Also remember that precise == 2 can enable LBR implicitly.
On Thu, Apr 25, 2013 at 06:41:00PM +0200, Andi Kleen wrote:
> > So why not do the same as we do for userspace? Copy MAX_INSN_SIZE bytes
> > and trap -EFAULT.
>
> Read the whole description, then you'll know why that is insecure.
You didn't actually explicitly mention it; you just said
> So why not do the same as we do for userspace? Copy MAX_INSN_SIZE bytes
> and trap -EFAULT.
Read the whole description, then you'll know why that is insecure.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
> Possible options:
>
> I) Disable FAR calls for ANY_CALL/RETURNS.
> This just means syscalls are not logged
> as calls. This also lowers the overhead of call logging.
> This changes semantics slightly.
> This is reasonable on Sandy
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
Possible options:
I) Disable FAR calls for ANY_CALL/RETURNS.
This just means syscalls are not logged
as calls. This also lowers the overhead of call logging.
This changes semantics slightly.
This is reasonable on Sandy Bridge and
So why not do the same as we do for userspace? Copy MAX_INSN_SIZE bytes
and trap -EFAULT.
Read the whole description, then you'll know why that is insecure.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Thu, Apr 25, 2013 at 06:41:00PM +0200, Andi Kleen wrote:
So why not do the same as we do for userspace? Copy MAX_INSN_SIZE bytes
and trap -EFAULT.
Read the whole description, then you'll know why that is insecure.
You didn't actually explicitly mention it; you just said unconditional
Traping the read deals with the first. The second shouldn't be a problem since
we generally only allow kernel info for CAP_ADMIN; if we don't already for LBR
that needs to be fixed separately.
Where is that check? I don't see it.
Also remember that precise == 2 can enable LBR implicitly.
On Thu, Apr 25, 2013 at 07:00:37PM +0200, Andi Kleen wrote:
Traping the read deals with the first. The second shouldn't be a problem
since
we generally only allow kernel info for CAP_ADMIN; if we don't already for
LBR
that needs to be fixed separately.
Where is that check? I don't
On Thu, Apr 25, 2013 at 07:18:42PM +0200, Peter Zijlstra wrote:
On Thu, Apr 25, 2013 at 07:00:37PM +0200, Andi Kleen wrote:
Traping the read deals with the first. The second shouldn't be a problem
since
we generally only allow kernel info for CAP_ADMIN; if we don't already
for LBR
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> The perf LBR code has special code to filter specific
> instructions in software.
>
> The LBR logs any instruction address, even if IP just faulted.
> This means user space can control any address by just
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
[]
> Should be applied to applicable stable branches too. The problem
> goes back a long time.
>
> Signed-off-by: Andi Kleen
> ---
[...]
This is not the correct way to submit a change to stable.
See
From: Andi Kleen
The perf LBR code has special code to filter specific
instructions in software.
The LBR logs any instruction address, even if IP just faulted.
This means user space can control any address by just branching
to a bad address.
On a modern Intel system the only software filtering
From: Andi Kleen a...@linux.intel.com
The perf LBR code has special code to filter specific
instructions in software.
The LBR logs any instruction address, even if IP just faulted.
This means user space can control any address by just branching
to a bad address.
On a modern Intel system the
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
[]
Should be applied to applicable stable branches too. The problem
goes back a long time.
Signed-off-by: Andi Kleen a...@linux.intel.com
---
[...]
This is not the correct way to submit a change to stable.
See
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
The perf LBR code has special code to filter specific
instructions in software.
The LBR logs any instruction address, even if IP just faulted.
This means user space can control any address by
26 matches
Mail list logo
