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-next>] [day] [month] [year] [list]
Date:   Wed,  2 May 2018 09:51:06 +0200
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     DRI Development <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Eric Anholt <eric@...olt.net>, linux-doc@...r.kernel.org,
        Jonathan Corbet <corbet@....net>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded

This came up in discussions when reviewing drm patches.

Cc: Eric Anholt <eric@...olt.net>
Cc: linux-doc@...r.kernel.org
Cc: Jonathan Corbet <corbet@....net>
Signed-off-by: Daniel Vetter <daniel.vetter@...el.com>

--

Aside: I wonder whether we shouldn't move this to some other place and
rst-ify it? Any good suggestions?
-Daniel
---
 Documentation/ioctl/botching-up-ioctls.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt
index d02cfb48901c..883fb034bd04 100644
--- a/Documentation/ioctl/botching-up-ioctls.txt
+++ b/Documentation/ioctl/botching-up-ioctls.txt
@@ -73,7 +73,9 @@ will have a second iteration or at least an extension for any given interface.
    future extensions is going right down the gutters since someone will submit
    an ioctl struct with random stack garbage in the yet unused parts. Which
    then bakes in the ABI that those fields can never be used for anything else
-   but garbage.
+   but garbage. This is also the reason why you must explicitly pad all
+   structures, even if you never use them in an array - the padding the compiler
+   might insert could contain garbage.
 
  * Have simple testcases for all of the above.
 
-- 
2.17.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ