linux-kernel - Re: use of setjmp/longjmp in x86 emulator.

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]

Date:	Mon, 01 Mar 2010 08:39:49 -1000
From:	Zachary Amsden <zamsden@...hat.com>
To:	Gleb Natapov <gleb@...hat.com>
CC:	linux-kernel@...r.kernel.org, mingo@...e.hu, avi@...hat.com,
	mtosatti@...hat.com
Subject: Re: use of setjmp/longjmp in x86 emulator.

On 03/01/2010 07:47 AM, Gleb Natapov wrote:
> On Mon, Mar 01, 2010 at 06:13:53AM -1000, Zachary Amsden wrote:
>    
>
>> ... you are broken.  This case can be made very much more complex
>> and hard to reason about by using local variables which are reset by
>> the longjmp.
>>
>> Further, it requires use of the volatile keyword to interact
>> properly with logic involving more than one variable, and thus, by
>> definition is impossible to use in the kernel, which does not
>> implement the volatile keyword.  :)
>>      
> volatile is a language keyword how it can be not implemented by the
> kernel? And why volatile is needed to implement longjmp?
>    

Local variables which are not volatile are "undefined" after a longjmp.  
Thus setjmp() return value is the only valid rvalue otherwise.

As I said, the kernel does not implement the volatile keyword :)
(i.e. its use is heavily discouraged to the point one can consider it 
not implemented)

>> Instead, for this case, use the fact that there is an
>> architecturally designed finite number of exceptions that can be
>> processed simultaneously.  This means if you queue exceptions to a
>> pending list of control-flow interrupting events to be processed, as
>> long as the queue is appropriately sized, you will never overflow
>> this queue and never require dynamic allocation.  Further, you can
>> then naturally follow the exception priority rules at the top-level
>> of the emulator and never need to pass back complex exception
>> structures, merely a simple return value which indicates whether to
>> return to top-level control logic or continue with instruction
>> emulation.  I believe using this style of programming will make your
>> need for setjmp/longjmp go away.
>>
>>      
> Of course it is possible to use return values instead. This is what code
> does currently and this is completely unrelated to exception queue
> depth. Code will be much simpler if we will be able to bail out from the
> depth of emulator immediately if exception condition is met or exit to
> userspace is required instead of passing the condition up the call
> chain.
>    

Anything that can generate exceptions is going to need logic to handle 
error cases anyway... the depth can not be that bad.  Especially if you 
structure it so as to optimize for tail calling.

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