From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Wei Liu <wl@xen.org>, Anthony PERARD <anthony.perard@citrix.com>,
Juergen Gross <jgross@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/4] xen/x86: introduce self modifying code test
Date: Thu, 14 Dec 2023 16:28:50 +0100 [thread overview]
Message-ID: <ZXsfMthj8wTdZOeT@macbook> (raw)
In-Reply-To: <31cb367f-1a20-4ced-8f6f-aeab69f7c4fb@suse.com>
On Thu, Dec 14, 2023 at 02:57:11PM +0100, Jan Beulich wrote:
> On 14.12.2023 14:47, Roger Pau Monné wrote:
> > On Thu, Dec 14, 2023 at 12:55:22PM +0100, Jan Beulich wrote:
> >> On 14.12.2023 11:17, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/setup.c
> >>> +++ b/xen/arch/x86/setup.c
> >>> @@ -58,6 +58,7 @@
> >>> #include <asm/microcode.h>
> >>> #include <asm/prot-key.h>
> >>> #include <asm/pv/domain.h>
> >>> +#include <asm/test-smoc.h>
> >>>
> >>> /* opt_nosmp: If true, secondary processors are ignored. */
> >>> static bool __initdata opt_nosmp;
> >>> @@ -1951,6 +1952,8 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p)
> >>>
> >>> alternative_branches();
> >>>
> >>> + test_smoc(XEN_SYSCTL_TEST_SMOC_ALL, NULL);
> >>
> >> I realize I'm at risk of causing scope creep, but I'd still like to at
> >> least ask: As further self-tests are added, we likely don't want to
> >> alter __start_xen() every time. Should there perhaps better be a wrapper
> >> (going forward: multiple ones, depending on the time tests want invoking),
> >> together with a Kconfig control to allow suppressing all of these tests in
> >> at least release builds?
> >
> > Right now I only had in mind that livepatch related tests won't be
> > executed as part of the call in __start_xen(), but all the other ones
> > would, and hence wasn't expecting the code to change from the form in
> > the next patch.
>
> Well, I was thinking of there more stuff appearing in test/, not self-
> modifying-code related, and hence needing further test_*() alongside.
> test_smoc().
Oh, I see. I think it might be best to introduce such wrapper when we
have at least 2 different self tests? Otherwise it would be weird IMO
to have another function (ie: execute_self_tests()?) that's just a
wrapper around test_smoc().
> >>> --- /dev/null
> >>> +++ b/xen/arch/x86/test/smoc.c
> >>> @@ -0,0 +1,68 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>> +
> >>> +#include <xen/errno.h>
> >>> +
> >>> +#include <asm/alternative.h>
> >>> +#include <asm/cpufeature.h>
> >>> +#include <asm/test-smoc.h>
> >>> +
> >>> +static bool cf_check test_insn_replacement(void)
> >>> +{
> >>> +#define EXPECTED_VALUE 2
> >>> + unsigned int r = ~EXPECTED_VALUE;
> >>> +
> >>> + alternative_io("", "mov %1, %0", X86_FEATURE_ALWAYS,
> >>> + "+r" (r), "i" (EXPECTED_VALUE));
> >>> +
> >>> + return r == EXPECTED_VALUE;
> >>> +#undef EXPECTED_VALUE
> >>> +}
> >>> +
> >>> +int test_smoc(uint32_t selection, uint32_t *results)
> >>> +{
> >>> + struct {
> >>> + unsigned int mask;
> >>> + bool (*test)(void);
> >>> + const char *name;
> >>> + } static const tests[] = {
> >>> + { XEN_SYSCTL_TEST_SMOC_INSN_REPL, &test_insn_replacement,
> >>> + "alternative instruction replacement" },
> >>> + };
> >>> + unsigned int i;
> >>> +
> >>> + if ( selection & ~XEN_SYSCTL_TEST_SMOC_ALL )
> >>> + return -EINVAL;
> >>> +
> >>> + if ( results )
> >>> + *results = 0;
> >>> +
> >>> + printk(XENLOG_INFO "Checking Self Modify Code\n");
> >>> +
> >>> + for ( i = 0; i < ARRAY_SIZE(tests); i++ )
> >>> + {
> >>> + if ( !(selection & tests[i].mask) )
> >>> + continue;
> >>> +
> >>> + if ( tests[i].test() )
> >>> + {
> >>> + if ( results )
> >>> + *results |= tests[i].mask;
> >>> + continue;
> >>> + }
> >>> +
> >>> + add_taint(TAINT_ERROR_SMOC);
> >>> + printk(XENLOG_ERR "%s test failed\n", tests[i].name);
> >>
> >> Do we really want both of these even when coming here from the sysctl?
> >
> > So only print the messages if system_state < SYS_STATE_active?
>
> Yes. Nor tainting the system.
OK.
> >>> --- a/xen/common/kernel.c
> >>> +++ b/xen/common/kernel.c
> >>> @@ -386,13 +386,14 @@ char *print_tainted(char *str)
> >>> {
> >>> if ( tainted )
> >>> {
> >>> - snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c%c%c",
> >>> + snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c%c%c%c",
> >>> tainted & TAINT_MACHINE_INSECURE ? 'I' : ' ',
> >>> tainted & TAINT_MACHINE_CHECK ? 'M' : ' ',
> >>> tainted & TAINT_SYNC_CONSOLE ? 'C' : ' ',
> >>> tainted & TAINT_ERROR_INJECT ? 'E' : ' ',
> >>> tainted & TAINT_HVM_FEP ? 'H' : ' ',
> >>> - tainted & TAINT_CPU_OUT_OF_SPEC ? 'S' : ' ');
> >>> + tainted & TAINT_CPU_OUT_OF_SPEC ? 'S' : ' ',
> >>> + tainted & TAINT_ERROR_SMOC ? 'A' : ' ');
> >>
> >> How well is this going to scale as other selftests are added? IOW should
> >> this taint really be self-modifying-code-specific?
> >
> > I'm afraid I'm not sure I'm following. Would you instead like to make
> > the taint per-test selectable?
>
> The other way around actually: Taint generally for failed selftests,
> not just for the self-modifying-code one (which ends up being the only
> one right now).
So the suggestion would be to use TAINT_ERROR_SELFTEST instead of
TAINT_ERROR_SMOC? I can do that, but it might also be more
appropriate when there are more self tests.
Thanks, Roger.
next prev parent reply other threads:[~2023-12-14 15:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 10:17 [PATCH v3 0/4] xen/x86: add testing for self modifying code and livepatch Roger Pau Monne
2023-12-14 10:17 ` [PATCH v3 1/4] x86/livepatch: align functions to ensure minimal distance between entry points Roger Pau Monne
2023-12-14 11:18 ` Jan Beulich
2023-12-14 13:37 ` Roger Pau Monné
2023-12-14 13:53 ` Jan Beulich
2023-12-14 15:20 ` Roger Pau Monné
2023-12-14 15:28 ` Jan Beulich
2023-12-14 10:17 ` [PATCH v3 2/4] xen/x86: introduce self modifying code test Roger Pau Monne
2023-12-14 11:55 ` Jan Beulich
2023-12-14 13:47 ` Roger Pau Monné
2023-12-14 13:57 ` Jan Beulich
2023-12-14 15:28 ` Roger Pau Monné [this message]
2023-12-14 15:33 ` Jan Beulich
2023-12-14 10:17 ` [PATCH v3 3/4] x86/livepatch: introduce a basic live patch test to gitlab CI Roger Pau Monne
2023-12-14 12:55 ` Jan Beulich
2023-12-14 10:17 ` [PATCH v3 4/4] automation: add x86-64 livepatching test Roger Pau Monne
2023-12-14 19:10 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZXsfMthj8wTdZOeT@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.