linux-kernel - Re: Why exported const value modified by another driver not updated in original driver

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: <CAK-9PRDA4xnc08rR+yf_NoG0+7uUJn0euV+cOoEMOAYMYeN5Cg@mail.gmail.com>
Date:	Tue, 4 Sep 2012 17:19:00 +0530
From:	Chinmay V S <cvs268@...il.com>
To:	Manavendra Nath Manav <mnm.kernel@...il.com>
Cc:	Julian Andres Klode <jak@...-linux.org>,
	kernelnewbies@...nelnewbies.org, devel@...verdev.osuosl.org,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: Why exported const value modified by another driver not updated
 in original driver

Hi Manavendra,

Couple of things are involved in above experiment.

1. const
The variable "value" is defined as
- "static const int" in driver.c.
- "extern int" in hacker.c (i.e. not const).

2. volatile
An object marked volatile is always fetched from memory and the
compiler does NOT try to optimise away this read from memory. This is
because volatile is an explicit indication to the compiler to fetch
the value from memory and not used older value cached in CPU-register.

Here is whats happening in regular case:

driver.ko init()
    - alloc RAM for "value"
    - load value of "value" into register
    - print "value"
      (123 in driver.ko context)
hacker.ko init()
    (no alloc RAM as it is extern. Allow assignment as its NOT const here).
    - load value of "value" into register
    - print "value"
      (987 in hacker.ko context)
hacker.ko exit()
    - print "value"
      (987 in hacker.ko context)
driver.ko exit()
    - print "value"
      (123 in hacker.ko context)


Here is whats happening in case volatile is used:

driver.ko init()
    - alloc RAM for "value"
    - load value of "value" into register
    - print "value"
     (123 in driver.ko context)
hacker.ko init()
    (no alloc RAM as it is extern. Allow assignment as its NOT const here).
    - load value of "value" into register
    - print "value"
      (987 in hacker.ko context)
hacker.ko exit()
    - print "value"
     (987 in hacker.ko context)
driver.ko exit()
    - fetch value of "value" from RAM.
      (as volatile forces an explicit read from memory)
    - print "value"
      (987 copied from hacker.ko context into driver.ko context)

As Alan mentioed above, it will be interesting to look into the
assembly code of your modules. Run objdump -S on your .ko modules and
search for .init.text and .exit.text in the assembly. Observing where
the compiler decides to place the object "value" should explain why
things work the way they do.

--
regards
CVS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/