Below is a SPAM received by a customer of zNET Internet Services. It originated from your site, used an address referencing your site, used your company for connectivity, or in some way involved you. Please deal with this person according to any AUP's you have. Thanks for your time and attention to this problem. When Spam Burns You: Why Bulk E-mail is Bad Business http://www.twowriters.net/pages/words_08.html Spam Laws http://www.spamlaws.com Basic Mailing List Management Principles for Preventing Abuse http://mail-abuse.org/rbl/manage.html "The makers of our Constitution understood the need to secure conditions favorable to the pursuit of happiness, and the protections guaranteed by this are much broader in scope, and include the right to life and an inviolate personality -- the right to be left alone -- the most comprehensive of rights and the right most valued by civilized men. The principle underlying the Fourth and Fifth Amendments is protection against invasions of the sanctities of a man's home and privacies of life. This is a recognition of the significance of man's spiritual nature, his feelings, and his intellect. Every violation of the right to privacy must be deemed a violation of the Fourth Amendment." - Justice Louis Brandeis Network Information: BELL-ATLANTIC1 151.196.0.0 151.205.0.0 [EMAIL PROTECTED] SPAM Follows: From [EMAIL PROTECTED] Mon Dec 18 20:16:07 2000 Received: from sd04.znet.com (sd04.znet.com [207.167.69.1]) by mx3.znet.com (8.11.1/8.11.1/jjb-mx3) with ESMTP id eBJ4G5220038 for <[EMAIL PROTECTED]>; Mon, 18 Dec 2000 20:16:05 -0800 (PST) Received: from sd.znet.com (sd.znet.com [207.167.64.5]) by sd04.znet.com (8.11.1/8.11.1/jjb-sd04) with ESMTP id eBJ4G4526952 for <[EMAIL PROTECTED]>; Mon, 18 Dec 2000 20:16:04 -0800 (PST) Received: (from root@localhost) by sd.znet.com (8.11.1/8.11.1/jjb-sd) id eBJ4G2m13872 for [EMAIL PROTECTED]; Mon, 18 Dec 2000 20:16:03 -0800 (PST) Received: from lightning.fastxs.net (ns1.fastxs.net [212.204.201.31]) by sd.znet.com (8.11.1/8.11.1/jjb-sd) with ESMTP id eBJ4G0g13861 for <[EMAIL PROTECTED]>; Mon, 18 Dec 2000 20:16:01 -0800 (PST) X-Envelope-From: [EMAIL PROTECTED] X-Envelope-To: <[EMAIL PROTECTED]> Received: by lightning.fastxs.net (Postfix) id 9080BE8097; Tue, 19 Dec 2000 05:15:05 +0100 (CET) Delivered-To: [EMAIL PROTECTED] Received: by lightning.fastxs.net (Postfix, from userid 522) id 3B41CE808A; Tue, 19 Dec 2000 05:15:05 +0100 (CET) Delivered-To: [EMAIL PROTECTED] Received: from arizona.localdomain (adsl-151-202-119-56.nyc.adsl.bellatlantic.net [151.202.119.56]) by lightning.fastxs.net (Postfix) with ESMTP id E78D4E808A for <[EMAIL PROTECTED]>; Tue, 19 Dec 2000 05:15:02 +0100 (CET) Received: (from kevin@localhost) by arizona.localdomain (8.11.0/8.11.0) id eBJ4F0V32201 for [EMAIL PROTECTED]; Mon, 18 Dec 2000 23:15:00 -0500 Date: Mon, 18 Dec 2000 23:14:59 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [plex86] Performance enhancement: elminiating mode and contextswitches Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, Dec 18, 2000 at 09:42:54AM -0500 Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] On Mon, Dec 18, 2000 at 09:42:54AM -0500, Kevin Lawton wrote: > Ramon van Handel wrote: > > > > Once you modify the instructions in a page by extending the size > > > of an instruction (changing an IO to a call), as opposed to > > > inserting an INT3 (always 1 byte), we have to move from our notion > > > of simple modified cache pages to a more dynamic translation like > > > scheme. The branch offsets change etc. > > > > No, not necessarily. What you do is overwrite the next instruction and > > keep the original in a branch table. You use a call to go to the > > emulation routine; in stead of using ret, however, the emulation routine > > will look in the branch table, which contains (1) the next instructions to > > be executed, and (2) the address of the first instruction that was not > > overwritten. > > Sounds good. I think this has good potential for virtualizing branch > instructions. I see what you mean about virtualizing other instructions > which are less than 5 bytes. Stepping on downstream instructions > means either generating dynamic code for arbitrary instructions, or > accessing emulation code. The first option is much work. The > second option is not so good from a run-it-in-ring3 perspective. I'm not an expert on any of this, but consider the following: jmp foo [...] inst1 foo: inst2 inst3 Let's say 'inst1' is a four byte instruction that we wish to emulate, so we replace it, along with part of 'inst2', with a five byte 'call xyz' instruction -- what happens to the foo branch? Note, it wouldn't be possible to scan for all 'jmp foo' instructions because the jmp branch offset could be dynamically setup. Am I missing something? (I'm by no means an expert in assembler or emulation, but I'm curious if this becomes an issue.) -Kevin -- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | [EMAIL PROTECTED] 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------
