Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.assembly > #17 > unrolled thread

Protected mode on 64-bit CPU

Back to article view | Back to alt.os.assembly

Contents

  Protected mode on 64-bit CPU muskrat7@gmail.com - 2016-09-03 19:10 -0700
    Re: Protected mode on 64-bit CPU Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-09-03 23:17 -0400
      Re: Protected mode on 64-bit CPU "wolfgang kern" <nowhere@never.at> - 2016-09-04 11:27 +0200
      Re: Protected mode on 64-bit CPU James Harris <james.harris.1@gmail.com> - 2016-09-04 13:01 +0100
        Re: Protected mode on 64-bit CPU Muskrat <muskrat7@gmail.com> - 2016-09-04 10:10 -0700
        Re: Protected mode on 64-bit CPU James Harris <james.harris.1@gmail.com> - 2016-09-04 21:53 +0100

#17 — Protected mode on 64-bit CPU

Does anyone know why 64-bit long mode does not have built-in hardware protection? I know many didn't use the 32-bit hardware segmentation but it was a nice option to have if you wanted... Did they just get rid of it in 64-bit mode due to the perception it wouldn't be used or were there other limitations that prevented this feature?

[toc] | [next] | [standalone]

#18

On Sat, 3 Sep 2016 19:10:19 -0700 (PDT)
muskrat7@gmail.com wrote:

> Does anyone know why 64-bit long mode does not have built-in hardware
> protection? I know many didn't use the 32-bit hardware segmentation
> but it was a nice option to have if you wanted... Did they just get
> rid of it in 64-bit mode due to the perception it wouldn't be used or
> were there other limitations that prevented this feature?
>

I'm cross-posting this to alt.os.development and alt.lang.asm.

You might also try posts to comp.lang.asm.x86 and comp.arch.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#19

Rod Pemberton cited:
> On Sat, 3 Sep 2016 19:10:19 -0700 (PDT)
> muskrat7@gmail.com wrote:
 
>> Does anyone know why 64-bit long mode does not have built-in hardware
>> protection? I know many didn't use the 32-bit hardware segmentation
>> but it was a nice option to have if you wanted... Did they just get
>> rid of it in 64-bit mode due to the perception it wouldn't be used or
>> were there other limitations that prevented this feature?

Protection in long mode works by (anyway required there) paging.
Segment oriented protection is rare used in 32-bit environments.
I think the reason for abandon Segments in LM were speed and perhaps 
the missing of the (LM only) additional page protecion features too.

> I'm cross-posting this to alt.os.development and alt.lang.asm.
> You might also try posts to comp.lang.asm.x86 and comp.arch.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#20

On 04/09/2016 04:17, Rod Pemberton wrote:
> On Sat, 3 Sep 2016 19:10:19 -0700 (PDT)
> muskrat7@gmail.com wrote:
>
>> Does anyone know why 64-bit long mode does not have built-in hardware
>> protection? I know many didn't use the 32-bit hardware segmentation
>> but it was a nice option to have if you wanted... Did they just get
>> rid of it in 64-bit mode due to the perception it wouldn't be used or
>> were there other limitations that prevented this feature?

Segmentation was a brilliant idea but was let down by Intel's Protected 
Mode implementation which distinguished between segmented and 
non-segmented pointers and thereby created lots of complexity.

People generally just used 32-bit pointers.

I gather than when AMD asked Microsoft and others what they wanted from 
64-bit mode there was, because of the familiarity of the above flat 
32-bit address mode, little or no demand for segmentation. AMD therefore 
dropped it and lots of other things for which they found little or no 
interest.

(They did not delete these things from the CPU - which still has them in 
PMode - only from 64-bit Long Mode.)

IMO, even with the flat pointer model, it is a pity that AMD went as far 
as they did.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#21

On Sunday, September 4, 2016 at 7:01:05 AM UTC-5, James Harris wrote:
> On 04/09/2016 04:17, Rod Pemberton wrote:
> > On Sat, 3 Sep 2016 19:10:19 -0700 (PDT)
> > muskrat7@gmail.com wrote:
> >
> >> Does anyone know why 64-bit long mode does not have built-in hardware
> >> protection? I know many didn't use the 32-bit hardware segmentation
> >> but it was a nice option to have if you wanted... Did they just get
> >> rid of it in 64-bit mode due to the perception it wouldn't be used or
> >> were there other limitations that prevented this feature?
> 
> Segmentation was a brilliant idea but was let down by Intel's Protected 
> Mode implementation which distinguished between segmented and 
> non-segmented pointers and thereby created lots of complexity.
> 
> People generally just used 32-bit pointers.
> 
> I gather than when AMD asked Microsoft and others what they wanted from 
> 64-bit mode there was, because of the familiarity of the above flat 
> 32-bit address mode, little or no demand for segmentation. AMD therefore 
> dropped it and lots of other things for which they found little or no 
> interest.
> 
> (They did not delete these things from the CPU - which still has them in 
> PMode - only from 64-bit Long Mode.)
> 
> IMO, even with the flat pointer model, it is a pity that AMD went as far 
> as they did.
> 
> 
> -- 
> James Harris

Yeah, and I know OSs didn't use it but having hardware enforced segmentation could help to create a much more secure OS, at least in theory. I heard segmentation cost performance but if that's true does it cost more than implementing the software based protections and then hoping you don't have a bug that will thwart it...?

[toc] | [prev] | [next] | [standalone]

#22

On 04/09/2016 13:01, James Harris wrote:

...

> IMO, even with the flat pointer model, it is a pity that AMD went as far
> as they did.

Looking back, I see that that's a bit cryptic so here's an example:

AIUI to check for stack overflow on AMD64 there are two primary options:

1. Use the paging hardware to make a guard page. That works normally but 
can fail if the compiler doesn't correctly anticipate the page size.

2. Have the compiler include checks which basically have to be executed 
at the start of each subroutine (with the possible exception of small 
leaf subroutines) to ensure there is a sufficient amount of space. This 
adds to the cost of each call.

By contrast, with segmentation in PM32 a stack segment can automatically 
limit the size of the stack. Every time the stack is referenced the 
hardware can check the range of the access. This requires execution of 
no extra code and the compiler does not need to anticipate the page 
size. It is a pity that AMD took this option away.


-- 
James Harris

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.assembly

csiph-web