From: Sergey Dyasli <email@example.com> To: Andrew Cooper <firstname.lastname@example.org>, <email@example.com> Cc: Lars Kurth <firstname.lastname@example.org>, Stefano Stabellini <email@example.com>, Julien Grall <firstname.lastname@example.org>, Wei Liu <email@example.com>, Konrad Rzeszutek Wilk <firstname.lastname@example.org>, George Dunlap <George.Dunlap@eu.citrix.com>, Doug Goldstein <email@example.com>, Ian Jackson <firstname.lastname@example.org>, Jan Beulich <email@example.com>, Daniel De Graaf <firstname.lastname@example.org>, "email@example.com >> Sergey Dyasli" <firstname.lastname@example.org> Subject: Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests Date: Mon, 13 Jan 2020 11:01:05 +0000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 10/01/2020 11:02, Andrew Cooper wrote: > On 10/01/2020 10:37, Sergey Dyasli wrote: >> Hide the following information that can help identify the running Xen >> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset. >> Add explicit cases for XENVER_commandline and XENVER_build_id as well. >> >> Introduce xsm_filter_denied() to hvmloader to remove "<denied>" string >> from guest's DMI tables that otherwise would be shown in tools like >> dmidecode. >> >> Signed-off-by: Sergey Dyasli <email@example.com> >> --- >> v1 --> v2: >> - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny() >> - Made behaviour the same for both Release and Debug builds >> - XENVER_capabilities is no longer hided >> >> CC: Andrew Cooper <firstname.lastname@example.org> >> CC: George Dunlap <George.Dunlap@eu.citrix.com> >> CC: Ian Jackson <email@example.com> >> CC: Jan Beulich <firstname.lastname@example.org> >> CC: Julien Grall <email@example.com> >> CC: Konrad Rzeszutek Wilk <firstname.lastname@example.org> >> CC: Stefano Stabellini <email@example.com> >> CC: Wei Liu <firstname.lastname@example.org> >> CC: Daniel De Graaf <email@example.com> > > I realise there are arguments over how to fix this, but we (the Xen > community) have already f*cked up once here, and this is doing so a > second time. > > Nack. > > Fixing it anywhere other than Xen is simply not appropriate. > > The reason for this (which ought to be obvious, but I guess only to > those who actually do customer support) is basic human physiology. > "denied" means something has gone wrong. It scares people, and causes > them to seek help to change fix whatever is broken. But the patch takes care of that by removing "denied" from DMI tables. Functionally it should have the same effect as v1 to ordinary guests. > It is not appropriate for it to find its way into the guest in the first > place, and that includes turning up in `dmesg` and other logs, and > expecting guest runtime to filter for it is complete nonsense. `dmesg` will have only Xen major version (e.g. Xen 4.13) with this patch applied. Even if there exists a tool which uses xen_version hypercall for information gathering, it would show you "<denied>" for fields like commandline and build_id already (without the patch). So extending this behaviour for other sensitive fields is not a regression IMHO. > As said several times before, the empty string is completely fine ABI > wise, doesn't confuse customers, and really really does work in practice. I agree with the other opinion that returning an empty string is too ambiguous. I'd prefer to retain the current behaviour with (whatever) non-empty descriptive string. -- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-13 11:01 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-10 10:37 Sergey Dyasli 2020-01-10 11:02 ` Andrew Cooper 2020-01-10 15:28 ` George Dunlap 2020-01-10 15:56 ` Jan Beulich 2020-01-10 16:45 ` Jürgen Groß 2020-01-10 17:00 ` George Dunlap 2020-01-11 3:55 ` Doug Goldstein 2020-01-11 9:35 ` George Dunlap 2020-01-13 11:01 ` Sergey Dyasli [this message] 2020-01-10 11:09 ` Jan Beulich 2020-01-11 4:02 ` Doug Goldstein 2020-01-11 9:02 ` George Dunlap 2020-01-12 18:26 ` Doug Goldstein 2020-01-13 12:51 ` George Dunlap 2020-01-13 13:39 ` Julien Grall 2020-01-13 14:01 ` Andrew Cooper 2020-01-13 14:07 ` George Dunlap 2020-01-13 14:28 ` Julien Grall 2020-01-13 14:40 ` Andrew Cooper 2020-01-14 10:19 ` Sergey Dyasli 2020-01-13 14:52 ` Julien Grall 2020-01-13 14:01 ` Ian Jackson
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=George.Dunlap@eu.citrix.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests' \ /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
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.