On 04.12.2023 02:02, Elliott Mitchell wrote: > On Mon, Nov 27, 2023 at 09:27:18AM +0100, Roger Pau Monn >> On Fri, Nov 24, 2023 at 05:15:34PM -0800, Elliott Mitchell wrote: >>> On Thu, Nov 23, 2023 at 10:39:37AM +0100, Roger Pau Monn >>>> On Tue, Nov 21, 2023 at 04:56:47PM -0800, Elliott Mitchell wrote: >>>>> It was insisted that full logs be sent to xen-devel. Perhaps I am >>>>> paranoid, but I doubt I would have been successful at scrubbing all >>>>> hardware serial numbers. As such, I was willing to post substantial >>>>> sections, but not everything. >>>> >>>> Can you please point out which hardware serial numbers are you >>>> referring to, and where are they printed in Xen dmesg? >>> >>> I didn't confirm the presence of hardware serial numbers getting into >>> Xen's dmesg, but there was a lot of data and many hexadecimal numbers. >>> With 4000 lines of output, checking for concerning data is troublesome. >> >> 4000 lines of output from Xen dmesg seems quite suspicious. Xen dmesg >> on a fully booted box is ~400 lines on my local box. That might get >> quite longer if you have a box with a lot of memory region, or a lot >> of CPUs. > > That was from 4 boots with differing settings. Since it was full console > log, it also had the initial Linux kernel boot messages. Each log was > ~1000 lines. > >>> There was enough for alarms to trigger. >> >> That's fine, but without pointing out which information is sensitive, >> it's very unlikely such concerns will ever get fixed. >> >> Could you at least go over the log and point out the first instance of >> such line that you consider contains sensitive information? > > I would have been more comfortable with getting some guidance on which > portions were desired or which could be left out. No need for Linux's > boot messages, what would cut things down by half. No need for the > memory map, lots more goes.
I didn't think "xl dmesg" spit out any Dom0 kernel messages by default. Jan > It is easier to be comfortable with 40 line sections than 1000 line > sections. > >
