public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
From: ben.hutchings@codethink.co.uk (Ben Hutchings)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kernel feature support - architecture options and drivers
Date: Fri, 18 Aug 2017 14:38:59 +0100	[thread overview]
Message-ID: <1503063539.2047.90.camel@codethink.co.uk> (raw)
In-Reply-To: <04EAB7311EE43145B2D3536183D1A8445B96609D@GSjpTKYDCembx31.service.hitachi.net>

On Fri, 2017-07-28 at 04:49 +0000, ???? / KAWAI?HIDEHIRO wrote:
> Hello Ben,
> 
> I'm sorry for the late reply.

Likewise. :-/

[...]
> > KVM (CONFIG_VIRTUALIZATION) adds a large attack surface (guest-to-host)
> > and is likely to be hard to maintain in the long term.  Several of the
> > configurations (hitachi_omap, plathome_obsvx1, siemens_iot2000,
> > siemens_server) enable this.  Do you need it?
> 
> It is not used at this point, but may be need in the future.
> 
> As long as we don't use KVM to build up a multi tenant VM service,
> i.e. all users are the same legitimate user, the security risk of
> guest-to-host attack will not become higher.  So with regard to the
> security risk, it will not be a problem for some use cases.

Even when the guests are running known trusted code, that code might
have its own security flaws.  KVM then potentially provides a useful
security boundary between a compromised guest and the host.  But I take
your point - if the code running in the guest is trusted and security
supported, an outdated KVM doesn't add significant extra risk.

> > /dev/kmem (CONFIG_DEVKMEM) is only rarely needed for kernel debugging,
> > but is enabled in many configs.  Please disable it.
> > 
> > /dev/mem (CONFIG_DEVMEM) is needed by some userland drivers, though UIO
> > provides a cleaner way to do this.  Please check whether you can disable
> > it.
> 
> I tried to grep executable files in /usr/{bin,sbin}, and I found multiple
> commands which may access /dev/mem.  But I'm not sure how much impact
> disabling /dev/mem has on us.  We also use /dev/mem for a user land
> driver, but we will be able to reimplement it via UIO.
> 
> 
> By the way, I think that `supporting a feature' is not the same as
> `enabling a feature'.  Does `please disable it' mean that this is a
> suggestion for a secure config, or imply that CIP shouldn't support
> this feature?

Where I said 'please disable it' with no qualification, I think the
feature is inherently insecure and I don't think CIP should pretend to
provide security support for it.

Where I said something like 'check whether you can disable it', I
consider the feature to be high risk, but CIP should try to support it
if members need it.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

  reply	other threads:[~2017-08-18 13:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 13:18 [cip-dev] Kernel feature support - architecture options and drivers Ben Hutchings
2017-07-21 14:24 ` Agustin Benito Bethencourt
2017-07-21 15:19 ` Jan Kiszka
2017-07-21 17:11   ` Ben Hutchings
2017-07-21 17:27     ` Jan Kiszka
2017-07-28  4:49 ` 河合英宏 / KAWAI,HIDEHIRO
2017-08-18 13:38   ` Ben Hutchings [this message]
2017-08-21  7:46     ` 河合英宏 / KAWAI,HIDEHIRO
2017-08-30  5:59 ` Masato Minda

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=1503063539.2047.90.camel@codethink.co.uk \
    --to=ben.hutchings@codethink.co.uk \
    --cc=cip-dev@lists.cip-project.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox