control weather page can be executed on i386

[lambdaislove]

So when loading an executable you want to prevent anything more from being executable than is possible. You can control this with segments for instance. It would seem that on i386 you cannot control weather a page is executable or not, however. Is segmentation the only way to control whether or not a page can be executed on i386?

[iansjack]

Paging lets you control this. Most modern operating systems don't use segmentation.

[lambdaislove]

What bit do I set in the page table to allow this? On https://wiki.osdev.org/Paging there doesn't seem to be any mention of a way to control if code is executable or not.

[azblue]

Paging lets you control this. Most modern operating systems don't use segmentation.

He was asking about the 386; the NX bit wasn't added until much later (Pentium 2?)

So yes, on old hardware segmentation is the most straightforward way to prevent data from being executed. There is an interesting hack to emulate NX on systems that don't support it; it has something to do with tricking TLB entries. I can't quite remember how it worked.

[lambdaislove]

That makes it sound like there's still a way to do this with a 32-bit kernel. I'm using qemu so I'd just like to be able to load a 32-bit x86 kernel and be able to set the executable bit.

[isaacwoods]

He was asking about the 386; the NX bit wasn't added until much later (Pentium 2?)

Afaik, Intel first supported it on the Pentium 4, so even later. AMD supported it before that however, I think from the start of AMD64

[lambdaislove]

Ah so if you enable PAE you get access to the NX bit. I see.

[Brendan]

Hi,

Ah so if you enable PAE you get access to the NX bit. I see.

Yes; if you enable PAE you may or may not get access to the NX bit depending on whether the CPU supports that feature or not.

There is an interesting hack to emulate NX on systems that don't support it; it has something to do with tricking TLB entries. I can't quite remember how it worked.

For most CPUs (especially those that don't support NX), "instruction TLB" and "data TLB" are separate. This means that you can mark all "non-executable" pages as "not present" and get a page fault when they're accessed; and if it was a data access your page fault handler can mark the page as "present" and read from the page (to get it into the data TLB but not the instruction TLB) and then make the page "not present" again. Of course once it's in the data TLB it'll stay there for a while (until evicted or flushed) and other data accesses to that page won't cause a page fault (even though the page is "not present"), but execution will cause a page fault (because it's only in the data TLB and not in the instruction TLB).


Cheers,

Brendan

[Schol-R-LEA]

It should, however, be mentioned that AMD introduced the AMD64 architectural extensions, including the NX bit, in 2003, and Intel followed suit with their XD bit (which is their name for the same setting) a year later. While systems without it continued to be sold for a few more years, by now one can reasonably expect that any PC made in the past (say) 13 years to support NX/XD bits.

Why is this relevant? Because that was still in the period (which stretched from 1974 to around 2008) where each successive generation of hardware outsold all previous generations combined - that is to say, roughly speaking, the number of microprocessor-based computers in the world more than doubled every 18 to 24 months. Technically, this trend has continued, but most of that rapid increase is now seen in the mobile market rather than desktops, where x86 isn't a serious competitor and every processor in use has had an equivalent functionality from the outset (at least WRT the ones used in mobile devices).

The practical upshot of this is that between pattern, and older systems discarded for hardware failures or obsolescence, the number of PCs without the NX/XD bits currently in use is negligible, at least from the perspective of most OS devs. The majority of systems which don't have it are ones which aren't going to get a new OS put on them no matter what, not even a version of Windows made in the past decade - old imaging file servers which have been hidden in an electrical closet of some dentist's office slowly dying of overheating and dust, glorified kiosks running on the reception desk of some government agency, that sort of thing. There are hundreds of thousands of such systems, certainly, but no one is going to be changing the OS on them, ever - with such systems, you'd be lucky to find Windows XP or Red Hat 9.0 on them.

Where I am currently still exiled to... sorry I meant to say , where I currently live in the southern US, even IT recycling businesses don't sell computers that are older than Pentium 4, and they basically charge a nominal fee (US$20-35) to let you take them off their hands, which they only do to defray some of their costs (it is a lot cheaper than stripping down the metals and chemicals, and then dealing with the resulting toxic waste).

I cannot speak for places outside the US, but my impression is that in most of the world, you are even less likely to find older hardware. I may be wrong, however; please feel free to correct me on this.

The point is, you probably would need to go out of your way to find a system without NX/XD support.

Now, I do not know what the OP's goals are, or what hardware they mean to target. There are legitimate reasons why they might want to target base i386 systems. The question also speaks to the issues of supporting the necessary subsystems (PAE or Long Mode) in order to use the NX/XD bit, which may be a consideration for the OP when starting out in an new operating system implementation. However, I do think that some perspective may be helpful, if not for the OP then for some others with similar questions.

[iansjack]

Perhaps the OP could confirm that the question referred only to the original 80386 rather than current processors?

[klange]

Perhaps the OP could confirm that the question referred only to the original 80386 rather than current processors?

OP already confirmed that they weren't talking about the original 80386:

That makes it sound like there's still a way to do this with a 32-bit kernel. I'm using qemu so I'd just like to be able to load a 32-bit x86 kernel and be able to set the executable bit.

[iansjack]

I think you'll find that processors later than the 80386 can run 32-bit kernels. Some of them even support PAE.