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: <16641a56-9139-4396-a5a8-89606bedd1f1@app.fastmail.com>
Date:   Fri, 27 Jan 2023 11:27:25 +0100
From:   "David Rheinsberg" <david@...dahead.eu>
To:     "Ingo Molnar" <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        "Borislav Petkov" <bp@...en8.de>, "Ingo Molnar" <mingo@...hat.com>,
        "Thomas Gleixner" <tglx@...utronix.de>
Subject: Re: [PATCH] x86/insn_decoder_test: allow longer symbol-names

Hi Ingo!

On Wed, Jan 25, 2023, at 12:30 PM, Ingo Molnar wrote:
> * David Rheinsberg <david@...dahead.eu> wrote:
>> diff --git a/arch/x86/tools/insn_decoder_test.c b/arch/x86/tools/insn_decoder_test.c
>> index 472540aeabc2..366e07546344 100644
>> --- a/arch/x86/tools/insn_decoder_test.c
>> +++ b/arch/x86/tools/insn_decoder_test.c
>> @@ -106,7 +106,7 @@ static void parse_args(int argc, char **argv)
>>  	}
>>  }
>>  
>> -#define BUFSIZE 256
>> +#define BUFSIZE 4096
>
> That hard-coded constant is a bit lame and will cause trouble the minute 
> *that* size is exceeded - don't we have some more natural figure, such as 
> KSYM_SYMBOL_LEN?

Thanks for the hint! I tried mentioning this in the commit-message. I am unsure whether a fixed-size limit is the correct thing to do. However, given that this is a compile-time test-tool, I thought bumping the limit for this stack buffer to be sufficient. I am open to other suggestions.

The input to this tool is the output of objdump, so effectively annotated x86-assembly. To get a proper estimate of how long such a line could be, I would have to audit all instructions and know what kind of arguments are possible. Can some of them take multiple symbols as argument? Are there other possibly long encodings of arguments to consider?

Lastly, shouldn't this use KSYM_NAME_LEN rather than KSYM_SYMBOL_LEN? And then how much room for normal instruction-encoding should I calculate? I feel like whatever I do (even with those constants), I would end up with only an estimate and wouldn't actually end up closing this issue.

The current workaround is to just disable CONFIG_X86_DECODER_SELFTEST, which I thought is a sad state. I can gladly use `256 + KSYM_NAME_LEN` and add a comment ala "room for insn-encoding and a symbol name". Would that be acceptable? The alternative would be to try to dyn-alloc a buffer and increase it to the actual line-length?

Open to suggestions!

Thanks
David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ