linux-kernel - Re: [PATCH] trace: ras: print the raw data of arm processor error info

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] [day] [month] [year] [list]

Message-ID: <e391ed52-d861-0149-33eb-f55122b6bd6c@arm.com>
Date:   Wed, 26 Feb 2020 15:14:30 +0000
From:   James Morse <james.morse@....com>
To:     Xie XiuQi <xiexiuqi@...wei.com>
Cc:     Borislav Petkov <bp@...en8.de>, tony.luck@...el.com,
        linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] trace: ras: print the raw data of arm processor error
 info

Hi Xie,

On 13/01/2020 14:10, Xie XiuQi wrote:
> What do you think of this patch?
> 
> On 2020/1/9 19:46, Borislav Petkov wrote:
>>>  );
>>>  
>>>  /*

What patch?!

(digs in the headers)
https://lore.kernel.org/linux-edac/20191214121109.8349-1-xiexiuqi@huawei.com/

>>> -- 
>> That's for ARM folks to decide whether they wanna shuffle raw error
>> records into userspace like that. CCed.

Hmm, this dumps more of 'CPER_SEC_PROC_ARM' to user-space. But not all of it ... (ugh,
this is the thing with three variable length fields in it!) I would like to be able to
parse these in the kernel eventually, but that doesn't matter right now.

I agree privileged user-space should be able to collect all the CPER for some tool to
analyse it. (what else would we do with 'vendor specific error info'?). I'm not totally
convinced tracepoints are the right thing for big blobs of data like this, but its what
we're using today.

I'll show my ignorance about trace points:

How does rasdaemon react to you expanding the trace point like this? I recall they are
self-describing, if user-space doesn't hard code the layout...

You export what may be kernel pointers with the virtual fault address. Is there any way an
unprivileged user can get hold of these?
(its somewhat pointless as user-space can't know what that pointer means)

Thanks,

James