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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220203101111.mx3o5kmo2bkjirn4@bogus>
Date:   Thu, 3 Feb 2022 12:04:56 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Anshuman Khandual <anshuman.khandual@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>, coresight@...ts.linaro.org
Subject: Re: [PATCH] coresight: trbe: Move check for kernelspace unmapped at
 EL0 to probe

On Thu, Feb 03, 2022 at 11:55:58AM +0530, Anshuman Khandual wrote:
> 
> 
> On 2/1/22 5:52 PM, Sudeep Holla wrote:
> > Currently with the check present in the module initialisation, it shouts
> > on all the systems irrespective of presence of coresight trace buffer
> > extensions.
> 
> IIUC a system with CONFIG_CORESIGHT_TRBE enabled but without a TRBE DT
> i.e "arm,trace-buffer-extension" complains about kernel space unmapping
> at EL0 (even though it does not even really have TRBE HW to initialize).


Correct. Basically, this error will be seen on all systems(DT and ACPI) when
the module is compiled. It really doesn't matter if the system supports TRBE.

> > 
> > Similar to Arm SPE perf driver, move the check for kernelspace unmapping
> > when running at EL0 to the device probe instead of module initialisation.
> 
> Makes sense.
>

Thanks.

> > 
> > Cc: Mathieu Poirier <mathieu.poirier@...aro.org>
> > Cc: Suzuki K Poulose <suzuki.poulose@....com>
> > Cc: Mike Leach <mike.leach@...aro.org>
> > Cc: Leo Yan <leo.yan@...aro.org>
> > Cc: Anshuman Khandual <anshuman.khandual@....com>
> > Cc: coresight@...ts.linaro.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@....com>
> > ---
> >  drivers/hwtracing/coresight/coresight-trbe.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> > index 276862c07e32..3fe2ce1ba5bf 100644
> > --- a/drivers/hwtracing/coresight/coresight-trbe.c
> > +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> > @@ -1423,6 +1423,11 @@ static int arm_trbe_device_probe(struct platform_device *pdev)
> >  	struct device *dev = &pdev->dev;
> >  	int ret;
> >  
> 
> Could you please add a similar comment like SPE driver regarding how
> the TRBE buffer will be inaccessible, if kernel gets unmapped at EL0
> and trace capture will terminate.
>

Sure I can add that. But if the device probe fails, will you be able to even
start the trace capture, sorry I didn't get what you mean by "trace capture
will terminate". I assume it must be "trace capture is not possible or not
allowed" IIUC.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ