linux-kernel - Re: [PATCH] char: nvram: disable on ARM

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180207015509.GV3404@piout.net>
Date:   Wed, 7 Feb 2018 02:55:09 +0100
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] char: nvram: disable on ARM

On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
> * arch/arm/kernel/time.c has this code
> 
> #if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
>     defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
> /* this needs a better home */
> DEFINE_SPINLOCK(rtc_lock);
> EXPORT_SYMBOL(rtc_lock);
> #endif  /* pc-style 'CMOS' RTC support */
> 
> That can be adapted now, or maybe we could move all definitions into
> a common place (that needs some more planning).
> 

Yes, on arm, the rtc_lock is mostly there to please
drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
x86 and PPC specific.

If we can get rid of arch/powerpc/platforms/chrp/time.c and
arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
is x86 only.

> * similarly, this line in nvram.c can be simplified:
> #if defined(CONFIG_ATARI)
> #  define MACH ATARI
> #elif defined(__i386__) || defined(__x86_64__) || defined(__arm__)  /* and ?? */
> #  define MACH PC
> #else
> #  error Cannot build nvram driver for this machine configuration.
> #endif
> 
> * GENERIC_NVRAM is not really generic, instead this seems to be the
>   chardev that is used for 32-bit powerpc (powermac, 85xx, 86xx), while
>   64-bit powerpc (cell, maple, opal, pseries) use code from
>   arch/powerpc/kernel/nvram_64.c, with the same underlying arch hooks.
>   The nvram_64 code appears to be mostly a superset of the 32-bit
>   generic_nvram one.
> 
> * The code in drivers/char/nvram is not used at all when
>    GENERIC_NVRAM is set, and half the code in there is different
>    between x86 and atari.
> 
> * most of the external interface in include/linux/nvram.h is
>   unused, the rest tends to be architecture specific
> 
> * The procfs file appears to be completely useless on any 64-bit
>    x86 machine, this is what I see:
> 
> $ cat /proc/driver/nvram
> Checksum status: valid
> # floppies     : 0
> Floppy 0 type  : none
> Floppy 1 type  : none
> HD 0 type      : none
> HD 1 type      : none
> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
> DOS base memory: 635 kB
> Extended memory: 65535 kB (configured), 65535 kB (tested)
> Gfx adapter    : EGA, VGA, ... (with BIOS)
> FPU            : not installed
> 

I really don't think anyone is using that but I don't really know much
about x86 and the specification this may be part of.

I see the info may be used in drivers/video/fbdev/ and
drivers/platform/x86/thinkpad_acpi.c

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com