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
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 Documentation/stable_kernel_rules
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 branchin
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 Bridg
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 uncondition
> 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 stable" in
the body of a message to majord...@vger.kernel.org
More ma
> 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
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: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 direc
>
> 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 t
* 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
* 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.
>
13 matches
Mail list logo
