linux-kernel - Re: [BUG/PATCH] x86 mmiotrace: dynamically disable non-boot CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Apr 2008 13:46:09 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Paalanen <pq@....fi>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	vegard.nossum@...il.com
Subject: Re: [BUG/PATCH] x86 mmiotrace: dynamically disable non-boot CPUs


* Pekka Paalanen <pq@....fi> wrote:

> > we should fix this restriction ASAP. Forcibly dropping to UP will 
> > cause mmiotrace to be much less useful for diagnostic purposes of 
> > Linux
> 
> Ok, how do you propose we solve this?
> 
> I have asked the question before, and then I had two ideas. Well, the
> first one was actually your idea (so I hear) to solve the same problem for
> kmemcheck.
> - per-cpu page tables
> - instead of single-stepping, emulate the faulting instruction and never
> disarm pages during tracing. (Use and modify code from KVM.)
> 
> I don't believe either of these is easy or fast to implement. Given 
> some months, I might be able to achieve emulation. Page tables are 
> still magic to me.

yeah - it looks complex. Not a showstopper for now :-)

but given that Xorg is usually just a single task, do we _really_ need 
this?

> > drivers. We want to enable the mmiotrace-ing of specific devices via 
> > some /sys flag. For example via:
> > 
> >    cat /sys/devices/pci0000\:00/0000\:00\:1f.2/mmiotrace
> > 
> > this should start mmiotracing of that specific device - or something 
> > like that. Hm?
> 
> Ooh, that sounds like a neat interface. I like it. I've been 
> half-thinking of different ways of specifying the set of devices to 
> trace, but none of them was particularly nice. This feature is for 
> post-2.6.26, right?

yeah, most likely.

> Ok, so first select mmiotrace tracer, at which point those sysfs files 
> appear, but mmiotrace is not activated yet. Then, when any of the 
> device specific files, or the global file in debugfs, is opened, 
> mmiotrace activates. And if the file is closed, mmiotrace deactivates.

sounds good to me!

> Should we support several "cats" at the same time?

if it's possible ...

> > i suspect the bug is that you bring the CPU down from an atomic 
> > (spinlocked or irq disabled) context.
> 
> Hmm, it should not be... I have to double-check, but all the other 
> code, too, from where enter_uniprocessor() is called, may sleep. The 
> first thing the caller does is to acquire a mutex, which I assume 
> would complain loudly if spinlocked or irq-disabled.
> 
> Ingo, thank you for fixing this patch, though I'd like to suggest to 
> leave it out for now, since there clearly are worse problems with it 
> than without it. And if we can solve the SMP issue, this is not 
> needed. For the time being we can just instruct users to disable all 
> but one CPU when try want to trace.

i think we still need to make this as 'transparent' to users as 
possible. Disabling CPUs can be tedious.

are lost events really a problem in practice, given Xorg's 
single-threadedness?

i'm leaving out this patch from the series for now.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/