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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Aug 2020 10:03:18 +0800 From: "Jin, Yao" <yao.jin@...ux.intel.com> To: peterz@...radead.org Cc: mingo@...hat.com, oleg@...hat.com, acme@...nel.org, jolsa@...nel.org, Linux-kernel@...r.kernel.org, ak@...ux.intel.com, kan.liang@...el.com, yao.jin@...el.com, alexander.shishkin@...ux.intel.com, mark.rutland@....com Subject: Re: [PATCH v1 2/2] perf/core: Fake regs for leaked kernel samples Hi Peter, On 8/7/2020 5:02 PM, peterz@...radead.org wrote: > On Fri, Aug 07, 2020 at 02:24:30PM +0800, Jin, Yao wrote: >> Hi Peter, >> >> On 8/6/2020 7:00 PM, peterz@...radead.org wrote: >>> On Thu, Aug 06, 2020 at 11:18:27AM +0200, peterz@...radead.org wrote: >>> >>>> Suppose we have nested virt: >>>> >>>> L0-hv >>>> | >>>> G0/L1-hv >>>> | >>>> G1 >>>> >>>> And we're running in G0, then: >>>> >>>> - 'exclude_hv' would exclude L0 events >>>> - 'exclude_host' would ... exclude L1-hv events? >>>> - 'exclude_guest' would ... exclude G1 events? >>> >>> So in arch/x86/events/intel/core.c we have: >>> >>> static inline void intel_set_masks(struct perf_event *event, int idx) >>> { >>> struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); >>> >>> if (event->attr.exclude_host) >>> __set_bit(idx, (unsigned long *)&cpuc->intel_ctrl_guest_mask); >>> if (event->attr.exclude_guest) >>> __set_bit(idx, (unsigned long *)&cpuc->intel_ctrl_host_mask); >>> if (event_is_checkpointed(event)) >>> __set_bit(idx, (unsigned long *)&cpuc->intel_cp_status); >>> } >>> >> >> exclude_host is now set by guest (pmc_reprogram_counter, >> arch/x86/kvm/pmu.c). When enabling the event, we can check exclude_host to >> know if it's a guest. >> >> Otherwise we may need more flags in event->attr to indicate the status. >> >>> which is, afaict, just plain wrong. Should that not be something like: >>> >>> if (!event->attr.exclude_host) >>> __set_bit(idx, (unsigned long *)&cpuc->intel_ctrl_host_mask); >>> if (!event->attr.exclude_guest) >>> __set_bit(idx, (unsigned long *)&cpuc->intel_ctrl_guest_mask); >>> >>> >> >> How can we know it's guest or host even if exclude_host is set in guest? > > I'm not following you, consider: > > xh xg h g h' g' > 0 0 0 0 1 1 > 0 1 1 0 1 0 > 1 0 0 1 0 1 > 1 1 1 1 0 0 > > Thanks for the table! It clearly shows the combinations of different conditions. My understanding is: xh = exclude_host xg = exclude_guest h = intel_ctrl_host_mask (before) g = intel_ctrl_guest_mask (before) h' = intel_ctrl_host_mask (after) g' = intel_ctrl_guest_mask (after) For guest, exclude_host = 1 and exclude_guest = 0 xh xg h g h' g' 1 0 0 1 0 1 before/after values are not changed. For host, exclude_host = 0 and exclude_guest = 1 xh xg h g h' g' 0 1 1 0 1 0 before/after values are not changed. > So the 0,0 and 1,1 cases get flipped. I have a suspicion, but this > _really_ should have fat comments all over :-( > I'm not very sure about other cases. xh xg h g h' g' 0 0 0 0 1 1 1 1 1 1 0 0 The before/after values are just reversed. I don't know if there will be some negative impacts? Maybe we need more reviews here. > What a sodding trainwreck.. > :( Thanks Jin Yao
Powered by blists - more mailing lists