OSDev.org

I'd like to claim that unicorns exist, since we all know trolls exist.

Assuming people will believe good bedtime stories won't get you far. Proof wanted, not insults, thanks.

berkus wrote:Your self-righteous narcissism is amazing, but as Combuster said, proof please, not insults.

Boy! The one insulted is I, that guy XenOS not content of posting his random Google search instead of asking semi politely, he just ignores my telling him and reiterates his unfounded claims. I said and should I repeat it, this new thing doesn't use AMD's or anybody's "magic" password. Unless calling someone a lier isn't deemed insulting on this board ? Oh, well (again).

I have said I shall finally publish this, at the same places where I published the much more interesting AMD debugging expansions - you must have seen that, it's been all over the web. Instead of wasting my (and your time) you'd better do something with what I've brought you hey.

Bye bye

Hi,

Combuster wrote:Assuming people will believe good bedtime stories won't get you far. Proof wanted, not insults, thanks.

For some CPUs, proof that cache testing features exist is easy to find - for 80486 and clones (with the TRn registers) it was fully documented by Intel in their old programming manuals, etc, and for Intel P6 it's documented in "MSRs Appendix" of the programming manuals. I wouldn't be surprised if the same MSRs work in the same or similar way for later Intel CPUs that were derived from the P6 core (but haven't been publicly documented). I also believe similar cache testing features exist in at least some AMD CPUs (because I remember seeing some incomplete notes on "confidential" AMD MSRs a while ago).

Now, consider this from the perspective of someone probing the CPU for undocumented MSRs. They find an undocumented MSR that seems to write directly to physical memory under certain conditions, and there's no documentation that describes it as a cache test feature (and they have no real way to realise it's modifying cache lines instead of writing directly to physical memory because it has virtually the same effect), so they assume it's something new and might not realise it's something that's been floating around in various forms for over 20 years.


Cheers,

Brendan

berkus wrote:

Czernobyl wrote:I have said I shall finally publish this, at the same places where I published the much more interesting AMD debugging expansions - you must have seen that, it's been all over the web.

Eagerly awaiting.

Seconded.
I don't feel like making any attempt of challenging the claim itself as it is a rather probable one (for reasons including the ones Brendan explained). The point is that until we can actually see it in use, it is in practice equivalent to a piece of literature. If you are after your credits, you might better work on your proof than on these policy debates bordering on flamewars - the latter is for trolls and other losers.

Combuster wrote:

berkus wrote:

Czernobyl wrote:I have said I shall finally publish this, at the same places where I published the much more interesting AMD debugging expansions - you must have seen that, it's been all over the web.

Eagerly awaiting.

Seconded.
I don't feel like making any attempt of challenging the claim itself as it is a rather probable one (for reasons including the ones Brendan explained). The point is that until we can actually see it in use, it is in practice equivalent to a piece of literature.

Thanks. You've got your (short) piece of literature for review at http://blogs.mail.ru/mail/czernobyl/99E ... ED43E.html, that shall be my New Year present to you all.


--
Czerno

berkus wrote:Thanks, looks fairly useless.

Indeed. Only K7, only ring 0.


JAL

jal wrote: Indeed. Only K7, only ring 0.

Sure, you've been warned from the start only some processors are concerned and only ring zero.
And I've come to this place here in the hope I'd gather intelligent advice re. how dangerous this could be, or not dangerous; I've got /some/, for which I'm grateful. Did I ever claim something that would be of interest to any of you in particular? I've posted the link because I've been challenged to do it. Still I don't grok people who take the time to post how uninterested they are, or some, apparently from the regulars here, apparently just to insult... I understand and respect the fact that they are unimpressed, though apparently not enough uninsterested they would simply ignore the thread LOL.

Still an interesting feature IMHO. Opinions and mileage...may vary. Bye ! This is absolutely my last post to this thread, in earnest I don't have anything left to add.

Even if your method isn't globally useful across the whole x86 CPUs as stated, what would be universally valuable would be for you to describe how you got to determine all those details. Based on that you could contribute with ideas for investigation methodologies and "change the theater scene" a little bit for good for everyone. That would be very appreciated and lasting.

I personally consider that any sharing of information is always welcome and important. At least you did share it. What I wouldn't do is teasing people with an "I give or take away info" game.

If I had known that, and if my concern was to get a better insight about security, I would have just asked something along these lines: "I have found that it might be possible for at least some K7 CPUs to directly read physical 32-bit RAM addresses in CPL0 in a way that bypasses the paging/segmentation system, through the uses of its MSRs. You just specify the MSR in ECX, provide the physical RAM offset in EBX, and it will return the 64-bit data in EDX:EAX, and you must use the RDMSR and WRMSR instructions. What security implications can it have for operating systems in general, given that all virtualization characteristics for address space are bypassed even with paging enabled, in CPL0 code?" As you can see, not much more is needed to get objective opinions. I would always opt to share the information I get to decipher directly and freely anyway, seeing how low level security is very strong nowadays most of the time and how this issue isn't global.

I'll have to agree with the other posters that the ability to bypass segmentation / paging at CPL0 is not a problem. I use a segmented kernel design for protection/security reasons, but I can never insure that a 3:d party device-driver couldn't crash the kernel intentionally or unintentionally. I could reduce the probability for unintentional damage by avoiding a flat memory model where any address calculation error could corrupt whatever it wants, but maliciuos attacks could not be stopped at CPL0.

And I don't think it is a big deal in most OSes to convert between physical and logical addresses at CPL0. I have APIs that do this, so it is no big deal.