[cip-dev] Kernel feature support - architecture options and drivers

[cip-dev] Kernel feature support - architecture options and drivers

[Ben Hutchings]

Sorry for the delay in reviewing feature support.  I previously reviewed
filesystems and networking options, and this covers most of the rest.  I
will send one more mail after this covering the remaining options.

# x86

a.out support (CONFIG_IA32_AOUT) is enabled in plathome_obsvx but is
only needed for programs built before about 1995!  Please disable it.

Vsyscall emulation (CONFIG_LEGACY_VSYSCALL_EMULATE) should be disabled
as it's only needed by older C libraries.  Please select
CONFIG_LEGACY_VSYSCALL_NONE instead.

The modify_ldt syscall (CONFIG_MODIFY_LDT_SYSCALL) and 16-bit code
support (CONFIG_X86_16BIT) should be disabled; they're only needed to
run WINE.

Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
siemens_iot2000 config.  Are you really using Quark SoCs?

X32 syscall support (CONFIG_X86_X32) adds some attack surface that is
not well-tested.  Several of the configurations (plathome_obsvx1,
siemens_server and toshiba) enable this.  Do you need it?

KVM old-style device assignment (CONFIG_KVM_DEVICE_ASSIGNMENT) is
deprecated and the feature has been removed upstream in 4.12, so it is
definitely not supportable.  Only the plathome_obsvx1 config has this
enabled.  Please disable it.  If you are actually using this feature, it
should be replaced by VFIO.

i7300_idle (CONFIG_I7300_IDLE) has been removed upstream, but is enabled
in the plathome_obsvx1, siemens_server and toshiba configs).  This is
only useful for the Intel i7300 chipset, so it should be fine to disable
it.

Several drivers (CONFIG_HP_WIRELESS, CONFIG_INTEL_RST,
CONFIG_INTEL_SMARTCONNECT) appear to only be useful for laptops, but are
enabled in the siemens_server config.  Please consider disabling them.

SFI (CONFIG_SFI) seems to only be useful for Intel smartphone platforms,
but is enabled in the siemens_server config.  Please disable it.

# Storage drivers

nbd (CONFIG_BLK_DEV_NBD) was not in good shape in 4.4, but is enabled in
plathome_obsvx1.config and 
siemens_iot2000.  Do you need it?

dm-cache (CONFIG_DM_CACHE) is marked as experimental in 4.4 and has
changed a lot upstream, which will make it hard to maintain.  The
siemens_server config has it enabled.  Do you need it?

dm-switch (CONFIG_DM_SWITCH) is marked as experimental in 4.4, but is
enabled in the siemens_server config.  Do you need it?

MD multipath (CONFIG_MD_MULTIPATH) is "not under active development",
and should be replaced with dm-multipath.  It is enabled in the
plathome_obsvx1, siemens_iot2000, and siemens_server configs.  Do you
need it?

Many old SCSI drivers (CONFIG_BLK_DEV_3W_XXXX_RAID, CONFIG_SCSI_3W_9XXX,
CONFIG_SCSI_3W_SAS, CONFIG_SCSI_ACARD, CONFIG_SCSI_ADVANSYS,
CONFIG_SCSI_AM53C974, CONFIG_SCSI_BUSLOGIC, CONFIG_SCSI_DC395x,
CONFIG_SCSI_DMX3191D, CONFIG_SCSI_DPT_I2O, CONFIG_SCSI_EATA,
CONFIG_SCSI_GDTH, CONFIG_SCSI_IMM, CONFIG_SCSI_INIA100,
CONFIG_SCSI_INITIO, CONFIG_SCSI_IPS, CONFIG_SCSI_MVUMI,
CONFIG_SCSI_PMCRAID, CONFIG_SCSI_PPA, CONFIG_SCSI_QLOGIC_1280,
CONFIG_SCSI_SYM53C8XX_2, CONFIG_SCSI_WD719X, CONFIG_SCSI_AIC79XX,
CONFIG_SCSI_AIC7XXX, CONFIG_SCSI_AIC94XX, CONFIG_SCSI_ESAS2R,
CONFIG_MEGARAID_LEGACY, CONFIG_SCSI_MVSAS, CONFIG_SCSI_QLA_ISCSI) are
enabled in siemens_server config and I very much doubt you need any of
these.  Please disable them.

# Graphics drivers

gma500 (CONFIG_DRM_GMA{3600,500,600}) is not maintained upstream and
will be unsupportable, but is enabled in the plathome_obsvx1 config.  Do
you need it?

nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config.  I'm
not sure how this could be useful in an OMAP system, and I don't expect
the driver to be supportable.  Please disable it.

# Network drivers

Many old Ethernet drivers (CONFIG_TYPHOON, CONFIG_VORTEX,
CONFIG_NE2K_PCI, CONFIG_DNET, CONFIG_ETHOC, CONFIG_FEALNX, CONFIG_JME,
CONFIG_ADAPTEC_STARFIRE, CONFIG_AMD8111_ETH, CONFIG_PCNET32,
CONFIG_ATL1, CONFIG_ATL1C, CONFIG_ATL1E, CONFIG_ATL2, CONFIG_B44,
CONFIG_BCMGENET, CONFIG_CHELSIO_T1, CONFIG_DE2104X, CONFIG_DE4X5,
CONFIG_DM9102, CONFIG_NET_TULIP, CONFIG_ULI526X, CONFIG_WINBOND_840,
CONFIG_DL2K, CONFIG_SUNDANCE, CONFIG_HP100, CONFIG_SKY2, CONFIG_KS8842,
CONFIG_KSZ884X_PCI, CONFIG_ENC28J60, CONFIG_MYRI10GE, CONFIG_NATSEMI,
CONFIG_NS83820, CONFIG_S2IO, CONFIG_VXGE, CONFIG_FORCEDETH,
CONFIG_HAMACHI, CONFIG_YELLOWFIN, CONFIG_NETXEN_NIC, CONFIG_QLA3XXX,
CONFIG_QLGE, CONFIG_R6040, CONFIG_8139CP, CONFIG_8139TOO, CONFIG_ATP,
CONFIG_SC92031, CONFIG_SIS190, CONFIG_SIS900, CONFIG_EPIC100,
CONFIG_SMSC9420, CONFIG_CASSINI, CONFIG_HAPPYMEAL, CONFIG_NIU,
CONFIG_TEHUTI, CONFIG_TLAN, CONFIG_VIA_RHINE, CONFIG_VIA_VELOCITY,
CONFIG_WIZNET_W5100, CONFIG_WIZNET_W5300) are enabled in siemens_server
config and I very much doubt you need any of these.  samsung-sxgbe
(CONFIG_SXGBE_ETH) is also enabled, but this hardware only exists in
Samsung SoCs.  Please disable them.

e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
not maintained upstream.  (Don't confuse e1000 with e1000e, which is for
PCI Express and is still maintained.)  Please disable them.

sungem (CONFIG_SUNGEM) is enabled in the siemens_server and toshiba
powerpc configs, but I doubt that this driver is needed.  Please
consider disabling it.

USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
seem to be properly maintained upstream.  Do you need them?

i2400m-usb (CONFIG_WIMAX_I2400M_USB) is enabled in plathome_obsvx1, but
is unmaintained upstream.  Do you need it?  (I also noted previously
that wimax in general is dead.)

Wifi drivers may be hard to support in the long term due to changes in
the softMAC (mac80211) driver API.  However I will assume that they are
needed for some applications.

The ipw2x00 drivers (CONFIG_IPW2100, CONFIG_IPW2200) are not maintained
and only found in some old x86 systems, but is enabled in the
plathome_obsvx1 config.  Please disable them.

zd1211rw (CONFIG_ZD1211RW) seems to be unmaintained but is enabled in
the plathome_obsvx1 config.  Please disable it.

r8172u (CONFIG_R8712U) is in drivers/staging (and has been for nearly 7
years!) and is therefore unlikely to be supportable, but is enabled in
the siemens_iot2000 config.  Do you need it?

# USB drivers

fotg210-hcd (CONFIG_USB_FOTG210_HCD) is a platform driver that doesn't
look usable on x86, but is enabled in the siemens_server config.  Please
disable it.

uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
x86 configs.  Please disable it.

ehset (CONFIG_USB_EHSET_TEST_FIXTURE) and usb3503
(CONFIG_USB_HSIC_USB3503) are unlikely to be needed but are enabled in
the siemens_server config.  Please consider disabling them.

# Misc drivers

OProfile (CONFIG_OPROFILE) seems to be barely maintained and redundant
with perf, but all the configs still enable it (mostly because it's
enabled in upstream defconfigs).  Please consider disabling it.

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?

/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.

Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
siemens_server config.  Assuming you don't need to support these
platforms, please disable it.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[cip-dev] Kernel feature support - architecture options and drivers

[Agustin Benito Bethencourt]

Dear CIP friends,

On 21/07/17 15:18, Ben Hutchings wrote:
> Sorry for the delay in reviewing feature support.  I previously reviewed
> filesystems and networking options, and this covers most of the rest.  I
> will send one more mail after this covering the remaining options.


please remember that Ben H. will join us at the TSC bi-weekly call next 
Monday. It would be very good if you can take a look at this mail before 
the meeting.

Best Regards

-- 
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at codethink.co.uk

[cip-dev] Kernel feature support - architecture options and drivers

[Jan Kiszka]

On 2017-07-21 15:18, Ben Hutchings wrote:
> Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
> siemens_iot2000 config.  Are you really using Quark SoCs?

Yeah...
http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
This revision will stop being shipped at latest in 2020, but there will
be a lot of these chips in the field until then.

Likely all needed patches will be in 4.13 (just still struggling to get
userspace software ported from the Intel BSP to mainline). So I'm
planning to submit the essential patches for CIP integration "soon".

> uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
> know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
> x86 configs.  Please disable it.

You need it for old USB 2.0 chipsets that have separate USB 1.1 and 2.0
interfaces. Those would then no longer word with 1.1 devices. But I bet
none of the provided products contain that.

> 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?

Not on the IOT2000 (f...ine Yocto rules made that pop up, I still need
to convert to a plain defconfig), not for production purposes on our
server, but we do have products (not listed so far) with KVM.

With - buzzword alarm - "edge computing", it is getting more and more
important as isolation tool for "apps". Containers/namespaces are
sometimes not strong enough.

I can contribute to reviewing patches when needed or talk to the current
maintainers to have a look as well. At least on x86, it is mature by
now. ARM seems to be catching up quickly.

> /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 just explained this these days to someone who wanted to build an API
around it. In current embedded, it can be tricky, but I'm with you and
will promote its removal further.

> 
> Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
> siemens_server config.  Assuming you don't need to support these
> platforms, please disable it.

Ack.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] Kernel feature support - architecture options and drivers

[Ben Hutchings]

On Fri, 2017-07-21 at 17:19 +0200, Jan Kiszka wrote:
> On 2017-07-21 15:18, Ben Hutchings wrote:
> > Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
> > siemens_iot2000 config.  Are you really using Quark SoCs?
> 
> Yeah...
> http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
> This revision will stop being shipped at latest in 2020, but there will
> be a lot of these chips in the field until then.
>
> Likely all needed patches will be in 4.13 (just still struggling to get
> userspace software ported from the Intel BSP to mainline). So I'm
> planning to submit the essential patches for CIP integration "soon".

I assume you're aware of erratum #24 affecting the LOCK prefix?  There
seems to be no solution except to use Intel's forked version of binutils
which deletes the LOCK prefix.  I don't know if it's an issue for kernel
code, but probably not - the kernel shouldn't use LOCK if CONFIG_SMP is
not enabled, and in any case shouldn't get a page fault on such an
instruction..

> > uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
> > know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
> > x86 configs.  Please disable it.
> 
> You need it for old USB 2.0 chipsets that have separate USB 1.1 and 2.0
> interfaces. Those would then no longer word with 1.1 devices. But I bet
> none of the provided products contain that.

I know there were some UHCI/EHCI pairings but I haven't seen a UHCI in a
long time.

> > 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?
> 
> Not on the IOT2000 (f...ine Yocto rules made that pop up, I still need
> to convert to a plain defconfig), not for production purposes on our
> server, but we do have products (not listed so far) with KVM.
> 
> With - buzzword alarm - "edge computing", it is getting more and more
> important as isolation tool for "apps". Containers/namespaces are
> sometimes not strong enough.
[...]

I understand that - just trying to check that is actually being used.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[cip-dev] Kernel feature support - architecture options and drivers

[Jan Kiszka]

On 2017-07-21 19:11, Ben Hutchings wrote:
> On Fri, 2017-07-21 at 17:19 +0200, Jan Kiszka wrote:
>> On 2017-07-21 15:18, Ben Hutchings wrote:
>>> Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
>>> siemens_iot2000 config.  Are you really using Quark SoCs?
>>
>> Yeah...
>> http://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/pages/default.aspx.
>> This revision will stop being shipped at latest in 2020, but there will
>> be a lot of these chips in the field until then.
>>
>> Likely all needed patches will be in 4.13 (just still struggling to get
>> userspace software ported from the Intel BSP to mainline). So I'm
>> planning to submit the essential patches for CIP integration "soon".
> 
> I assume you're aware of erratum #24 affecting the LOCK prefix?  There
> seems to be no solution except to use Intel's forked version of binutils
> which deletes the LOCK prefix.

That switch is even upstream. But, yeah, we need to rebuild everything
in userland from scratch and can't use, e.g., normal Debian packages.
For the next version, we software folks will be involved now.

>  I don't know if it's an issue for kernel
> code, but probably not - the kernel shouldn't use LOCK if CONFIG_SMP is
> not enabled, and in any case shouldn't get a page fault on such an
> instruction..

Exactly, the kernel is fine as-is.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] Kernel feature support - architecture options and drivers

[河合英宏 / KAWAI，HIDEHIRO]

Hello Ben,

I'm sorry for the late reply.

> From: Behalf Of Ben Hutchings

> nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config.  I'm
> not sure how this could be useful in an OMAP system, and I don't expect
> the driver to be supportable.  Please disable it.
 
> e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
> several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
> not maintained upstream.  (Don't confuse e1000 with e1000e, which is for
> PCI Express and is still maintained.)  Please disable them.

These drivers are not used.  We'll simply disable them.

> USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
> configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
> seem to be properly maintained upstream.  Do you need them?

It is used as a convenient network interface for engineering.
If it is difficult to support them for super long term, we don't mind
too much even if CIP doesn't support them.

> 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.

> /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?

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

[cip-dev] Kernel feature support - architecture options and drivers

[Ben Hutchings]

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.

[cip-dev] Kernel feature support - architecture options and drivers

[河合英宏 / KAWAI，HIDEHIRO]

Hello Ben and folks,

> From: Ben Hutchings [mailto:ben.hutchings at codethink.co.uk]
> Sent: Friday, August 18, 2017 10:39 PM
> On Fri, 2017-07-28 at 04:49 +0000, ???? / KAWAI?HIDEHIRO wrote:

> > 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.

Let me clarify the level of support.  I think there are multiple
support levels:

(1) Backporting security fix
(2) Backporting other bug fix
(3) Backporting additional functionality related to the feature
(4) Answering questions, trouble shooting, ... (should be done by
    community)

If CIP only supports (1), your opinion is reasonable.
If CIP also supports (2), supporting even insecure features will make
sense.  For example, if we want to use a debugging feature which has a
security risk during the development phase, we hope that we can use it
without hitting bugs.

However, I'm not sure which support levels should be supported by CIP.
Have we defined it clearly?  If so, I'm sorry.

Best regards,

--
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

[cip-dev] Kernel feature support - architecture options and drivers

[Masato Minda]

Hi, Ben,

Sorry for late reply. I checked with our development team. And, I got reply from them.

Here is from out team.

minmin

On 2017/07/21 22:18, Ben Hutchings wrote:
>
> Sorry for the delay in reviewing feature support.? I previously reviewed
> filesystems and networking options, and this covers most of the rest.? I
> will send one more mail after this covering the remaining options.
>
> # x86
>
> a.out support (CONFIG_IA32_AOUT) is enabled in plathome_obsvx but is
> only needed for programs built before about 1995!? Please disable it.

It is only our histrical custom.
O.K. I understand.

> Vsyscall emulation (CONFIG_LEGACY_VSYSCALL_EMULATE) should be disabled
> as it's only needed by older C libraries.? Please select
> CONFIG_LEGACY_VSYSCALL_NONE instead.
>
> The modify_ldt syscall (CONFIG_MODIFY_LDT_SYSCALL) and 16-bit code
> support (CONFIG_X86_16BIT) should be disabled; they're only needed to
> run WINE.
>
> Intel Quark support (CONFIG_X86_INTEL_QUARK) is enabled in the
> siemens_iot2000 config.? Are you really using Quark SoCs?
>
> X32 syscall support (CONFIG_X86_X32) adds some attack surface that is
> not well-tested.? Several of the configurations (plathome_obsvx1,
> siemens_server and toshiba) enable this.? Do you need it?

It is better for us to stay in our products,
but, I understand to disable.

> KVM old-style device assignment (CONFIG_KVM_DEVICE_ASSIGNMENT) is
> deprecated and the feature has been removed upstream in 4.12, so it is
> definitely not supportable.? Only the plathome_obsvx1 config has this
> enabled.? Please disable it.? If you are actually using this feature, it
> should be replaced by VFIO.

O.K. I understand to replaced by VFIO.
?
> i7300_idle (CONFIG_I7300_IDLE) has been removed upstream, but is enabled
> in the plathome_obsvx1, siemens_server and toshiba configs).? This is
> only useful for the Intel i7300 chipset, so it should be fine to disable
> it.

O.K. I understand to disable.
?
> Several drivers (CONFIG_HP_WIRELESS, CONFIG_INTEL_RST,
> CONFIG_INTEL_SMARTCONNECT) appear to only be useful for laptops, but are
> enabled in the siemens_server config.? Please consider disabling them.
>
> SFI (CONFIG_SFI) seems to only be useful for Intel smartphone platforms,
> but is enabled in the siemens_server config.? Please disable it.
>
> # Storage drivers
>
> nbd (CONFIG_BLK_DEV_NBD) was not in good shape in 4.4, but is enabled in
> plathome_obsvx1.config and
> siemens_iot2000.? Do you need it?

O.K. I understand to disable.
?
> dm-cache (CONFIG_DM_CACHE) is marked as experimental in 4.4 and has
> changed a lot upstream, which will make it hard to maintain.? The
> siemens_server config has it enabled.? Do you need it?
>
> dm-switch (CONFIG_DM_SWITCH) is marked as experimental in 4.4, but is
> enabled in the siemens_server config.? Do you need it?
>
> MD multipath (CONFIG_MD_MULTIPATH) is "not under active development",
> and should be replaced with dm-multipath.? It is enabled in the
> plathome_obsvx1, siemens_iot2000, and siemens_server configs.? Do you
> need it?

O.K. I understand to disable.

> Many old SCSI drivers (CONFIG_BLK_DEV_3W_XXXX_RAID, CONFIG_SCSI_3W_9XXX,
> CONFIG_SCSI_3W_SAS, CONFIG_SCSI_ACARD, CONFIG_SCSI_ADVANSYS,
> CONFIG_SCSI_AM53C974, CONFIG_SCSI_BUSLOGIC, CONFIG_SCSI_DC395x,
> CONFIG_SCSI_DMX3191D, CONFIG_SCSI_DPT_I2O, CONFIG_SCSI_EATA,
> CONFIG_SCSI_GDTH, CONFIG_SCSI_IMM, CONFIG_SCSI_INIA100,
> CONFIG_SCSI_INITIO, CONFIG_SCSI_IPS, CONFIG_SCSI_MVUMI,
> CONFIG_SCSI_PMCRAID, CONFIG_SCSI_PPA, CONFIG_SCSI_QLOGIC_1280,
> CONFIG_SCSI_SYM53C8XX_2, CONFIG_SCSI_WD719X, CONFIG_SCSI_AIC79XX,
> CONFIG_SCSI_AIC7XXX, CONFIG_SCSI_AIC94XX, CONFIG_SCSI_ESAS2R,
> CONFIG_MEGARAID_LEGACY, CONFIG_SCSI_MVSAS, CONFIG_SCSI_QLA_ISCSI) are
> enabled in siemens_server config and I very much doubt you need any of
> these.? Please disable them.
>
> # Graphics drivers
>
> gma500 (CONFIG_DRM_GMA{3600,500,600}) is not maintained upstream and
> will be unsupportable, but is enabled in the plathome_obsvx1 config.? Do
> you need it?

O.K. I understand to disable.

> nouveau (CONFIG_DRM_NOUVEAU) is enabled in the hitachi_omap config.? I'm
> not sure how this could be useful in an OMAP system, and I don't expect
> the driver to be supportable.? Please disable it.
>
> # Network drivers
>
> Many old Ethernet drivers (CONFIG_TYPHOON, CONFIG_VORTEX,
> CONFIG_NE2K_PCI, CONFIG_DNET, CONFIG_ETHOC, CONFIG_FEALNX, CONFIG_JME,
> CONFIG_ADAPTEC_STARFIRE, CONFIG_AMD8111_ETH, CONFIG_PCNET32,
> CONFIG_ATL1, CONFIG_ATL1C, CONFIG_ATL1E, CONFIG_ATL2, CONFIG_B44,
> CONFIG_BCMGENET, CONFIG_CHELSIO_T1, CONFIG_DE2104X, CONFIG_DE4X5,
> CONFIG_DM9102, CONFIG_NET_TULIP, CONFIG_ULI526X, CONFIG_WINBOND_840,
> CONFIG_DL2K, CONFIG_SUNDANCE, CONFIG_HP100, CONFIG_SKY2, CONFIG_KS8842,
> CONFIG_KSZ884X_PCI, CONFIG_ENC28J60, CONFIG_MYRI10GE, CONFIG_NATSEMI,
> CONFIG_NS83820, CONFIG_S2IO, CONFIG_VXGE, CONFIG_FORCEDETH,
> CONFIG_HAMACHI, CONFIG_YELLOWFIN, CONFIG_NETXEN_NIC, CONFIG_QLA3XXX,
> CONFIG_QLGE, CONFIG_R6040, CONFIG_8139CP, CONFIG_8139TOO, CONFIG_ATP,
> CONFIG_SC92031, CONFIG_SIS190, CONFIG_SIS900, CONFIG_EPIC100,
> CONFIG_SMSC9420, CONFIG_CASSINI, CONFIG_HAPPYMEAL, CONFIG_NIU,
> CONFIG_TEHUTI, CONFIG_TLAN, CONFIG_VIA_RHINE, CONFIG_VIA_VELOCITY,
> CONFIG_WIZNET_W5100, CONFIG_WIZNET_W5300) are enabled in siemens_server
> config and I very much doubt you need any of these.? samsung-sxgbe
> (CONFIG_SXGBE_ETH) is also enabled, but this hardware only exists in
> Samsung SoCs.? Please disable them.
>
> e100 (CONFIG_E100) and e1000 (CONFIG_E1000) drivers are enabled in
> several configs (hitachi_omap, plathome_obsvx1, siemens_server) but are
> not maintained upstream.? (Don't confuse e1000 with e1000e, which is for
> PCI Express and is still maintained.)? Please disable them.

O.K. I understand to disable.
?
> sungem (CONFIG_SUNGEM) is enabled in the siemens_server and toshiba
> powerpc configs, but I doubt that this driver is needed.? Please
> consider disabling it.
>
> USB-attached network drivers (CONFIG_USB_USBNET) are enabled in several
> configs (hitachi_omap, toshiba_tegra, plathome_obsvx1) but few of them
> seem to be properly maintained upstream.? Do you need them?

It is better for us to stay in our products,
but, I understand to disable.
?
> i2400m-usb (CONFIG_WIMAX_I2400M_USB) is enabled in plathome_obsvx1, but
> is unmaintained upstream.? Do you need it?? (I also noted previously
> that wimax in general is dead.)

O.K. I understand to disable.

> Wifi drivers may be hard to support in the long term due to changes in
> the softMAC (mac80211) driver API.? However I will assume that they are
> needed for some applications.
>
> The ipw2x00 drivers (CONFIG_IPW2100, CONFIG_IPW2200) are not maintained
> and only found in some old x86 systems, but is enabled in the
> plathome_obsvx1 config.? Please disable them.

O.K. I understand to disable.

> zd1211rw (CONFIG_ZD1211RW) seems to be unmaintained but is enabled in
> the plathome_obsvx1 config.? Please disable it.

O.K. I understand to disable.

> r8172u (CONFIG_R8712U) is in drivers/staging (and has been for nearly 7
> years!) and is therefore unlikely to be supportable, but is enabled in
> the siemens_iot2000 config.? Do you need it?
>
> # USB drivers
>
> fotg210-hcd (CONFIG_USB_FOTG210_HCD) is a platform driver that doesn't
> look usable on x86, but is enabled in the siemens_server config.? Please
> disable it.
>
> uhci-hcd (CONFIG_USB_UHCI_HCD) is for obsolete hardware (so far as I
> know) but is enabled in the plathome_obsvx1, siemens_server and toshiba
> x86 configs.? Please disable it.

O.K. I understand to disable.
?
> ehset (CONFIG_USB_EHSET_TEST_FIXTURE) and usb3503
> (CONFIG_USB_HSIC_USB3503) are unlikely to be needed but are enabled in
> the siemens_server config.? Please consider disabling them.
>
> # Misc drivers
>
> OProfile (CONFIG_OPROFILE) seems to be barely maintained and redundant
> with perf, but all the configs still enable it (mostly because it's
> enabled in upstream defconfigs).? Please consider disabling it.
>
> 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?

O.K. I understand to disable.
?
> /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.
>
> Chrome platform support (CONFIG_CHROME_PLATFORMS) is enabled in the
> siemens_server config.? Assuming you don't need to support these
> platforms, please disable it.
>
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.

--
Masato Minda <minmin@plathome.co.jp>
Plat'Home Co., Ltd.