linux-kernel - Re: [PATCH RFC] kunit: tool: add 'mte=on' qemu arg on arm64

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]

Date: Tue, 20 Feb 2024 08:46:06 +0800
From: David Gow <davidgow@...gle.com>
To: Paul Heidekrüger <paul.heidekrueger@....de>
Cc: Brendan Higgins <brendan.higgins@...ux.dev>, Mark Brown <broonie@...nel.org>, 
	Shuah Khan <skhan@...uxfoundation.org>, 
	"open list:KERNEL UNIT TESTING FRAMEWORK (KUnit)" <linux-kselftest@...r.kernel.org>, 
	"open list:KERNEL UNIT TESTING FRAMEWORK (KUnit)" <kunit-dev@...glegroups.com>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] kunit: tool: add 'mte=on' qemu arg on arm64

On Wed, 14 Feb 2024 at 20:41, Paul Heidekrüger <paul.heidekrueger@....de> wrote:
>
> Hi!
>
> I was running some KASan tests with kunit.py recently and noticed that
> when KASan is run in hw tags mode, we manually have to add the required
> `mte=on` option to kunit_tool's qemu invocation, as the tests will
> otherwise crash.
>
> To make life easier, I was looking into ways for kunit.py to recognise
> when MTE support was required and set the option automatically.
>
> All solutions I could come up with for having kunit_tool conditionally
> pass `mte=on` to qemu, either entailed duplicate code or required
> parsing of kernel's config file again. I was working under the
> assumption that only after configuring the kernel we would know whether
> the 'mte=on' option was necessary, as CONFIG_ARM64_MTE is not visible
> before.
>
> Only afterwads did I realise that the qemu arm64 config that kunit_tool
> falls back on, uses the `virt` machine, which supports MTE in any case.
> So, could it be as easy as just adding the `mte=on` option to
> kunit_tool's arm64 config? Would this be a welcome addition?
>
> What do you think?
>
> Many thanks,
> Paul
>
> Signed-off-by: Paul Heidekrüger <paul.heidekrueger@....de>
> ---

I think this is fine. I'd be a little bit concerned if this were only
supported in newer qemu versions, but it seems to go back to 6.2, so
should be okay. I think it's better to just enable it unconditionally
by default rather than trying to parse the config.

The KASAN tests seemed to work fine with HW tags in my testing here. I
do wonder if there's a way to make the tests skip themselves if MTE
isn't available: is there a way of doing a runtime check for this?

Regardless, this is:
Reviewed-by: David Gow <davidgow@...gle.com>

-- David

>  tools/testing/kunit/qemu_configs/arm64.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/kunit/qemu_configs/arm64.py b/tools/testing/kunit/qemu_configs/arm64.py
> index d3ff27024755..a525f7e1093b 100644
> --- a/tools/testing/kunit/qemu_configs/arm64.py
> +++ b/tools/testing/kunit/qemu_configs/arm64.py
> @@ -9,4 +9,4 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y''',
>                            qemu_arch='aarch64',
>                            kernel_path='arch/arm64/boot/Image.gz',
>                            kernel_command_line='console=ttyAMA0',
> -                          extra_qemu_params=['-machine', 'virt', '-cpu', 'max,pauth-impdef=on'])
> +                          extra_qemu_params=['-machine', 'virt,mte=on', '-cpu', 'max,pauth-impdef=on'])
> --
> 2.40.1
>

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4014 bytes)